The crux of the switch
It’s almost hard to imagine Mac OS X without a good application switcher. But previous to OS X 10.3, that was just the case. Back in 2003, I summarized why the previous application switcher was so poor:
To switch the active application in 10.2, you hit Command-Tab and a highlighted dock icon told you which application was selected. It worked, but it had problems. The biggest of which occurred when open applications were separated by several unopened applications on the dock. When this happened, the highlight skipped across these unopened applications in a seemingly unpredictable manner because almost no one could remember exactly which applications were open and which applications where closed.
A Better Switcher
In 2001, a small software startup named Proteron announced LiteSwitch X, an OS X update to its popular OS 9 keyboard application switcher. LiteSwitch was essentially a Mac implementation of the Alt-Tab switcher found in Windows, but with an additional slew of features including drag and drop support, closing multiple applications and windows layering control. I was unsatisfied with the 10.2 application switcher and started using LiteSwitch X soon after buying my first Mac.
Apple caught up to Proteron in OS X 10.3 and introduced its own application switcher albeit with significantly less features than LiteSwitch X. Apple’s switcher has remained relatively unchanged since its original implementation.
Hit Command-Tab and you switch from the current app to the next most recently used app. If you hold Command, all running apps are displayed, and you can continue hitting tab to switch to another app. You can additionally hold down Shift and cycle in the opposite direction, and use the H and Q keys to hide and quit applications.
Apple slightly improved the switcher with 10.5, introducing drag and drop support and then again with 10.6, allowing you to trigger Exposé and show all windows of the selected application by hitting the up or down key.
Blinded by the Lite
Version 1.1 of LiteSwitch X introduced a preference for sending the reopen event to applications upon switching to them. This meant that LiteSwitch would force OS X to reopen the window if it had been closed, or restore the window if it had been minimized to the Dock. I enabled this preference soon after I started using LiteSwitch as it felt like the most natural way to switch to an application. With every OS X update, LiteSwitch X was one of the first add-ons that I installed. So when I switched to an application, I expected to it to be visible — the only exception being if it was a document-based application and there were no open documents.
In early 2009, I noticed that the Proteron website was down (The Wayback Machine records July 24, 2008 as the last date the website was reachable), and over the past year I was concerned about continuing to use software that was no longer supported. So near the end of December I begrudgingly tried to use the built-in OS X switcher.
Having been blinded by LiteSwitch for so many years, I was completely set back that the OS X switcher didn’t reopen closed or minimized application windows. For example, say iTunes was open but the main app window was closed. If I switched to iTunes, no window would appear. Switching to Finder, Mail, Address Book, Safari, Tweetie, Adium and other apps also didn’t reopen application windows.
Given that switching didn’t reopen application windows, I expected a common keyboard shortcut for accomplishing this. Unfortunately, shortcuts only complicated the situation. To show the iTunes main window, I needed to hit the keyboard shortcut for opening the window (Option-Command-1 in the case of iTunes) or click on the iTunes Dock icon. There’s no unified keyboard shortcut for reopening the main window - even among applications made by Apple. Here are the keyboard shortcuts for the apps I listed above:
- iTunes: Option-Command-1
- Finder: Command-N
- Mail: Command-1
- Address Book: Command-0
- Safari: Command-N
- Tweetie: Command-0
- Adium: Command-/
These are just the apps that have a shortcut. Many, like Evernote, don’t even have one.
After tweeting about the lack of a standard shortcut for reopening main windows, Martin Polley pointed out that the OS X application switcher actually can reopen windows with some additional shortcut trickery.
It goes like this: hit Command-Tab to switch as you would normally, then when the app you want to switch to/reopen is selected, hit Option while continuing to hold Command. Then release Command before you release Option. Go ahead and try it now. When you first start using it, it’s quite painful after the simplicity of Command-Tab, but it does get slightly easier over time.
Personally, I love controlling OS X via keyboard, and most of the time I welcome consistent and standard keyboard shortcuts for commands. However, I believe that adding a shortcut for reopening windows is the wrong solution because it defies traditional keyboard shortcut expectations. For nearly every keyboard shortcut I use in OS X, there is a perceived before state and an expected after state. For example, if I’m browsing a site in Safari and I want to jump to the search input, I hit Command-Option-F. In the before state, I perceive that the webpage has focus. The expected after state is that the search input will have focus. In the case of the OS X reopen shortcut, the before state is that the window is closed or minimized. The expected after state is that OS X will bring the selected application forward and reopen or restore the window. The issue is that it’s very difficult, and sometimes impossible, to know if the window is actually closed or minimized. So for the shortcut to be truly effective, the user needs to remember which windows are open and which windows are closed or minimized. This is unrealistic at best.
Out of the box, the Mac offers three key ways to switch applications, and each of them behaves differently.
- The Dock. Click the application icon in the Dock to switch to the application and bring all of its windows, including closed application windows or individual minimized windows (if the app has only one window and it’s minimized), to the front. Clicking on an application’s Dock icon to switch to that app is one of the first skills that a new Mac user will learn. So it makes sense that doing this brings that application’s windows to the front.
- Selecting the Window and Exposé (now part of Mission Control). Click within an window to switch to the application and bring the selected, but not all of its application windows, to the front. Exposé is a different way to visualize windows but the same behavior applies. This is even more straightforward that clicking on a Dock icon; clicking on a window brings that window forward. For the new user, it seems okay that only a single application window comes to the front because the user clicked a single window. (As a historical note, in OS 9, clicking within a window actually brought all the application’s windows to the front.)
- Command-Tab. Hit Command-Tab and you switch from the current app to the next most recently used app and bring its open windows to the front. Let’s consider the new Mac user again. Clicking on an application’s Dock icon brought that app’s windows to the front, but using Command-Tab to switch to an app — which looks identical to the app icon in the Dock — only brings open windows to the front. It’s easy to assume that this isn’t going to make a lot of sense to the new user.
I believe that Command-Tab is the only way to switch applications without affecting windows because when Apple implemented the switcher in OS X 10.3, someone decided that it was the one true application switcher. And a true application switcher shouldn’t affect windows; a true application switcher only switches the application.
This is where Apple misstepped. Beyond being inconsistent with its closest switcher sibling the Dock, it doesn’t provide perhaps the most important thing that most users need upon switching: to see an application window.
Applications and Windows and Documents
Every application has at least one window. Some applications are document-based, meaning they allow the user to operate on multiple items at the same time. Mail, TextMate and Photoshop are all examples of document-based applications. Typically, document-based applications have one window per open document and often have multiple windows open at once. Other applications are non-document based; in these apps the user can only operate on one item at a time. As of this writing, iTunes, iCal and Address Book are all examples of non-document based applications. Typically, non-document based applications only have one window. For all practical purposes, that window is the application.
In the case of non-document based applications, the argument for always showing a window upon switching is easier. If you want to use iTunes, there’s practically nothing you can do without the application window. The same is true for iCal, Address Book and many other single window apps.
It’s a little trickier for document based applications. If the application has one document open, it makes sense to show that window — even if its minimized — because there’s a damn good chance that they’ll want to see that window. (People who keep their Dock hidden: have you ever switched to a document-based application and thought nothing was open because you didn’t see a window, later only to discover that you had a window minimized in the Dock?) If the application has two documents open, it makes sense to show the last document (window) the user interacted with.
Here’s the tricky part: what if a document-based application doesn’t have any documents open? Current apps handle this in different ways: some do nothing, some open a new untitled document automatically, some make it a user preference. Personally, I prefer apps to do nothing and not open any new windows, but ultimately I believe the window opening behavior should be based on the app. This, then, is the only exception to showing a window upon switching: if a document-based application doesn’t have any documents open, the developer should choose the window opening behavior and in some cases, allow the user to choose in the application preferences.
The Crux of the Switch
Switching should reopen closed and minimized application windows. It’s consistent with other ways to switch and therefore easy to understand. But most importantly, it’s what the user needs to use the app in most cases.
Given that Apple has released three versions of OS X since introducing the application switcher, I’m fairly certain that they would be extremely hard pressed to change its behavior at this point. The good news is that Ammon Skidmore, previously of Proteron, is keeping LiteSwitch alive, and it continues to work in OS 10.9.
The Crux of the Switch was originally published in January 2010 on my tumblelog, also unraveled.