Principle of Least Astonishment

In user interface and software design, the principle of least astonishment states that "if a necessary feature has a high astonishment factor, it may be necessary to redesign the feature." It means that your user interface should behave in a way that the user expects, based on their prior knowledge of how similar interfaces behave.

This is a rant about Mac OS X.

At my new job, they gave me a Macbook Pro to work on because they standardized around Apple products. At first I figured I would just get used to OS X, and it was difficult not to because this Macbook didn't take very well to Linux.

I ran OS X full-time at work for about three months and came to the conclusion that Mac developers apparently don't care at all for the principle of least astonishment. (Note that this isn't a jab at Apple, because most of these problems come from popular third party apps, but perhaps Apple gave apps more control than they should have over window management features).

(I eventually had them swap out my Macbook Pro with a standard HP laptop on which I installed Linux).

The OS X Dock and Window Switching

One of my biggest sources of frustration is the dock and window switching features of OS X.

The dock groups all windows of a like application into one single icon on the dock. If you have multiple windows of the same app open, clicking its dock icon will bring all of the windows to the front. Which window then has the keyboard's focus is up to the alignment of the stars. There's no option to ungroup windows into different icons.

To switch windows you hit Command-Tab (⌘Tab), which is like Alt-Tab in Windows and Linux except it only switches between applications and not windows. When you ⌘Tab to an app, again all windows of that app come to the foreground and you can't predict which of its windows has your keyboard's focus.

• Example: Adium. Adium regularly has at least two windows open: the buddy list window and the chat window. Every single time I ⌘Tab to Adium, the buddy list window takes the focus, even if the chat window was the last one I used. I always have to then ⌘` (to switch windows between the current application) to focus the chat window.
• Example: iTerm2. If I had two iTerm windows open, then every single time I ⌘Tab to iTerm, it would focus the opposite window from the one I had last time. For example I could ⌘Tab from iTerm "A" to Firefox to iTerm "B" to Firefox to iTerm "A". This was particularly frustrating because usually when I have two iTerm windows open it's because I want one to sit mostly idle; maybe it's watching system resources or running a long task and I didn't want it to take up a tab on my main window.
• Example: Minecraft. Every time I would ⌘Tab to and from a Minecraft window, the Command key would become "stuck" within Minecraft. For example I'd ⌘Tab to it and start typing stuff in chat, but when I type the letter "a" it behaves as though I typed ⌘A to select all text and then I'd subsequently end up deleting it. To remedy this I'd have to again ⌘Tab away and back again from Minecraft to "unstick" the key.

Another example is Google Chrome, but this one can't be summed up with just one bullet point.

Chrome has Web Apps, and for example we'll pick on the Hangouts app. Web apps get their own icon inside of the Chrome Web Apps launcher, and when you open them, they get their own icon on your OS X dock. This sounds good in theory, but under the hood the web app is still running as Google Chrome and OS X's window management problems still apply.

Even though you have two icons on your dock (Chrome and Hangouts), they both refer to the same application. If you ⌘Tab to Chrome, Hangouts also comes to the foreground. If you ⌘Tab to Hangouts, Chrome also comes up. You still have all the same problems of not knowing which window will grab the focus when you ⌘Tab to either app. For example, if you had Hangouts active earlier, and later you ⌘Tab to Chrome, the Hangouts window gets the keyboard focus even though you wanted the Chrome window.

It appears that it is up to the individual app how they deal with their app being switched to. Some apps focus the last window you were working from, some apps focus the next window in their own list, some apps always focus a specific window every time.

You can't simply learn one time how window switching and the dock works and apply that knowledge to every app you run. If you run a new app for the first time, you can't predict how it will behave without testing it. This is a violation of the principle of least astonishment.

The Zoom Button

The zoom button is on the window title bar of most apps, and it's roughly analogous to the "maximize" button on Windows and Linux.

As of Mac OS X Yosemite and El Capitan, the default behavior of the Zoom button is to put the current app into full screen mode (not maximized). If you just wanted to maximize the window instead, you have to hold the Option key while clicking on the Zoom button, or else double-click the title bar of the window.

Most apps behave this way, but some do their own crazy thing instead.

• Example: Google Chrome. Trying to maximize Chrome using the standard way that works in most apps does not in fact maximize Chrome. It only expands it vertically, but not horizontally. To maximize Chrome, you have to push Option+Shift+Zoom (or Option+Shift+double click the title bar).
• Example: a past version of iTunes. I'll admit that this example is outdated, but the way iTunes behaved on Mac OS X Leopard was equally surprising. Back then, the Zoom button maximized most apps by default, except in iTunes, when it would instead shrink iTunes down into a minimalistic playback control window. The window would actually get significantly smaller instead of larger when you click the Zoom button.

I don't have other examples because thankfully my set of applications I work with mostly did The Right Thing™.

The point of my complaint about the Zoom button is that it's not possible to simply learn one time about what the Zoom button does and how to maximize a window. It appears that every app is capable of overriding the behavior of this button and do their own thing with it. If you run a new app for the first time, you can't know in advance what will happen when you click this button. This is a violation of the principle of least astonishment.

The Command Key and Other Behaviors

The command key in general is a source of many problems.

There are a few Command-key shortcuts that globally apply to all apps. These are shortcuts like ⌘X, ⌘C, and ⌘V for cut, copy and paste. Besides this, it is apparently possible for apps to bind their own actions to the command key, and one app's set of keyboard shortcuts won't necessarily be the same in another, similar, app.

• Example: Adium again. In most apps, if you want to insert a literal line break character in a text box (where hitting Return/Enter would send the message), you would hold down Shift when hitting Return. For example, Slack behaves this way. But in Adium, this will cause the message to be sent anyway. Instead you have to hold Option and hit Return; or was it Command? I'd always screw this up three different ways before figuring it out again.
• Example: Atom vs. all other text interfaces I used. In Atom, hitting the Home key would put the cursor at the beginning of the current line of text, and End would put it at the end of the line. In most other apps with large text areas, Home instead puts the insertion cursor at the beginning of the entire document, and End at the end of the document.
• Example: iTerm2 and Atom's tab switching shortcuts. In iTerm2 the way to switch from one tab to the next was to hit ⌘+Left or Right arrow. In Atom, this shortcut doesn't do anything. Instead you'd do Control-PageUp or PageDn, which is more similar to how apps like Atom behave on other platforms besides OS X. I haven't tested tab switching shortcuts in other apps.

The one good thing I liked about the Command key is that it made it easy to copy and paste text from a terminal. Control-C has a special function in terminals, so being able to copy without halting the running application was a neat feature. In Linux land most terminal emulators make you push Shift-Ctrl-C to copy text.

The general feeling I got from the use of the Command key on Mac OS X is that nobody can agree on what it should be used for. Every developer uses it differently in their app, and sometimes there's no rhyme or reason for why one shortcut binds to Command instead of to Control or Option. I feel that if Linux developers decided they wanted to add a new modifier key for shits and giggles, the same sort of absolute mess would follow. Instead, for the most part, nobody in Linux makes very much use of the Command key at all (in Linux the Command key is called Super, and is the same as the Windows key on a standard keyboard). In most Linux desktop environments nothing at all is bound to the Super key, although the GNOME Shell desktop makes some use of it for window switching purposes.

In contrast, the Windows key on a Windows OS is very well defined. There are a handful of global Winkey shortcuts (for example, Windows+R to open the Run dialog, or Windows+L to lock your screen). These shortcuts apply globally throughout the OS, and no third party software that I'm aware of binds their own shortcuts to the Windows key. If that's even possible for an app to do, I don't know. Mac OS X would be better off not allowing application writers to bind custom actions to the Command key because they clearly can't be trusted with it.

This keyboard shortcut mess is a violation of the principle of least astonishment.

I'll probably update this blog post with additional examples as I find them. I still dual-boot my personal Macbook Air with Linux and OS X.