conex
conex copied to clipboard
kesselborn
show tab groups in an always visible toolbar above tabs (like TabGroups Manager)
(this came via mail, posting it here for visibility)
Sorry to write you out-of-the-blue, but I was reading some of your forum posts related to Firefox Tab Groups — and your interest in developing a Tab Groups-style add-on — and wanted to share an implementation idea with you before you got too far into a development project. Please forgive if I’m out of line writing you like this!!
So here’s my argument re: Tab Groups in browsers today:
If you ask browser users, "Why do you want tab groups as a feature?" they typically say, "Because I want a quick and easy way to organize my open tabs into logical named groups so I can work more efficiently.” They don't say, "Because I want to jump back and forth between an abstracted Panorama view."
Many Mozilla devs are fighting against Tab Groups feature requests because they think this means “reimplement Panorama,” which of course would be terrible. But even though Mozilla axed Tab Groups, users like us (as you rightly pointed out) still need some way to group tabs. And users like me find it frustrating to have to jump back and forth between a secondary, abstracted environment (Panorama) and the normal Firefox user environment anyway. We just want easy tab grouping. Many of us have several "workspaces" running at once, and need to quickly be able to jump between sets of tabs grouped logically.
I'd like to share with you a novel approach to Tab Groups that many developers aren't aware of, but that thousands of users have found ABSOLUTELY CRITICAL to their workflow. This basic idea blows Panorama out of the water.
Have you ever seen TabGroups Manager? https://addons.mozilla.org/en-US/firefox/addon/tabgroups-manager-revived
I cannot encourage you enough to check it out. It only runs in Firefox 54 and below, though (breaks in 55+), so be sure to try it in an older browser.
(1) The most important feature: The add-on allows the user to see persistent Tab Groups all the time in one browser window, without clicking a button or changing contexts. It creates one level of hierarchy (Tab Groups) which are represented as an extra bar in the tab area. (Please see the screenshots on the add-on page.) This allows the user to organize Tab Groups directly in the main browser window view, without having to flip to a secondary "Panorama" screen. The groups are always persistent on-screen. The user can create hierarchy, name the groups, and manage tabs (drag-and-drop between tab groups) in a quick, convenient way that provides visual context at all times. (2) Secondary feature: The add-on allows the user to hibernate tab groups to improve performance. (3) Most importantly, it resolves the weird paradoxes and inconsistencies with Panorama. The tabs are simply grouped in nested hierarchy. That’s it.
The problem is, Panorama has sullied the concept of Tab Groups for too many developers and muddied the etymological waters of tab grouping. Users who wanted Tab Groups indeed used Panorama (terrible implementation as it was) - often in combination with add-ons which extended its functionality to make it actually useful - because when Mozilla forced its will in implementing Panorama as the solution for tab grouping, there were no other options. So users made do with Panorama. Now that it's been axed, that's why many users who liked some sort of tab grouping feature are shouting for its return. Maybe they don't fully realize that it's not "Panorama" (poor implementation of Tab Groups, but the one that they recognize) that they want, but simply a useful implementation of Tab Groups. To me, it doesn't make sense to now be forced to have tabs completely disorganized, which is the current new paradigm in Firefox.
The concept behind TabGroups Manager is an incredible workflow booster. Of course, the add-on will no longer work in Firefox 57+.
My suggestion for anyone implementing new Tab Groups functionality for Firefox, whether core browser code or webextension add-ons is: Please implement this concept of “in-one-browser-window, always-visible, one-level-of-hierarchy” tab grouping.
Creating a toolbar as the TabGroups Manager did is currently not possible with WebExtensions (see bug above).
Regarding Panorama: my addon is not very cleverly named, as I do not plan to create a Panorama-View for changing tabs -- it rather opens a popup where tab groups are visible and you'll have the possibility to search for tabs + history (and later bookmarks). See https://www.youtube.com/watch?v=Y5HVCDHGg0s for a video of how it looks like (it's a little bit older already).
So: changing groups is a click or keyboard-shortcut away. I am as well looking into having the same popup view as a sidebar, which would make it permanently visible on the side (vs. top, horizontal view).
Re:
If you ask browser users, "Why do you want tab groups as a feature?" they typically say, "Because I want a quick and easy way to organize my open tabs into logical named groups so I can work more efficiently.” They don't say, "Because I want to jump back and forth between an abstracted Panorama view."
Although I agree that the "panorama-view" is not useful (which is why I currently don't plan to implement it), I think its very brave to assume that the answer of "browser users" when asked about TabGroups matches your preference. If you look at Safari's "Show all Tabs" implementation, I would love to have something like that if it could be done so nicely and so fast in Firefox ... that + keyboard support + tab groups of course.
In general I think it would have been better style to not slash panorama and Mozilla's motives behind it so much as it paved the way for something like tab groups in the first place. I would not be surprised if other people preferred panorama's implementation to something lile TabGroup Manager.
Sorry: had to say this :) ... apart from that: thank you very much for the input.
Thank you very much for opening this discussion!
Well, I talk to quite a few browser users in my line of work. Most people, when dealing with lots of tabs, "just want a way to organize them." And the reason that Panorama ultimately failed wasn't that people don't want tab organization; it failed because the feature was hidden and obtuse to use. You had to remember that something completely hidden was there, and then drag around tab representations into group blobs. Not so good.
I think the biggest reason why Tab Groups need to (at least optionally) be permanently visible in the main browser window is (a) so that it's super-quick-and-easy to use; (b) you can see at all times which group context you're in; (c) you can immediately see all other available groups for switching contexts and for moving tabs into a different group; (d) users will remember the feature and the tabs in other groups not currently visible. If Tab Groups were immediately apparent in the interface and users could quickly switch tabs between them without jumping into a hidden menu, then of course the feature useage would go up tremendously.
My basic point is: People frequently say something like, "Wow, I have too many tabs open. I don't even know what to do with them." And Panorama was too difficult and abstract for people to use. But people are familiar with folders, etc. If Tab Groups is implemented well (like TabGroups Manager did), they would see Tab Groups like folders for their tabs and use them.
I like your ideas a lot and look forward to seeing what you implement!!
Analysis
"Wow, I have too many tabs open. I don't even know what to do with them."
This hits the nail on the head. The fundamental value of tab groups is their ability to get some tabs out of your way without losing them. There are other ways to do this, but their interfaces are worse:
-
Bookmark + close lets you save a tab for later, but old bookmarks become clutter to deal with.
- Conclusion: we usually want to store tabs only temporarily, until we come back to them.
-
Snooze Tabs & Pocket** allow saving tabs temporarily, but are so much work that I never used them.
- Conclusion: we usually want to hide and restore groups of associated tabs at the same time.
-
Profiles allow saving/restoring groups, but are too much work to administer (specifically creation).
- Conclusion: groups should be quick to create and should share most settings.
-
Browser windows are quick to create and share most settings. However, there's too many groups to open a window for each without cluttering the desktop/taskbar, and there's no way to close/hide a window so it can be restored later.
- Conclusion: it's important that groups can be hidden and [still] persist across sessions.
This brings us to containers, groups of tabs that share preferences and persist across sessions. Sharing so much with tab groups, they feel like an organizational tool. However, they were designed as a privacy tool, like profiles for a single user. This causes conflict: there are tabs that I'd like to be hidden and shown together, but isolated from a privacy perspective (for example, search engines and any other site).
At the same time, a lot of the time containers and groups do overlap. If I have a bunch of open tabs on a single site, I'd often like to be able to hide them together. And there's nothing wrong with creating multiple containers for the same site for organizational purposes (ex: I have multiple github containers for different projects).
Action
Ideally, instead of trying to add an additional level of organization/abstraction, I'd like conex to integrate into one that already exists: browser windows. I think they are already a great interface for groups: They are visual, support drag & drop, and have great performance and OS integration (for example, they allow allow viewing two groups on different workspaces, alongside different applications); In many ways, they're more convenient than panorama was. Moreover, they interact with containers in a way that makes sense -- it's even possible to move a tab between them without any privacy risk. Added bonus: you don't need to find a new unique shortcut to create new groups.
Browser windows are missing a few key features, in order of importance:
- Hiding windows and persisting them across sessions.
- Naming windows so you can easily switch between them and know which to restore.
- An easy way to move tabs between windows in bulk (ie, initial creation).
- The official containers addon helps with this, with "move tabs to a new window", but not...
- An easy way to collapse two windows back into one.
- A context menu and/or keyboard shortcut for moving tabs between windows, if they're on different workspaces.
In my ideal world, instead of trying to shoehorn containers into being both a privacy and organizational tool, conex works to make browser windows be actually useful and integrate better with containers. I'm not sure exactly what that looks like and I've spent far too long on this post already, so I'll leave it here for now.
Thanks for the detailed input. I don’t really want to argue against your points because I mostly agree with you.
Taking the pragmatic point of view here, I see mainly two problems that make this solution not feasible at the moment:
-
the points you listed above would all need to be implemented before conex could become usable and that is a lot of pre-conditions
-
you need a OS with a decent window management. Though this is the case with Linux, it certainly is not with macos — I tried to go down this road before and it’s not feasible. As I am tailoring conex to my needs ;) relying on good Window management won’t work as macos is my daily driver.
On a neutral point: it would make conex usage different on different OSes which can be seen as a con but perhaps as well as a pro (using the native OS functionality)
you need a OS with a decent window management
Dealing with too many windows of the same application is a pain on any OS/DE I've used, though perhaps a rolling environment like i3 would do better.
I didn't get into the specifics of what "better window/container integration" means because I'm not entirely sure. I'm still not, but the little thinking I've done overnight suggests that it's not actually that different from what tab groups did, except you can think of a hidden group as a window that's not being drawn at the moment, and drop panorama in favor of allowing a tab group to be popped out into its own window, at which point you can drag and drop tabs between windows/groups that way.
Do webextensions provide an api for opening and closing windows?
Sure .. it’s possible. As I said: I went down that route as a work around for hiding tabs: just move all non-visible tabs to one window and the ones that should be shown to the current window (it’s perhaps in some branch still), which is similar on a technical level, but the experience wasn’t good. I think even minimizing and maximizing windows is possible, but sure anymore though.
Am 10.10.2017 um 14:52 schrieb smichel17 [email protected]:
you need a OS with a decent window management
Dealing with too many windows of the same application is a pain on any OS/DE I've used, though perhaps a rolling environment like i3 would do better.
I didn't get into the specifics of what "better window/container integration" means because I'm not entirely sure. I'm still not, but the little thinking I've done overnight suggests that it's not actually that different from what tab groups did, except you can think of a hidden group as a window that's not being drawn at the moment, and drop panorama in favor of allowing a tab group to be popped out into its own window, at which point you can drag and drop tabs between windows/groups that way.
Do webextensions provide an api for opening and closing windows?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
I will sleep on this for a few days and then make some mockups suggesting an interface for switching between tab groups. When I do, should I post them here, in #9, or in a new issue?
Really interesting reading all the thoughts here.
I just want to chime in and say that an interface that allows for one level of hierarchy (basically "folders" for tabs) still remains my favorite UI implementation of tab groups. The best and most functional example I've used is https://addons.mozilla.org/en-US/firefox/addon/tabgroups-manager-revived.
I understand that a tab group bar like that is not likely in the short-term given the current state of Mozilla bugs, but I still believe it's the quickest and easiest way to manage tabs in the long term. It just works.
I like it on a desktop, but on a laptop, I'd prefer something more like the Tab Groups addon; my vertical space is ~~previous~~ precious!
edit: fix autocowreck
Yes, all of our tab vertical and horizontal spaces are "previous" (to FF57+). j/k :)
You're right about the different environments. I'm a big proponent of the tabgroup bar being an option. For those on mobile and smaller-format devices, something like Tab Groups (Panorama) could remain. But I would like to have the option for a persistent, drag-and-drop tab groups interface for desktop.
my addon is not very cleverly named, as I do not plan to create a Panorama-View for changing tabs
That's unfortunate, I find panorama view very useful for grouping tabs. It's probably annoying for switching between tab groups though.
Panorama view is a lot more effort to implement, so I suspect you won't see it from this extension. However, I wouldn't be surprised if someone else made an extension that is only a panorama or other visual way of moving tabs between containers.
yeah: it's basically my lack of good frontend foo. It probably is not even so much work if you are a html/css/js native. Still: @suhr what was the most useful aspect of this view? Being able to drag/drop tabs to another group? Or seeing more that one tab group at a time? Just curious if drag/drop support in the current conex popup would be sufficient. Thanks for your input
@kesselborn To see the whole tab group at once, visually (as pictures), and be able to drag&drop these pictures to other tab groups.
Just curious if drag/drop support in the current conex popup would be sufficient.
Unfortunately, no. I'm a visual thinker, so I rely on seeing a lot. Panorama allows you to see, that's why it's so great.
Presuming the Toolbar WE lands I'd like to point out that having tab groups below the URL bar as opposed to above the tabs has some nice UX features. For these reasons I preferred Tab Groups Button's toolbar.
- You want tabs at the top because switching tabs is a more common action than switching tab groups and Fitt's Law.
- The URL bar works as a necessary buffer between tabs and tab groups. An excessive buffer is otherwise necessary between the tabs and tab groups to prevent miss-clicks due to the minimal vertical separation. Such miss-clicks are significantly more disruptive and disorienting than most other browser interactions due to the page and tab bar changing unexpectedly.
Note to self:
- https://wiki.mozilla.org/Add-ons/Projects#New_WebExtension_APIs
- https://bugzilla.mozilla.org/show_bug.cgi?id=1215064