One of the latest features to land on the trunk of the mozilla-central source code repository—what will eventually become Firefox 3.1—is a new mechanism for switching between tabs in Firefox when using the Ctrl+Tab and Ctrl+Shift+Tab shortcut gestures.
In Firefox 3.0 and earlier, pressing Ctrl+Tab brings the tab to the right of the currently visible tab into focus, and pressing Ctrl+Shift+Tab brings the tab to the left into focus.
One major problem with this interface is that it’s usually modal: the user’s locus of attention is often focused on the page they want to see, rather than the location of the desired page relative to the current page in the tab order. As a result, switching to another tab with the keyboard usually just involves repeatedly pressing Ctrl+Tab until the content the user wants is in front of them. Sometimes the user may overshoot and then have to press Ctrl+Shift+Tab to backtrack.
Another downside of this approach, as Jenny Boriss has noted, is that the user has very little information about what’s actually contained in an unfocused tab; all they really know is the name of the page and its icon.
The new Ctrl+Tab interface in the Firefox trunk tries to solve some of these shortcomings.
Assume that you arrive at a computer that has Firefox open with three tabs loaded in it named “Wikipedia”, “Google”, and “About Ubiquity”, in that order. The Wikipedia tab is the one that’s currently selected, and you want to go to the next tab, which is Google. Holding down Ctrl and tapping the Tab key results in the following:
The first thing you’ll notice is that the current tab you’re on is still Wikipedia; the overlay in the center of the screen indicates that the tab you’ll go to if you release the Ctrl key is the “About Ubiquity” page, which is two tabs to the right of the Wikipedia tab, and that tapping Tab once more before releasing Ctrl will bring you to the “Google” page that you want to go to. You may be puzzled as to why the overlay in the center of the screen doesn’t reflect the same ordering as the tabs at the top of the browser.
Here, the user interface is following in the footsteps of a similar feature from windowed operating systems like Mac OS X and Windows to navigate between active applications. The order of the thumbnails is based on how recently you’ve visited them, which makes it easy to quickly switch between two places. In the above example, this means that whoever used this computer before you was on the “About Ubiquity” page before moving to the Wikipedia page.
This change is probably based on the premise that the last-visited tab is more frequently the user’s locus of attention than the tab to the left or right of the current one, which is probably true. But the same core problem remains: the last page that the user is on isn’t always their locus of attention. Indeed, unless someone is rapidly switching between two places, most people don’t even remember the last web page they were on; even less relevant is the second-to-last web page they were on, and the ordering of anything older than that looks like randomness. What this means is that for the particular use case of quickly switching between two tabs, this new mechanism is non-modal, and indeed quite efficient. But for all other cases, this interface is modal, because the same gesture is resulting in a different response based on a part of the browser’s state (i.e., tab-viewing history) that not only isn’t the user’s current locus of attention, but also isn’t even knowable to the user until they press Ctrl+Tab—and even then, the user can only see three tabs at a time in the overlay, even if more are open in the browser. At least with the previous mechanism, one could look at the tab bar to infer what the results of pressing Ctrl+Tab would be.
So, in the case where the user isn’t going back to the tab that they were just at very recently, they’re stuck in the same kind of situation that they were in with the old Ctrl+Tab mechanism: just keep pressing Ctrl+Tab until the page you want shows up. But this brings up another problem with the new interface: the end-user is only presented with thumbnails. In the old Ctrl+Tab mechanism, at least I was presented with each full-sized page every time I pressed Ctrl+Tab so that I could see if it was the one I wanted; here, I’m relegated to looking at a tiny thumbnail of the page, which only serves to make the task that much more difficult.
All of this is to say that I think the new Ctrl+Tab interface is really more of a trade-off than a decisive improvement: in the case where I want to go back to the tab I was just at, it’s great—although the thumbnails are completely unnecessary—but in most other cases, it’s actually harder to use than the old interface.
I haven’t thought much about possible solutions; one band-aid is to create a hybrid of both mechanisms, for instance by bringing the currently-selected tab to the foreground in the new Ctrl+Tab interface but still providing thumbnails for the next and previous tabs in an overlay. If anyone else has ideas, I’m sure the Mozilla community would love to hear them.