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:
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.
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.
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.