Closed Bug 1221497 Opened 5 years ago Closed 4 years ago

Please write an article about the deprecation/removal of the "Tab groups" feature

Categories

(support.mozilla.org :: Knowledge Base Content, task)

task
Not set

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: Gijs, Unassigned)

References

Details

(Keywords: devrel-needed)

Attachments

(1 file)

Proposed URL:

http://support.mozilla.org/kb/tab-groups-removal

More context: bug 1221050, and specifically this proposed migration plan:

(In reply to Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #16)
> Since we are removing tab groups without replacement, we should at least
> give people a heads up and point them to alternatives for dealing with many
> tabs. This means a few things:
> 
> - Show a desktop notification in the version *prior* to the one that removes
> tab groups saying something like »Tab groups will be removed from Firefox in
> a few weeks. Click to learn more.«
> 
> - Have that notification point to a support page that lists add-ons like
> side tabs, tree style tabs and tab mix plus. We should also make sure that
> those are add-ons that won't be deprecated through our new add-ons strategy
> in the next few months.
> 
> - That support page should also open in a background tab after the user
> updates to the version where groups are actually removed.
> 
> - By doing all this, we should limit the surprise when tab groups are
> actually removed, meaning that the solution that converts tab groups into
> bookmarks is more acceptable. I'd still prefer a solution where we convert
> to windows if the user has fewer than, say 5 groups.
Joni, any chance you could take care of this?

For clarity, the current plan is for the feature to be removed in Firefox 45, and for the initial linking to this page to be uplifted to 44.
Flags: needinfo?(jsavage)
Blocks: 1221500
Sure thing, Gijs. I've set up a placeholder URL that you can use here: https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/tab-groups-removal

Following our usual process, we'd have the content up for 44 beta. If you need it for Aurora or Nightly, let me know and we get the content up sooner.

Do you have suggestions for preferred/vetted add-ons or other alternatives that we should recommend in the article?
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(jsavage)
Flags: needinfo?(jsavage)
(In reply to Joni Savage ("need info" me) from comment #2)
> Sure thing, Gijs. I've set up a placeholder URL that you can use here:
> https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/tab-groups-
> removal

Thank you!

> Following our usual process, we'd have the content up for 44 beta. If you
> need it for Aurora or Nightly, let me know and we get the content up sooner.

Yes, this will go into aurora/nightly and be linked from the UI for a number of users, so it seems like we should get it up ASAP.

> Do you have suggestions for preferred/vetted add-ons or other alternatives
> that we should recommend in the article?

I think Kris is likely to have better suggestions than me. Tab Mix Plus and Tree Style Tabs seem like obvious candidates.
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(kmaglione+bmo)
(In reply to :Gijs Kruitbosch from comment #3)
> (In reply to Joni Savage ("need info" me) from comment #2)
> > Do you have suggestions for preferred/vetted add-ons or other alternatives
> > that we should recommend in the article?
> 
> I think Kris is likely to have better suggestions than me. Tab Mix Plus and
> Tree Style Tabs seem like obvious candidates.

I agree Tree Style Tab is probably a good candidate. I don't think Tab Mix Plus would help Panorama users much, and I'd probably want to avoid recommending it for code quality and user experience issues.

If it comes to it, I'd really want to avoid recommending just about any tab add-on for code quality issues, since almost all of them work by liberally monkey patching our tab code using string substitution and eval. See Tab Utilities (which might once have been a good suggestion for Panorama users) for an example of what happens when they stop being obsessively updated. Or, for that matter, Tab Kit and Tab Kit 2nd Edition, which I think are better-engineered solutions to the same problems.


That said, these would probably be reasonable suggestions, but it would be a good idea to make sure they still work after Panorama has been removed before publishing:

https://addons.mozilla.org/addon/toomanytabs-saves-your-memory/ implements tab groups using toolbars, and stores them in Places rather than session store. Allows users to choose the number of tab toolbars, and display some subset of groups at any given time.

https://addons.mozilla.org/addon/showcase/ I think the UX of this is pretty terrible, and the wording on the first run page ("Firefox Showcase is a Mozilla Firefox extension") is problematic, but I think it may appeal to some Panorama users.


I think it may be a good idea to try to point people to non-tab-based solutions, though. Pocket solves a lot of the use cases of Panorama, and is already in the browser, for instance. And the bookmarks sidebar is probably a better solution than Panorama for a lot of work flows. Especially with the "Open All in Tabs" feature that most people don't know about.
Flags: needinfo?(kmaglione+bmo)
(In reply to Kris Maglione [:kmag] from comment #4)
> That said, these would probably be reasonable suggestions, but it would be a
> good idea to make sure they still work after Panorama has been removed
> before publishing:

We can't really do this. We're trying to land strings on 44, for which bug 1221500 needs to land on 44 ASAP. I don't want to land that patch on m-c before we have some kind of page up, because everyone on m-c will see a notification that points to that page, and the experience is going to be crappy if there's nothing on said page (and I suspect that tab groups usage is proportionally higher on m-c than on release, though I have not bothered to look for evidence for this hunch). We can't remove panorama before we warn about removing panorama. So in effect, this page is blocking everything else, and we can't block this page on "what happens when we remove panorama.

We should get a best effort up ASAP, and then we can iterate as we get more details.
(In reply to :Gijs Kruitbosch from comment #5)
> We can't really do this. We're trying to land strings on 44, for which bug
> 1221500 needs to land on 44 ASAP. I don't want to land that patch on m-c
> before we have some kind of page up, because everyone on m-c will see a
> notification that points to that page, and the experience is going to be
> crappy if there's nothing on said page (and I suspect that tab groups usage
> is proportionally higher on m-c than on release, though I have not bothered
> to look for evidence for this hunch). We can't remove panorama before we
> warn about removing panorama. So in effect, this page is blocking everything
> else, and we can't block this page on "what happens when we remove panorama.

Can we not test them with the patch to remove Panorama before it lands? I think that the chances of removing Panorama breaking any given tab add-on are pretty high, and if we're pointing people to potential alternatives as part of the removal process, we should *really* make sure those alternatives work when Panorama is gone.
(In reply to Kris Maglione [:kmag] from comment #6)
> (In reply to :Gijs Kruitbosch from comment #5)
> > We can't really do this. We're trying to land strings on 44, for which bug
> > 1221500 needs to land on 44 ASAP. I don't want to land that patch on m-c
> > before we have some kind of page up, because everyone on m-c will see a
> > notification that points to that page, and the experience is going to be
> > crappy if there's nothing on said page (and I suspect that tab groups usage
> > is proportionally higher on m-c than on release, though I have not bothered
> > to look for evidence for this hunch). We can't remove panorama before we
> > warn about removing panorama. So in effect, this page is blocking everything
> > else, and we can't block this page on "what happens when we remove panorama.
> 
> Can we not test them with the patch to remove Panorama before it lands? I
> think that the chances of removing Panorama breaking any given tab add-on
> are pretty high, and if we're pointing people to potential alternatives as
> part of the removal process, we should *really* make sure those alternatives
> work when Panorama is gone.

You're assuming the patch for the actual removal is written, or that it could be written very quickly. First I wrote the notification patch, next up is the migration patch (method/goal of which is still being heavily debated) and then I'll need to actually write the removal patch, which won't be entirely trivial.

In any case, AIUI we're not planning to get rid of gBrowser.visibleTabs, so I don't really know that there's anything else those add-ons should be relying on, if they're not (as you described elsewhere) literally loading panorama in a tab? What are you worried is going to break? Tim, can you comment?
Flags: needinfo?(ttaubert)
Hm, so maybe one thing I could do is ask to preland just the strings so that we get rid of the l10n pressure in bug 1221500, which gives us all a bit more breathing room...
Well, for one thing, a lot of add-ons do actually load TabView directly:

https://mxr.mozilla.org/addons/ident?i=TabView&tree=addons&filter=&strict=1

And even for the ones that don't, I wouldn't be entirely confident that they don't depend on some behavior that will change when it's removed. Tab add-ons tend to be fairly fragile, and if we're recommending any particularly to users of Panorama, I want to be particularly sure that removing Panorama won't break them.
Since we need to show users content ASAP, we've published a first draft here https://support.mozilla.org/kb/tab-groups-removal. We'll quickly make changes to the content as we go along.

The article recommends the following solutions (in this order):
1. Use the bookmarks sidebar
2. Pocket
3. Add-ons (rather than recommending a specific add-on, we're asking users to search AMO themselves. We can recommend specific ones after we've confirmed that the said add-on won't break, but we need to make sure users know to contact the add-on developer if they need support, since our support forum contributors might not be able to help them if something goes wrong.

Anyone can edit this SUMO page, but feel free to recommend any changes here if you don't have/want a SUMO account: https://docs.google.com/a/mozilla.com/document/d/1gdHQux6pukWRdbiWUjrYxQdA0LB6tOsy4dYLKHUq_rk/edit?usp=sharing
Flags: needinfo?(jsavage)
(In reply to :Gijs Kruitbosch from comment #7)
> In any case, AIUI we're not planning to get rid of gBrowser.visibleTabs, so
> I don't really know that there's anything else those add-ons should be
> relying on, if they're not (as you described elsewhere) literally loading
> panorama in a tab? What are you worried is going to break? Tim, can you
> comment?

Yeah, I don't think we should remove that API. That's a separate call and discussion should we ever want to do that. It also doesn't hurt us as much as Tab Groups does, from a maintenance POV.

(In reply to Kris Maglione [:kmag] from comment #9)
> Well, for one thing, a lot of add-ons do actually load TabView directly:

That's terrible but not unexpected. We will possibly break a lot of badly written add-ons... or maybe just some. My guess is that most of these try to check something in TabView to work around any weirdness that Tab Groups itself causes, rather than building upon its "API".

We should probably talk to the add-ons review team and let them know that they should mark add-ons referring to "TabView" in 45 as incompatible, or possibly broken. Shooting an email to the developers might be another thing we can do. But maybe not before we can give them a Nightly version to test against.
Flags: needinfo?(ttaubert)
(In reply to Joni Savage ("need info" me) from comment #10)
> rather than recommending a specific add-on, we're asking users
> to search AMO themselves.

That's probably a good idea, but I'm worried about your suggested search strings. Nearly all of the results for "tab groups" rely on Panorama, and "tab tree" doesn't include a lot of the more useful options. It might be better to just link to the tabs category:

https://addons.mozilla.org/extensions/tabs/

(In reply to Tim Taubert [:ttaubert] from comment #11)
> That's terrible but not unexpected. We will possibly break a lot of badly
> written add-ons... or maybe just some. My guess is that most of these try to
> check something in TabView to work around any weirdness that Tab Groups
> itself causes, rather than building upon its "API".

I'm pretty sure that, with the exception of the 3 or 4 that are referencing YUI TabView, nearly all of those are using TabView to do things like read/write/select tab groups. And it looks like most of them don't check whether it exists before trying to access it, so will probably break even if they don't use it for anything important.

> We should probably talk to the add-ons review team and let them know that
> they should mark add-ons referring to "TabView" in 45 as incompatible, or
> possibly broken. Shooting an email to the developers might be another thing
> we can do. But maybe not before we can give them a Nightly version to test
> against.

I think it would be a good idea to contact developers as early as possible. There don't seem to be that many add-ons in the list, so maybe Jorge can just email them directly.
Flags: needinfo?(jorge)
(In reply to Joni Savage ("need info" me) from comment #10)
> Since we need to show users content ASAP, we've published a first draft here
> https://support.mozilla.org/kb/tab-groups-removal. We'll quickly make
> changes to the content as we go along.

Thanks very much Joni, that looks great!

Regarding the "What will happen to my existing tab groups?" section, I thought it might be good to mention that we're also going to either restore background-grouped tabs into a separate window, or offer people the option to select tabs to restore to "normal" tabs at the time at which panorama is removed. I'm still looking at what is easily feasible here, but I've put a note in.

I also replaced the link for the tab group search per comment #12.

I thought the content looked great already, so I've pushed the notification as part of bug 1221500 to fx-team, so if all is well nightly users will start seeing those from tomorrow onwards.

Finally, I've put up preliminary patches for the actual removal in bug 1222490, including a try push, that we could use to test add-ons (and/or point add-on authors to as a way of testing their add-on).
(In reply to Kris Maglione [:kmag] from comment #12)
> (In reply to Joni Savage ("need info" me) from comment #10)
> > We should probably talk to the add-ons review team and let them know that
> > they should mark add-ons referring to "TabView" in 45 as incompatible, or
> > possibly broken. Shooting an email to the developers might be another thing
> > we can do. But maybe not before we can give them a Nightly version to test
> > against.
> 
> I think it would be a good idea to contact developers as early as possible.
> There don't seem to be that many add-ons in the list, so maybe Jorge can
> just email them directly.

Yes, I think notifying the developers is a good idea. I'd like to hold until this lands at least on Nightly, so they at least have something to test with.
Flags: needinfo?(jorge)
FWIW I kinda like Tab Groups, so I'm finding porting them into an add-on an interesting challenge.

Steps:
1 - refactor removed code (retro'd bug 1222490) into add-on form - almost done! [1]
2 - cleanup, modernization and some rewrites; I'm really not a fan of its jQuery-like approach :(
3 - migrate current data for a minimally seamless transition (waiting on bug 1221050)
4 - add my own personal touch for extras and new features :)

I'm sure I'll be able to do some of that while the removal patch is written. If it turns out ok, I'm sure it will be worth mentioning as an alternative for most current Tab Groups users; yes, I'm shameless. :P

[1] https://github.com/Quicksaver/Tab-Groups
(In reply to Luís Miguel [:quicksaver] from comment #15)
> FWIW I kinda like Tab Groups, so I'm finding porting them into an add-on an
> interesting challenge.

Thanks for your interest in porting it into an add-on! As mentioned in bug 1222550, I’m also an active Panorama user and I’d really like to see it continue as an add-on. I’ll keep an eye on your GitHub project, and eventually try to join and help out.
I just uploaded the final version of Tab Groups to https://addons.mozilla.org/firefox/addon/tab-groups-panorama/, it is now awaiting review, but I don't foresee any reason for why it shouldn't be granted (even if it isn't, I'm sure the reasons for it will be direct and I'll be able to tackle them quickly for the next version).

It seems stable and fully functioning so far; already a few people are using it and haven't raised any issues yet. I think it would be good to have a link to it in the removal article for existing users:

- it's restartless, so it can be used right away;
- it can be used already on any Firefox version still with its native TabView code;
- works just as fine in builds without Tab Groups (try-build from bug 1221050 comment 109) as expected of it;
- features and performance should be on par with native Tab Groups, if not better because I'm awesome and have no modesty; ;)
- if the add-on is installed before the user updates to Firefox 45, it will no-op the migration process from bug 1221050, everything (groups and tabs included) will stay as is and seemingly nothing will change for the user;
- those that install the add-on only after updating to Firefox 45 can still get their groups back easily, by using the backup file (created in the desktop by the migrator) in the add-on's restore function.
I have submitted some more suggestions for the article. Dietrich told me last night that the suggestion to use Pocket might not go over particularly well with folks who use tab groups... Verdi, do you want to take a look at the article? (I don't think you can see my suggestions until Joni approves them, but I could be wrong...)
(In reply to :Gijs Kruitbosch from comment #22)
> I have submitted some more suggestions for the article. Dietrich told me
> last night that the suggestion to use Pocket might not go over particularly
> well with folks who use tab groups... Verdi, do you want to take a look at
> the article? (I don't think you can see my suggestions until Joni approves
> them, but I could be wrong...)

... now with needinfo.
Flags: needinfo?(mverdi)
I agree that the Pocket suggestion should probably not be in there. Helping with this article is on my list to do before 45 moves to Aurora. Madhava and I were just talking about it this morning. I'll ping Joni and add some instructions for the tab groups add-on soon.
Flags: needinfo?(mverdi)
Hello, in the article 

https://support.mozilla.org/en-US/kb/tab-groups-removal

it is written:

"Open the sidebar, click the menu button, followed by *Sidebars* "

This latter *Sidebars* is not in the default toolbar or menu panel as a button, nor it is a menu entry. I think it would be better to open the sidebar with the Ctrl + B shortcut.

Thanks for your attention.
(In reply to Simon from comment #25)
> Hello, in the article 
> 
> https://support.mozilla.org/en-US/kb/tab-groups-removal
> 
> it is written:
> 
> "Open the sidebar, click the menu button, followed by *Sidebars* "
> 
> This latter *Sidebars* is not in the default toolbar or menu panel as a
> button, nor it is a menu entry. I think it would be better to open the
> sidebar with the Ctrl + B shortcut.
> 
> Thanks for your attention.

Ugh, this is a good point. Sorry for not noticing this initially. We could fix this with the shortcut or tell users to use the bookmarks menu button or the main menu to open it.

(In reply to Verdi [:verdi] from comment #24)
> I agree that the Pocket suggestion should probably not be in there. Helping
> with this article is on my list to do before 45 moves to Aurora. Madhava and
> I were just talking about it this morning. I'll ping Joni and add some
> instructions for the tab groups add-on soon.

FWIW, I added links and got Kadir Topal in #sumo to approve my changes today before nightly went out. So there are links now. However, I haven't attempted to rewrite much otherwise (though I took out the "because it isn't used" claim about the removal as well, because it's a bit misleading). It would be great if you could look at how the article could be "properly" improved, also taking Simon's feedback into account.
I've seen someone mention (somewhere I can't find anymore...) the inclusion of some kind of "what to do with the tabgroups backup file" instructions in the SUMO article. The next version (1.0.1) of my Tab Groups add-on will have a "Load Migration Backup" button that will automatically fetch the migration backup file and load it in its restore panel, so users can quickly import back their groups from before the update. It might be worth mentioning this somewhere.

The attached screenshot is only to show you what I mean. If you'd like to include a screenshot of this in the SUMO article, I'm sure it might be worth getting a better one. ;)

Also, to reiterate from my previous comment, the add-on no-ops the migration if it was installed before updating to Firefox 45. Which means this button will only be visible to users that install the add-on _after_ updating to Firefox 45, because only those will actually have the migration backup file.
can I ask why it's being removed in the first place. I use it extensively and find it solid even with FF upgrades

it seems like something that would not need much work to keep in line with upgrade (obviously I'm guessing here so correct me if I'm wrong)

I have started a "bug" to ask it to be kept in so I can see what feedback people give about removing it. if lots of people don't want it removed and it is a lot of work to give an alternative etc , can we please revisit why it's being removed

https://bugzilla.mozilla.org/show_bug.cgi?id=1231284
Blocks: 1232178
from comment 20: (OT)
>i request that you hold off removal until there's a working add-on with import facility.
>even better, that you reconsider this ill-considered decision

That's just what I had expected: a wording like the latter ("ill-...").

And I guess that's what's blatantly missing in the article: the REASON, the telling WHY.

You know how end-users think. They'd just reproach you developers of being cowards because you were not able to publicly state why the removal had to take place.

So by mentioning the reason why also in the public article that Joni started, you will easily keep the great part of the moaners muzzled and they'll learn why it had to be.

But a way like 
>thank you for trying it out! We are refocusing our efforts to make 
>Firefox even better. 

rather sounds like bad PR marketing manager lingo. Because according to their opinion, you haven't made FF "even better" but "even worse".
They'd rather find an explanation why in those support pages to quench their thirst for information about the matter.

Or why else do you deliberately want to keep the actual reasons a secret to the genera public?
I aim to write a longer blogpost about the reasoning. Updated text for the support page, written by Verdi (thanks!), is already pending. At this point I don't think keeping this bug open is going to be very useful, so I'm going to close it out as FIXED, considering we have a page now and it has content.
No longer blocks: 1232178
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
maybe you "didn't mean it that way" but it's not helpful I think to refer to people like me, who have liked the feature enough to ask questions about why it's going as "moaners"

so if we, the public as you call us make any queries, polite or otherwise that question anything to be changed in upcoming versions we are moaners

I must say I find your post very pejorative, to say the least
I'm restricting comments on this bug. Please see the bugzilla etiquette page ( http://bugzilla.mozilla.org/etiquette.html ) and please treat people - volunteers, employees, and end-users alike - with respect in future.
Restrict Comments: true
Article about removing panorama can be found at: https://support.mozilla.org/en-US/kb/tab-groups-removal, containing useful info about removal and how users can recover their tab groups.

Mark bug Verified as fixed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.