Browser-Design Experiments (2010–2017) #3

Ubiquitous Firefox, Part 2: Solving Tab Proliferation (Mozilla Labs, 2011)

Merging tab history with the scrollbar.

This post is part of a series of experiments in redesigning the Web browser. In all of these designs, the primary problem I was solving is that of ‘too many tabs’. In this design, from 2011, I was attempting to solve this problem while reducing browser chrome as much possible.

I had originally posted this on Mozilla’s usability list. Mozilla Labs then asked me to write a couple of blog posts about it as part of their Community Concepts series. This is the second of those posts.

The Problem: Too Many Tabs!

Continuing our quest to remove debris from the browser, I’d like to discuss two related issues. The first is the issue of Back/Forward. As many comments pointed out, Inline Tab History doesn’t replace the Back/Forward drop-down list, leaving it difficult to jump quickly to a specific page in a tab’s history.

Before addressing that issue, I’d like to address a more fundamental problem: tab proliferation. If you’ve ever found that you have just too many tabs open, you’ve experienced this problem. The tab bar becomes cluttered, tabs get hidden past the ends of the tab bar, and it’s hard to keep track of the relationship between tabs.

There have been numerous attempts to address this issue. Firefox 4 comes with Panorama (‘Tab Groups’), which does a good job of helping you organize all those tabs manually. The Tree Style Tab extension groups spawned tabs with their parents, thus bringing some order to all those tabs. And Mozilla Labs’ Home Dash figures out for you which tabs are related and groups them together. These efforts and many others provide some valuable insight into the problem. But what if we could prevent tab proliferation at its source?

Where Did All These Tabs Come from?

We can identify two types of tabs: tabs that were opened on their own (original tabs), and tabs that were opened from other tabs (spawned tabs). The former type consists of sites like your e-mail, feed reader, social networking site, and search engine — sites that you open directly. The latter type consists of pages that are opened in new tabs from pages in the former class. For example, you click on a link in your e-mail, or open a news item in new tab. It should be fairly evident that the biggest source of tab proliferation is spawned tabs.

Consider this classic xkcd comic:

xkcd: The Problem with Wikipedia

The top-most node in that tree is an original tab, while all child nodes are spawned tabs. Every single node is a tab that was opened at some point, spawned some tabs of its own, and then closed. That’s a lot of tabs! It’s also a lot of opening and closing — tab management that you shouldn’t have to deal with.

How would the tab bar look during such a browsing session?

You start off with the original tab:
[ A ] +

While you’re reading a page in that tab, you come across two interesting links, so you open them in new tabs (italicized):
[ A ][ AA ][ AB ] +

When you’re done with A, you close it and move on to AA:
[ AA ][ AB ] +

But AA itself has three interesting links!
[ AA ][ AAA ][ AAB ][ AAC ][ AB ] +

‘Oh dear! I shall never get to AB at that rate!’ But you plow on anyway. The sequence continues in a manner similar to this, spawning and closing tabs as you travel rightwards along the tab bar. Eventually, if you’re lucky, you manage to close every single tab, ending up on AB (or ABCDE, or wherever you finish). Of course, not all tab-heavy browsing sessions yield such deep trees. Some have more breadth, with one page spawning a great many pages.

Note how this system reveals yet another fundamental problem: the Back/Forward system is broken. Back/Forward is inherently linear. That’s fine as long you remain within a tab; this is how people browsed the Web when these buttons were first introduced. But this type of tabbed browsing is two-dimensional. For example, AA and AB are not opened within A, but are each opened in new tabs, while A is closed immediately when you’re done with it. Thus, both AA and AB have A as their ‘back’ page. And these tabs rarely stick around long enough to develop their own internal history, The Back/Forward history is, therefore, a poor representation of where you’ve been and where you’re going. The tab bar, on the other hand, provides a visual indicator of where you have to go (while the Recently Closed Tabs list tells you where you’ve been). The tab bar has almost come to replace Back/Forward during these types of tab-proliferating sessions.

But is this type of browsing necessarily two-dimensional? After all, you’re not likely to read AA and AB at the same time, but in a certain sequence. What if we rearranged the tree in reading order?
A → AA → AAA → AAB → AAC → ⋯ → AB → ⋯

This linear order is identical to the order that the tabs appeared (and later disappeared) on the tab bar.

The Solution: Tab History as Queue

My proposal to fix all the above problems is the History Scroller:

The History Scroller (annotated version)

This builds on the ideas from Part 1, especially Inline Tab History. To recap, in that design, the pages in a tab’s history are all displayed in the content area arranged vertically. Additionally, each page gets a header with a favicon, its location, and other useful metadata. The header is attached to its page, so that it scrolls together with it. (If you’ve ever used Google Reader or Google Groups, this design is similar.)

The History Scroller combines the Back/Forward history with the scrollbar at the right of the interface. It is a visual representation of the tab’s history, with the favicons for each page shown in order. The current page being viewed in the content area is highlighted visually. This highlighting is done both in the scroller and in the content area (both with a darker border in the mockup), so you know which page is active. All other pages, meanwhile, are frozen and their resources managed by the browser.

Overlaid on the current page in the scroller is an indicator for where you are on that page. This is essentially a replacement for the scrollbar. (Ideally, the design should be along the lines of the ‘Content-Aware Scrollbar’.) Above and below the current page are the most nearby pages in the history. The scroller may also be scrolled in order to see more of the history. Hovering over any part of the History Scroller shows the page titles for each page (as seen in the mockup), making it easy to find the right one. (This touch was inspired Bret Victor’s Scrolltabs demo.) Clicking on any item will quickly scroll the content area to that page, preserving the previous location on that page.

When you click on a link, this new page is opened and displayed below the current one and the content area scrolls to the new page. You can, however, interrupt that scroll by scrolling up, leaving the new page unread. You get the same result from middle-clicking the link, which adds a new page to the history without scrolling to it. Unread pages are also indicated (they have a darker background in the mockup), so you don’t lose track of what you need to read, in case you go back or skip around. They are also loaded fully and then frozen, so they don’t continue running until you view them.

If you spawn several pages from one, they are added to the history in the order of being spawned. Together with the current page, these pages are highlighted separately as the active page group (the darker border in the mockup). This indication tells you where each new page will appear. Spawning these page won’t suddenly remove any history items below them (in the “Forward” history), because the Forward history is immutable. Thus, if you go back to a page and follow some link, the Forward history won’t suddenly disappear, like it does now. Similarly, if AA is followed by AB and you open a couple of pages from AA, AAA and AAB will appear between AA and AB, leaving AB untouched (and unread).

Since the tab history is now a representation of your reading queue, it makes sense to allow this queue to be reordered, in case you want to read pages in a different order than the how they were opened. Pages may, thus, be moved up and down in the history. Pages can also be transformed into new tabs by dragging them to the tab bar, for those situations where you need to keep a page open longer. Meanwhile, app tabs, being inherently permanent, get their spawned pages opened in a separate connected tab. (More thorough ideas for how to deal with web apps tabs are welcome.)

Finally, because the tab bar no longer represents a single page but a whole tab history and an entire browsing session, it no longer makes much sense to show the title of the current page. Instead, the tab shows the icons for the current page and the two surrounding pages. It would also make more sense to show this tab bar at the left side (like with Firefox for mobile).

To clarify further:

Solving the Tab Proliferation Problem (annotated version)

The tree diagram at the left arranges the nodes by reading order, with earlier nodes placed above later siblings. Collapsing that linearly results in an order identical to the result achieved through the new behaviour I’ve described. Note that this is identical to the order these pages would have appeared on the tab bar. What we’ve done is rotated the tab bar (the part with all the spawned tabs) and made it vertical, merging it with the tab history. This is made possible through a modification of the ‘open in new tab’ behaviour. In this new model, the tree remains unchanged. If you were going through the xkcd session, you would view and open those pages in exactly the same order. The big difference is that the browser now organizes them for you and makes your journey much clearer. You know where you’ve been, where you have to go, and how pages relate to each other. On top of that, you need not constantly be closing tabs as you go along. All you have to do is scroll down and the pages you’ve viewed are history. Meanwhile, the tab bar remains uncluttered and devoted to original tabs, allowing for a more organized tab bar (and Panorama).

Another way to view this new model is in terms of tab as task. The tab bar is devoted to separate potentially-simultaneous tasks, while the History Scroller for each tab is devoted to one mostly-linear task. The tab bar is for multitasking, while the History Scroller aids unitasking within each tab.

To summarize, by replacing the debris of the Back and Forward buttons with a more visual, informative, display of your content (the tab history), we were able to offer a solution for the problem of tab proliferation. Since the tab history is no longer hidden behind some buttons, we could update the Back/Forward behaviour to be more useful and more logical, leaving the tab bar no longer overloaded and cluttered. The Back button used to be more frequently used than the Forward button. In this new paradigm, however, we move forwards!

Conclusion: A Call to Developers

Tabbed browsing no doubt is not limited to the use cases I mentioned. How would this paradigm affect your own behaviour? Will it ultimately help (after a necessary acclimation period), or are there situations where this will make the browser less useful?

Moving on, what we need is a few extensions that demonstrate and test some of these ideas. Each extension should implement a feature that could stand on its own. These are, in order of importance:

  • New Back/Forward System. This extension will modify the new-tab/middle-click behaviour as I’ve described. Spawned pages will appear in the Forward list, and that list will always be maintained, so that the Forward history never gets overwritten. This extension will not modify the interface in any other way;
  • The History Scroller. This will modify the scrollbar in the way outlined above. It will display tab history, whether the history has been modified by the previous extension or not;
  • Inline Page Info. When combined with LessChrome HD, we can create an interface similar to the mockups while keeping the location bar. Later on, this can be expanded to display Inline Tab History.

Note how none of these extensions would rely on Ubiquity. We can create most of this design without removing the location bar. Ubiquity integration (and permanent removal of the location bar as it is now) can wait until it’s ready.


A few of the ideas in Part 1, specifically those of applying monotony to Ubiquity and of adding a new command, have previously been described by Jono Xia, one of Ubiquity’s developers. Jono deserves credit for discussing these ideas publicly first.

The above was based on a much longer piece. The adventurous are invited to visit the Mozilla Wiki for more details.