keyboard shortcut notations
Perm url with updates: http://xahlee.org/emacs/modernization_hotkey_notation.html.
A Short Survey Of Keyboard Shortcut Notation
Xah Lee, 2009-09-13
This article details some issues about designing 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):
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”, for the none-shifted and shifted version...
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 “keybinding” 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.
Notational Problems With Shifted Keys
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+&”.
Interpreting Key Notation As Typed Characters vs Pressing Buttons
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.
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.
(Apple uses the symbol “⌘” for the Command key, “⌥” for its “Option/Alt” key, “‸” for Control key, “⇧” for Shift key.) Apple use images to display these symbols. These symbols also in Unicode. Here's their unicode names: PLACE OF INTEREST SIGN “⌘”, OPTION KEY “⌥”, CARET “‸”, UPWARD WHITE ARROW “⇧”.
Key symbos used in Mac OS X menus.
In the Apple's model, adjacency implies pressing keys together. In order to use the Apple model, it is necessary to introduce symbols for the Control and Alt key modifiers (or other modifiers). If you don't use special glyphs, then “Ctrl+N” would become “CtrlN”.
(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 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.)
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 confirmation)
- Keyboard shortcuts.
- Keyboard layout
- Mac OS X keyboard shortcuts http://support.apple.com/kb/HT1343
- Keyboard shortcuts for Windows http://support.microsoft.com/kb/126449
Notation As Consummer Software vs Programing Language Syntax
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:
- Emacs's keyboard macros and key press representation in emacs lisp. (For some examples, see: How to Define Keyboard Shortcuts in Emacs, The Confusion of Emacs's Keystroke Representation.)
- Mac OS X's keybinding. (See: How To Create Your Own Keybinding In Mac OS X.)
- The X Window System's need to represent key presses as used by its utility xmodmap. (Syntax Example: dvorakKeymap.txt)
- Programable Keyboard Macro Software. For example, AutoHotKey. (See: AutoHotKey Basics)