In a graphical user interface you want a keyboard-based way to switch between open windows. The convention across contemporary operating systems is the two-key combination Alt-Tab. (On Apple machines it’s actually Apple-Tab, but for brevity’s sake I’ll call that Alt-Tab too.) Windows are arranged in a linear order and each Alt-Tab input moves you to the next one. In GUIs like Microsoft Windows or various flavors of X Windows that’s all there is to it. As a graph, the Alt-Tab method looks like this.
Here the rectangles represent windows, the forward-going arrows Alt-Tab, and the backward-going arrows Shift-Alt-Tab.
GUIs like OS X and the Unity shell for Ubuntu take a more complicated approach. Open windows are grouped by application. Alt-Tab moves you between application groups. Each application group remembers the window in its group that received focus most recently. If you want to go to a different window opened by the same application, you have to hit a different key combination: Alt-Backtick. The graph for the Alt-Tab/Alt-Backtick method looks like this.
As before, the solid lines represent Alt-Tab navigation. The dotted lines represent Alt-Backtick (and Shift-Alt-Backtick). Exactly which window in an application group is singled out as the Alt-Tab target is determined in a complex and path-dependent way.
This is a terrible design. With the Alt-Tab method I don’t have to think about how to navigate to the window I want–I just pound on Alt-Tab until I see it. This activity can be relegated entirely to muscle memory: it doesn’t intrude on my thinking at all. With the Alt-Tab/Alt-Backtick method, I can pound away through entire application group cycle without ever seeing the window I want. Only when I’ve come all the way around do I remember, oh right, I have to be clever about it. Then I’ll navigate back to the proper group and start delicately tapping Alt-Backtick until I’ve got what I want, at which point my concentration is broken. Worse still, I might start trying to strategize my way through the confusion. When I’m about to leave a window I’ll ask myself, “Five minutes from now which of the windows used by this application I’m I mostly likely to want?” then I’ll Alt-Backtick over to that one to just leave it at the head of application group queue before moving on to where I really want to go. Even if I don’t do this I’m either thinking about it or trying to make myself not think about it–whichever is more distracting. The operating system has become an impediment rather than a tool.
The worst offender is the Unity shell in Ubuntu, which if you linger on a application group in the Alt-Tab selection popup for more than a couple of seconds will change the semantics of this keyboard shortcut and start cycling through the application group with Alt-Tab. Imagine the second graph above where the Alt-Backtick edges are actually either Alt-Backtick or Alt-Tab in some complicated way that is tied in with your reflex speed and attention span. It is literally stressful.
This is classic overdesign: someone took a simple thing that worked well and made it into a more complicated thing that works less well. Specifically, the Alt-Tab/Alt-Backtick method has three failings:
- It is more complicated. You can see this by comparing the two graphs above.
- It doesn’t take visual feedback into account. In the Alt-Tab method I don’t need to remember anything about the state of the graph because I can cycle through the whole structure and see it for myself. Even if I have twenty windows open this isn’t a big deal, particularly if hitting Alt-Tab brings up a tabbing pop-up window that displays icons for the chain of open windows in order. There is no similarly mindless way to view the Alt-Tab/Alt-Backtick graph. A single repetitive hand motion will only reveal some of the open windows. To find the rest, I have to hunt them down inside a maze.
- It makes an unwarranted assumption about how windows should be grouped. A navigation method should group windows in a way that reflects the way they are being utilized. Say I’m trying to get two things done at the same time, and both require that I have a word processor and a spreadsheet open. In this local, temporary task space, word processor window 1 and spreadsheet window 1 are psychologically adjacent while word processor window 1 and word processor window 2 are psychologically separate. The Alt-Tab/Alt-Backtick schema, however, forces word processor windows 1 and 2 to be navagationally adjacent no matter what.
Of course no designer tries to make things worse, and I think the scenario in (3) shows the crux of where the Alt-Tab/Alt-Backtick method goes wrong. What you want in that scenario is to make the corresponding word processor/spreadsheet pairs adjacent in navigational space in a way that corresponds to their distance in psychological space. The Alt-Tab method does not do this. There navigational proximity is the distance along the open window chain, and the order of the chain is usually based on the order in which the windows were opened. It is effectively random. You can see this as sufficiently ameliorated by the feedback mechanism described in (2), or you can see it as a problem to be solved. The Alt-Tab/Alt-Backtick method attempts to solve it by paying a complexity cost–see (1)–for an efficiency win. Unfortunately it makes the incorrect assumption that application identity is a good proxy for task identity. Incorrect because you often need more than one application to accomplish a single task, and inconsistent with the document-centric model most modern graphical user interfaces take, which (correctly, I think) strive to treat the concept of separate “computer programs” as a technical detail that should not intrude on day-to-day workflows. Sometimes it’s best to leave well enough alone.