Key combinations are used to a varying degree by computer users, but one thing is clear. In Mac OS X, they are a vital part of the OS experience. It is through key combinations that a user can perform functions quickly without having to use the mouse. In an ideal world, a user could be without a mouse and still be able to use their computer to almost its full potential, if clumsily. But most importantly, they are easy. Usually. Analogous key combinations are usually consistent across Applications, true, but there should also be a logical, discoverable system for determining them.
Discoverability This is by far the biggest issue for key combinations: discoverability. I still impress my dad when I use even the simplest key combinations. Why? Because the average user does not know very much about them. Key combos seem like such a simple thing to long-time computer users, but they are often illogical and confusing which makes discovering them difficult. Moreover, they are not displayed in contextual menus: for example, the Copy, Cut and Paste options do not have their respective key combinations. But there's more: not only are key combos difficult to discover for first time users, certain things are hard to learn about and remember even for long time users. There is one particular example that has particularly troubled me. Most key combinations are noted in their respective menus. However, one class of combinations are not noted anywhere, except in tips and trick sections of websites. I am talking about modifiers that are used in conjunction with the mouse.
The fact that such combinations are relegated to such websites is indicative of how non-discoverable they are. Four different keys can be used with the mouse button and all of them do different things in different places. For example option-clicking an item in the dock hides that application. Command-option clicking switches to that application, and hides all the other programs. But command-clicking reveals the program in the Finder. Another example is that pressing escape while you are dragging something will usually cancel the drag. Yet the only time that moving a window can be cancelled is iTunes. Not to mention even more obscure things like dealing with windows while the command key is pressed doesn't bring them to focus, or that option will copy a file while you drag and hold it down, but move a file if you are dragging across drives. I'm sure you know that double-clicking selects a whole word, but did you know that clicking and the click-dragging will allow you to drag out a selection of text, that must have whole words? Or did you know that if you hold down the option key while selecting text you can select blocks of text irrespective of the line-breaks? Thus, what we need to have is some floating platte that tells you all of the modifiers that can be used with the mouse and what it can do. This platte must be easy to access and simple yet informative.
Command Right? According to the HIG, this combo's purpose is very clear cut. It even is "reserved for system use," a status to which are elevated such vital commands as command-tab and command-h. But in real life its usage is horribly muddled. Here is what it says:
Command–Right Arrow |
Changes keyboard layout to current layout of Roman script. |
Command–Shift–Right Arrow |
Extends selection to the next semantic unit, typically the end of the current line. |
Shift–Right Arrow |
Extends selection one character to the right. |
Shift–Option–Right Arrow |
Extends selection to the end of the current word, then to the end of the next word. |
Control–Right Arrow |
Moves focus to another value or cell within a control, such as a table. |
Except, despite being reserved by the system, this doesn't happen. In fact, I haven't the slightest clue what that "changes keyboard layout to current layout of Roman script" means. Instead developers are happily using command-right for other purposes. The only problem is that they can't really decide what that purpose is, even within the same application. The function of the key combo mutates depending on the object selected in the window. So if, in Safari, I have a text-area selected, command-right will move the text pointer to the end of the line. But if I click out of that box, command-right will move the browser window forward. iTMS has back and forward buttons, so it would be easy to assume, that like in Safari, they would be activated by command-left and command-right. Nope, command-left takes you to the beginning of the currently playing song, whatever that is. The Finder also has back and forward buttons, so you'd think that back and forward would be just what they are in Safari. But they are not, that's command-[ and command-].
In fact, this is not just a problem with the left and right arrow keys, all four suffer this fate. I have found (almost entirely accidentally), that Mac OS X actually does have ways to emulate the home and end commands on Windows computers. Option-up and option-down. Here is a quick table of what each of the arrows can do in text environments:
| Left | Right | Up | Down | |
|---|---|---|---|---|
| Control | Beginning of Line | End of Line | Scroll one page up | Scroll one page down |
| Option | Beginning of Word | End of Word | Beginning of Paragraph | End of Paragraph |
| Command | Beginning of Line | End of Line | Beginning of Document | End of Document |
The point I'm trying to get across here is that there is a lack of a clear strategy. The command key duplicates a function of the control key, and the control key duplicates the functions of the page up and down keys. I think that two things need to be done to fix this: that Apple moves the key's functions to the control key and that apple leaves the control key its shortcut values. This way you wouldn't have duplicated functions, but you also would get to use the command key solely for shortcuts.
And while I'm on the topic of no strategy... I came up with an idea the other day: what if instead of having a complete hodgepodge of combos, Mac OS X had a logical system of determining key combos. Here's what I mean: right now, think of the h key. Command-h is "hide this app", and command-option-h is "hide all other apps". But command-shift-h? That's usually something like the "home" command. The M key should be similar... but it isn't. Command-m minimises, but Command-option-m minimises all windows, not the other windows. Universal access things are usually control+Fx, except if you are talking about VoiceOver, it's Command+F5. But wait, it appeared like Apple wanted to reserve the function keys for users. Except for F5 that is.
My point is simply that a little more logic is needed. How about system shortcuts all use command-option, and apps never do. Or maybe that universal access, and only universal access use the control key. Plus there could be one set of combos for "Services" maybe like control-option.The way it is now is pretty confusing.
Wait a second, did I say F5?
This ties in real well with all that discoverability and logical strategy stuff. There is this so-called feature called "complete". You may have seen it in some menu somewhere. If you are typing you can press the F5 key and (I assume) it looks in the dictionary for the most common works that start with the letters you've already typed. You probably have encountered this feature in word processors or text editors, it can be useful. Here's the problem. For one, it has literally 0 discoverability. Plus the combo used is stupid. F5? The function keys should, in my opinion be reserved solely for users. Plus, get this. Type something and then press the esc key! The same thing happens! Even better... type command-period. Or option-escape! They all invoke that same feature. Why should you waste at least 4 different key combos on the exact same thing?
This feature is not only poorly discoverable, but it also is not very advanced. If you continue typing after you pressed the F5 key, it goes away. So I can't really continue to complete a word after all. Lastly you see that screen-clip? That's the bottom of the screen. The problem is this little popup doesn't fit onto the screen. Unlike every other menu in Mac OS X, it just disappears off the bottom. How strange.
Lastly, they are clearly working on this feature. In Dashcode or XCode, if you use this feature it fixes the problems in the above paragraph, and even offers a toggle between sorting by completetion and by a best guess. But for some reason they just didn't bother updating this in the rest of the OS.