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).
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.
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 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.
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 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.
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.
There are 0 comments on this page. Add yours.
0.0092s
.