Shortcut Notation used in Mac OS X, from Safari.
Xah Lee, 2009-09-13
This article details some issues about designing a notation that represent key presses, as often displayed in menus for keyboard shortcuts.
Here's some example of illustration the shortcuts notations used for various keys, from Microsoft Windows applications. These examples are from Microsoft's Internet Explorer (Version 8.0), Windows Mail (Version 6.0):
| Notation | Associated Menu Command |
|---|---|
| Ctrl+N | New Window in IE |
| Ctrl+Shift+H | History in IE |
| Alt+F4 | Close |
| Alt+Left Arrow | Back in IE |
| Esc | Stop in IE |
| F5 | Refresh in IE |
| Alt+Home | Home Page in IE |
| Alt+Enter | Properties in Windows Mail |
(missing examples of using the Tab key, and Page up/down key, Backspace and Delete keys.)
[about choosing a keyboard shortcut notation for a new emacs distribution ErgoEmacs] I think Microsoft's notation is good enough, though i do have a little personal gripes about keyboard shortcut notations.
With keys involving shift key, in my mind i always thought it should be 【Ctrl+n】 and 【Ctrl+Shift+n】, not with capitalized letters 【Ctrl+N】 and 【Ctrl+Shift+N】.
The difference between my model and the Windows model is that, in my model, the shortcut notation are interpreted as typed text. That is, users TYPE characters with modifiers. Emacs uses this interpretation for its keyboard shortcuts notation too. In the Windows notation, keys are more thought of as buttons on the keyboard hardware. This model is actually more sensible.
In the docs i wrote i always used my model, but never really seriously decided if it is better.
Both models do have some problems. In both my model and Windows's model, the notation for pressing all keys Ctrl and Shift and 1, has two notations: 【Ctrl+Shift+1】 and 【Ctrl+@】. More than one notation for the same key press is not good. But also, it introduces another notation 【Ctrl+Shift+@】.
For example, the somewhat standard key combo to increase font size (aka zoom in) is pressing Control and Shift and Plus. In Firefox on Windows, it is shown in menu as 【Ctrl++】. Note that it made a choice to skip showing the “Shift” key. Normally, it really should be 【Ctrl+Shift+=】. The reason that it made the choice of using the version not showing the Shift key, is because that way it is more obvious to see that “+” is zoom in and “-” is zoom out. That is, consider 【Ctrl++】 and 【Ctrl+-】, versus, 【Ctrl+Shift+=】 and 【Ctrl+-】. (Just noticed, that in Internet Explorer, it actually uses this notation “Ctrl +”. This shows that the Microsoft UI designers are willing to sacrifice consistency for ease of understanding.)
This multiple representation problem occurs because of the fact that some keys are used for more than one glyph with the Shift down (For example, “1” and “!”, “2” and “@”, “3” and “#” etc.). The end result is that there is no one-to-one correspondence with a key combination and its notation.
This problem gets worse with different keyboard layouts, because not all layouts have the same Shifted symbols. For example, i looked at the Spanish Spain layout, according to Wikipedia article on Keyboard layout, a key combination of Ctrl and the ampersand symbol, would be: 【Ctrl+Shift+6】 and 【Ctrl+&】. But in US keyboard and layout, it would be 【Ctrl+Shift+7】 and 【Ctrl+&】. This means, when given a a shortcut such as “Shift+‹symbol›”, it does not always have a unique meaning, unless the layout is also specified.
From this example, we can see a slight advantage of interpreting the notation as typing text, instead of pressing buttons on keyboard. Because, if we treat the notation as chars to type, then 【Ctrl+&】 would be the only notation for this particular shortcut, so there's no 【Ctrl+Shift+7】 or 【Ctrl+Shift+6】 alternatives that are dependent on keyboard layout. Again, this is what emacs do. Note that, emacs is this way only because it is evolved from 1980s, where there is not much notion of keyboard shortcuts, but more about programing and character streams entered by user. Emacs did not took a explicit, conscious, decision to deal with keyboard and layout and human interface complexity that happened in 1990s and 2000s. Keyboard notation today, for communicating what keys to press as shortcuts to invoke commands, as displayed in menus, really should deal with keys on the hardware as human pressing buttons, not as representation of character streams or typing text.
For example, consider what happens when user sees 【Ctrl+*】 vs 【Ctrl+Shift+8】. The one with the Shift key is more clear, because it explicitly indicates that there are 3 keys involved. For the notation without the shift key, it is odd because user actually need to press the Shift key yet it is not indicated in the notation.
Btw, it is also worth to mention that Apple's OS X, does not use the plus sign for its keyboard notation. For example, in Firefox for the Mac, to zoom in, the notation on the menu is shown as: “⌘+”, which means holding down the Command key and press “+”. The Apple model is arguably more elegant.
Shortcut Notation used in Mac OS X, from Safari.
Key symbos used in Mac OS X menus.
Here's the apple symbols in Unicode.
| Symbol | Meaning | Unicode name |
|---|---|---|
| ⌘ | Command key | PLACE OF INTEREST SIGN |
| ⌥ | Option/Alt | OPTION KEY |
| ‸ | Control key | CARET |
| ⇧ | Shift key | UPWARD WHITE ARROW |
| ⌤ | Enter | UP ARROWHEAD BETWEEN TWO HORIZONTAL BARS |
| ↩ | Return | LEFTWARDS ARROW WITH HOOK |
| ↑ | Up Arrow | UPWARDS ARROW |
| ↓ | Down Arrow | DOWNWARDS ARROW |
| → | Right Arrow | RIGHTWARDS ARROW |
| ← | Left Arrow | LEFTWARDS ARROW |
| ⇞ | Page Up | UPWARDS ARROW WITH DOUBLE STROKE |
| ⇟ | Page Down | DOWNWARDS ARROW WITH DOUBLE STROKE |
| ↖ | Home | NORTH WEST ARROW |
| ↘ | End | SOUTH EAST ARROW |
| ⌫ | Delete | ERASE TO THE LEFT |
| ⌦ | Forward Delete | ERASE TO THE RIGHT |
| ⎋ | Escape | BROKEN CIRCLE WITH NORTHWEST ARROW |
In the Apple's model, adjacency implies pressing keys together. In order to use the Apple model, it is necessary to introduce symbols for modifier keys. If you don't use special glyphs, then 【Ctrl+N】 would become “CtrlN”. (Alternative is to render keys with boxes, example: 【Ctrl N】)
Note that Apple's model do have theoretical problems. For example, if there is a shortcut for pressing Command key together with the character “⌘” on some new unicode keyboard hardware, then by the Apple model it should be shown as “⌘⌘”. Of course, this is likely never to happen in practice in the foreseeable future. A more practical problem Ctrl combination with the caret. It would be “‸^”, slightly confusing. However, note that the Control key is almost never used as shortcuts in Apple's apps.
Another theoretical problem is with representing shortcuts that are key sequences. For example, in Windows, you can usually press Alt, release, then press “f”, release, then press “o”, to invoke the menu item for Open. Also, you can press 【Alt+Space】, then “c”, to close the window. Both are key sequences, and one of them also involves a combination (pressing multiple keys together at the same time). Emacs use both of these type of key sequences, and extensively with the combo sequence. (example: 【Ctrl+x k】, 【Ctrl+h i】, “Esc Esc Esc”)
Apple's OS X does not use any key sequences as shortcuts (unless one turns on sticky keys for those physically disabled). For Apple's notation to adopt to key sequences, it needs to introduce some kinda separator. For example, 【Ctrl+h i】 would be written as 【Ctrl h, i】.
I would be interested to know what are the notation shown in menus in Linux Gnome and KDE. (am guessing they follow Windows, but would like screenshot confirmation.)
Some references:
A related issue is key syntax for defining key presses. This issue is entirely separate from Keyboard Shortcut notation, but is somewhat related, and often confused together.
There is no standard, of a syntax/language to represent key presses as needed in software that needs to deal with keyboard shortcuts. Each Operating system, or key macro, key mapping, key layout software, invents its own syntax. Here are some examples of the different syntax used by different systems: