Solving the Alt-Tab Problem

Aza Raskin on switching between applications (or tabs) using an alt-tab-like mechanism:

The standard method is to use MRU (Most Recently Used) order: the applications are arranged in the order in which they were last used. This works great for switching back-and-forth between two apps, which is a very common task. Unfortunately, that’s most of what it is good for. People have a strong spatial memory and the constant seethings of MRU confound it. If you need to switch between three windows (another common task), you are out of luck because MRU frustrates your natural tendency to form habits. Here’s a situation that comes up often in user testing:

You’ve been using alt-tab to bounce back-and-forth between your text editor and your web browser—you’ve formed a habit. You now click over to your Twitter client to see your friend’s latest updates, click back to your text editor, type a few sentences and hit alt-tab. What happens? Because of your habit, you expect it to go to your web browser, but because the last used application was your Twitter client, that’s where it switches. That’s most likely not what you wanted. What happens next? You generally pause to think, and then use double alt-tab to switch where you wanted to go, which is your web browser. Then you hit alt-tab to switch back to your editor (habit!) and instead it goes back to Twitter. The troubled cycle repeats until MRU’s ordered once again aligns with your habit.

Despite of having used computers with alt-tab task switchers for more than two decades, this still happens to me all the time. Aza presents a possible solution to the problem, based on the idea that the computer would try to detect the habits of the user, and thus find the application the user most likely wants to switch to. I’m not sure this is a good idea. Unless the solution works perfectly, it makes the computer’s behavior unpredictable from the user’s point of view.

The main problem is that there are situations where there are two likely candidates for the application the user might want to go to next.

Simply moving the previous frontmost two applications back to the front after the user first switches to an application after the first two, and then switches back the the previously frontmost application would be problematic, since it would make it harder for the user to «replace» one of the two frontmost applications. I don’t think this problem can be solved by anticipating the user’s intention, and rearranging the applications accordingly. If there is a solution, it probably involves changing how the application switcher works.

One possible solution might be to put the frontmost application into the second slot, and the previous frontmost application into the first slot. This way, going «back» to the previous application would be cognitively a different action than going to another application altogether.

I don’t have a clue whether this would solve the problem. It might just make the problem worse by adding another «action» to the application switcher. User testing would have to be done to see whether this solution works in real life.

This solution also doesn’t solve the problem that the order of the applications is not spatial; you have to look through the icons every time you want to switch to a specific application, because the same application never shows up in the same place.

Update: There is a follow-up to this article.

If you require a short url to link to this article, please use

designed for use cover

But wait, there's more!

Want to read more like this? Buy my book's second edition! Designed for Use: Create Usable Interfaces for Applications and the Web is now available DRM-free directly from The Pragmatic Programmers. Or you can get it on Amazon, where it's also available in Chinese and Japanese.