There’s been a lot of discussion at Mozilla lately about the keyboard shortcuts for switching tabs, and how to improve them:
- Boriss talks about why the new behavior is being proposed for addition.
- Atul talks about the trade-offs between the old behavior and the proposed new behavior.
- Aza Raskin throws his hat into the ring with some analysis based on information density.
- Boriss takes inspiration from application-switching shortcuts in the operating system in looking for ways to improve the new proposed behavior.
In this post I’ll add my two cents to the discussion.
First, if you’re using Firefox, and you have several tabs open, please try holding down the ctrl key and tapping tab a few times, just to see what happens. Go ahead, try it right now. Come back to this page and keep reading after you’re done.
If your Firefox is version 3.0 or older, what should have happened is that each time you tapped tab, Firefox switched to the next tab — meaning the tab to the right in the tab bar. Let’s call this the “old tab behavior”.
If you are using the brandest-newest cutting-edgiest version of Firefox, you would see a transparent overlay with up to three thumbnail images in it, of three of your tabs. Each time you tapped tab, it would change the hilighted thumbnail, but it wouldn’t change anything in your main Firefox window until you released ctrl. Another difference is that the tabs in this mode are ordered by freshness, i.e. by how recently you looked at them, which may be different from the left-to-right ordering of the tabs at the top of the Firefox window. Let’s call this the “proposed new tab behavior”. In case you haven’t seen the very latest Firefox yet, here’s what the proposed new tab behavior looks like:
Proposed new tab behavior
In my opinion, there are serious problems with both behaviors. Personally, I find both of them too hard to use. I still rely on clicking through the tabs with my mouse.
But as more and more of my data moves to web-applications that I want to keep open, as I rely on tabs more and more, and as the number of tabs I have open grows and grows, I waste more and more of my time hunting for the tab I want. I don’t think I’m alone in this. We need a decent keyboard-based alternative for tab navigation, and we need to get it right.
I don’t want to have to waste any brainpower thinking about the navigation method. My mind is on the contents of the tab that I want to get to. I want to be able to keep my mind on the contents, wiggle my fingers somehow, and be there. That’s what using the ideal interface would feel like. Both the old behavior and the proposed new behavior fall short.
To be specific, there’s three problems I can see with the current behavior. First is that it’s not discoverable. Unless someone tells you, you would never know that there’s a way to move between tabs other than clicking on them. I’ve been using Firefox for years but I didn’t know about the ctrl-tab shortcut until a few days ago!
The second problem is that the key mapping is not natural. Ctrl-tab moves you to the next tab to the right. Shift-ctrl-tab moves you to the next tab to the left. Although this keeps with the tradition of using the tab key to move ahead by one field in a form, and using shift-tab to move back by one field, the tradition itself is highly arbitrary. There’s nothing natural about using tab and shift-tab to mean right and left, respectively, nothing about them that helps the user guess what they mean. Even after a user learns what ctrl-tab means, there’s no guarantee that they’ll figure out that shift-ctrl-tab means the opposite.
The third problem is lack of visual context. You can only see the contents of one tab at a time; the rest of the tabs are just names (often abbreviated) and favicons. Each time you hit that tab, the main window contents change suddenly. If you hit it several times rapidly, the visual effect is very confusing. It’s hard to keep track of where you are and even harder to figure out where you’re going. It’s very easy to fly right past the tab you wanted, and have to either use ctrl-shift-tab or (more likely) take another trip all the way around the merry-go-round.
The new proposed behavior is an attempt to fix the visual context problem, but as atul pointed out, it’s not clear that it’s an improvement: you can only see three tabs, they’re thumbnails instead of full-size, the order of the tabs is different from what you see in the tab bar, and it’s indirect, in that you’re controlling a separate little voodoo-doll representation of your browser tabs outside the main window instead of controlling the browser itself.
I’m thinking about ways to provide more visual context, including more than three tabs, in a way that feels directly connected to the main browser window contents and the tab bar. Because I’m not smart enough to figure out any of the image-editing software on my computer, I made some mockups with pen and paper.
Lousy pen drawing of tab behavior idea, 1 of 2
Here’s a very simple idea: when the user holds down a modifier key, the contents of the current tab shrink down to a smaller sub-window in the middle of the browser window. The tabs to the left and right of the current tab (going by order in the tab bar) go into their own sub-windows that are shrunken and skewed to create the illusion that they are folded back into space. Tabs further to the left and further to the right are shrunken and skewed even more to fit them into the edges. In the above mockup there are five tabs shown, but we could squeeze in an arbitrary number: the next tab to the right takes up half of the remaining space in the right margin, the next tab after that takes up half of the space that’s still left, and so on. They just get smaller and smaller as they approach the edge of the screen.
I propose using the left and right arrows to move between tabs. That is, holding down a key combination (say ctrl + alt) shows you the screen above; hitting the right and left arrows while holding down the key combination moves to the next and previous tabs; and releasing the key combination returns you to the normal view, with the currently centered tab becoming full-screen.
Below is a simple variant of the same idea, where the sub-windows are allowed to spill outside the bounds of the main browser window. This is a bit unorthodox, but perfectly doable technically. We could resize the sub-windows using the same “half of the remaining space” algorithm, but adjusted for the edges of the entire screen instead of just the edges of the browser window. If the browser window was already full-screen, it would revert to the previously described behavior.
Lousy pen drawing of tab behavior idea, 2 of 2
This is all just a minor and limited improvement. It helps to provide a bit of visual context, so that when you’re switching tabs you can see what’s coming up before you get to it, and because it uses the left and right arrow keys it provides a slightly more natural mapping. It doesn’t help with the discoverability problem. Also, it remains loyal to the order of the tabs in the tab bar, when in fact this order is nearly meaningless most of the time. There may be better ways to navigate tabs that aren’t based on this order. Finally, it only uses two out of the four arrow keys, and doesn’t make good use of the vertical space of the screen. Could we improve it by adding a second, vertical direction of navigation and using the up and down arrow keys?
I’ve got some more ideas brewing to show you next time, complete with more crummy pen drawings, but in the meantime I hope you’ll play around with tab navigation and think about the many ways that it could be improved.
Not The User's Fault 
August 21, 2008 at 3:30 am
A few points:
* In the Ctrl_Tab extension for FF3 at least, the visual tabs are activated by the small box to the right of the tab-row; this makes it quite discoverable
* Your vision is kind of like how Vista pages through open windows. But isn’t the OS X Expose superior? Where you see all the windows shrink down to large thumbnails. To make the inactive tabs recede in the background draws attention away from the things I am looking for (a different tab), and towards the thing I already know about (the current tab)
August 21, 2008 at 3:53 am
Hey Jono – there are some good thoughts in here, but I think that while the mapping to tab locations is cleaner, you aren’t improving the key problem which is that browsing between 2-3 items isn’t really all that much quicker for the user.
August 21, 2008 at 5:42 am
> Also, it remains loyal to the order of the tabs in the tab bar, when in fact this order is nearly meaningless most of the time.
That order wouldn’t be half as meaningless if new tabs (when opened from links) would open right beside the current tab, creating a somewhat natural way of grouping related tabs together. Most decent tab related extensions do this – as well as IE7. Such behavior might also improve the chance that when a tab is closed, the next selected one might be the next one the user wanted to see anyway (e.g. in the use case of opening multiple tabs at once from a page and then reading through all of them).
IOW: Instead of focusing on how to best switch tabs, we should also ask the question about what we can do so that users won’t have to switch tabs all that often to start with.
August 21, 2008 at 5:51 am
Each method of iterating through tabs in a certain order has major flaws. Therefore I can’t help but think there’s something fundamentally wrong with the underlining representation of the tabs – ie, how tabs in the tab bar are organized.
Fix that, and you fix all these problems arising because of it.
Otherwise its just going to be a band-aid solution that will need to be fixed again in the future.
August 21, 2008 at 7:35 am
Just a common user, but …
I guess I’m one of the people who never figured out the ctrl+tab thing for Firefox –
– I’ve tried cmd+left/right, which is what I use for Adium and most intuitive for me
– I’ve tried cmd+~, because I think of tabs as little documents, and that’s how I scroll through my Word docs on a Mac….
– And you’re right, I could never remember that shift-tab is to go backwards. And even if I did, I would still have to contort my hand in painful manners to do a u-turn. (On the other hand, tabbing has become pretty instinctive to me)
As for the many proposals…
I don’t like any of them. The infinity-scrolling idea reminds me of the iTunes album flippy thing. It feels too sequential, and it sacrifices an all-in-one view sort of efficiency with flashy visuals. (As in, I’d prefer the current “look at all of the tabs in the tab bar and pick” versus “scroll through flashy different-sized-thumbnails and pick”)
I guess ideally I would be able to look at all of my tabs in a spatial way (that can be rearranged by me), and pick one just by wiggling my fingers (MAGIC!!), without disorienting myself in the process.
Maybe, as there gets to be more widescreen computers, there can be something on the side? Say if I hold down “Tab”, an area appears to the side that has all of my tabs (with, say, title, sequential number, and a little thumbnail). While I have Tab held down, I can either press the sequential number displayed, or start typing part of the name. And as I start typing, the possible tab candidates would be highlighted. And I release Tab when only the one I want is highlighted. So if I have 12 tabs, when I hold down tab, I get little thumbnails of them all on the side. If I want number 11, I’d hit 1, and tabs 1, 11, 12 would be highlighted. When I hit 1 again, only 11 would be highlighted. Then I release Tab. (I think I’d prefer highlighting rather than the other ones disappearing, because then I can always backtrack). And if I want to rearrange the tab order, I can just hit Tab and then click+drag with my mouse (I can even clump tabs together spatially — you can assign the sequential number by distance from the top or something). I guess if I want to tab area to be bigger, I’d just hold down Tab and drag the side out. And I guess if I just want to move to the next tab over (especially if I clumped them), I’d want to be able to just hit Tab+down or Tab+right.
In this way, I won’t get disoriented because I’m still in my current tab, the tab-selection interface won’t take up the whole window, there’s visual, sequential, spatial, and language clues that I can use to make my selection, and I can control how I organize it. Of course, this runs into the “holding key down and typing hand contortionist” issue.
August 21, 2008 at 8:21 am
In my opinion the “old tab behavior” stems from the “switch document” metaphor in the Windows and Linux world, which is (and has been for a long time) “Ctrl-Tab”.
Before all you designers venture further down that visual, shiny, maccy, animated path – don’t forget one huge benefit of the “old tab behavior”:
Speed. It’s instantaneous.
No waiting for rendering previews into canvases, scrolling or scaling animations. That’s what I want from Ctrl-Tab.
August 21, 2008 at 9:39 am
I just hope Aza smacks down on all this crazyness in the way of pure, useless eye candy (the current Ctrl+Tab implementation included) and gives us a truly useful tab switching behaviour.
August 21, 2008 at 9:52 am
And if I’m to be a bit more constructive than that …
– With the old behaviour you simply move your eyes to the tab strip (which works as your content overview) and hit Ctrl+Tab until the wanted tab is highlighted. (You focus on the tabs, not on the page itself.)
– With the Ctrl+tab behaviour there are several problems:
1. Only three tabs are shown. If I could see all tabs this might work better.
2. It puts too much emphasis on the preview and too little emphasis on the page titles. The previews are not easily recognizable but trick me into looking at them, although the page titles are actually better at telling me where I want to go. All page titles should be visible.
3. The tab previews should not move, the selection should move! That would make it much easier to follow what’s going on.
With those three problems fixed the new behaviour might work. Although I still think the old behaviour is at least as easy to use.
August 21, 2008 at 1:15 pm
In the builds for Firefox / Firefox based browsers for the mobile how does the tab cycling happen ?
August 21, 2008 at 4:20 pm
I agree with Simon,
just try Tab Mix Plus and set it to open new tabs next to the current one. The browsing experience is (at least in my case) infinitely more comfortable and there is no problem with disordered tabs.
This should be the default behavior in new Firefox. No need for implementing ctrl+tab. Personally, I won’t be upgrading to the new shiny ‘fox if this “feature” can’t be turned off.
August 21, 2008 at 5:03 pm
It seems to me that mozilla has been building a pile of hacks to mask the fact that switching between related tabs in firefox is inefficient.
A bit of history:
firefox 1: tabs open to the far right, closing a tab goes to the left. Only one, visual, order. This makes you jump from the far left to the far right of the tab bar, but it is consistent.
firefox 2: tabs open to the far right, closing a tab jumps to the last tab displayed, but only if you close just one tab. We now have two different orders.
firefox 3.1: Ctrl-tab uses last-displayed tab order. We now have three different orders, two of which are visually represented in different contexts, all of which have associated shortcuts.
The ctrl-tab hack will help the heavy browser at the expense of cognitive load, and be useless to the average non-shortcut-aware user.
Epiphany, IE 7, tabs open relative: tabs open next to their parent. One order for everyone, shortcuts don’t clash with the spatial metaphor.
There is no need for any other order because related tabs are already next to each other.
Very old mozilla bugs: #161836 and #262459. The second was unfortunately shot down by the infuriatingly unjustified opinion of resident UI experts.
August 21, 2008 at 7:01 pm
[…] « Tabbing Through the Tabs […]
August 22, 2008 at 1:55 am
Mozilla obviously borrowed some UI conventions from the software most familiar to most users – their OS. I am not familiar with other OS but it’s very the ‘old’ behavior is very similar to the alt-tab functionality in Windows (XP). The tab bar is also similar to the task bar at the bottom of the view screen in windows. So I would think this behavior would be natural to anyone with some Windows UI experience.
There are a couple of differences that make Firefox old behavior less useful than it’s Windows counterpart –
1. Alt-tab shows you all open programs, sorted by usage time (descending)
2. The navigation is centered on the screen allowing for better visual focus.
The new behavior for Firefox fixes #2, however it shows only 3 at a time making it even less useful than before.
You suggestion shows only 5 at a time, making it less of a problem than only 3 at a time, but the problem remains.
I would like to have a key combination that opens up a centered view of all currently open tabs (large thumbnails with names), but doesn’t require to continue to hold the key-combination. I would then use the arrows to quickly navigate to the tab I want to focus in at. Another way to improve context might be to provide a short description on each tab (taken from a combination of the description meta attribute and text indexing, somewhat similar to what google shows in its search results).
August 23, 2008 at 12:09 pm
[…] DiCarlo: Tabbing Through the Tabs and More Questions (and No Answers) about Tabs. Jono has some nice info on using tabs in Firefox, […]
August 23, 2008 at 2:39 pm
Your idea of how to provide context is an interesting one. I imagine something akin to Dock magnification in OS X, where visual items (in this case, thumbnails) are arranged in a consistent order, but the area around the mouse pointer is magnified—thus allowing for the possibility that there are a lot of items without losing click precision. Here’s how this might work with tabs:
Ctrl+Tab displays the “tab dock”, with thumbnails arranged in tab order and magnified around the current tab target. The mouse or left and right arrow keys can be used to navigate to the desired target, thus preserving tab order.
As for the case where there are more tabs than can be displayed in the tab bar, this functionality could display thumbnails for these and autoscroll (the tab dock and the tab bar simultaneously) as the user navigates towards either end of the tab dock.
To make recent tabs more prominent, their thumbnails could be enlarged slightly (though this may be confusing along with the magnification effect). Or perhaps tab thumbnails could vary slightly in transparency, with fresher ones being less transparent.
However, this doesn’t really solve the problem of quickly switching between two tabs. It would be nice to still be able to do this with one hand on the keyboard. Perhaps the freshness behavior could be retained in the case of holding Ctrl followed by a quick release of the Tab key, but holding Ctrl and then holding Tab for a particular amount of time (say, half a second) would activate the tab dock so it persists on the screen until the user dismisses it (by clicking on a thumbnail, navigating to one using the keyboard and pressing Enter, or hitting Escape/clicking outside the dock). Within the persistent tab dock, then, there could be two options for keyboard navigation: using the arrow keys to navigate by tab order, and the Tab key to navigate by freshness order. But in the case of quickly switching between two or three tabs, there is no need to activate the persistent tab dock.
August 24, 2008 at 7:19 am
Interesting mock-up. I fear, though, that it suffers from lack of information density. It wouldn’t scale too well, especially since tab-switching previews are most useful with many tabs. If you use all that vertical space too, however, more tabs could be shown at a time. For example, you could have a grid view, with the current tab in the centre, with tabs further away appearing smaller—sort of like a fisheye view on a grid of tab previews. Of course, once such a view is implemented, might as well add zooming, get rid of the tab bar, and use this as the only way to view pages (like a very basic ZUI).