Keyboard Shortcut Notations

By Xah Lee. Date: . Last updated: .

This article details some issues about designing a notation that represent key presses, as often displayed in software's graphical user interface menus.

Here is some sample shortcuts notations used for various keys, from Microsoft Windows. These are collected from: {Microsoft's Internet Explorer (Version 8.0, year 2009), Windows Mail (Version 6.0, year 2009)}.

Key Notations from Microsoft Software
NotationAssociated Menu Command
Ctrl+NNew Window in IE
Ctrl+Shift+HHistory in IE
Alt+Left ArrowBack in IE
EscStop in IE
F5Refresh in IE
Alt+HomeHome Page in IE
Alt+EnterProperties in Windows Mail
IE9 menu key notation
Windows key shortcut notation, shown in Internet Explorer 9's menu. Note the break of consistency in Zoom In/Out keys.

The Shifted Key dilemma: Shift+n vs N

When you see Ctrl+N, does it mean: Ctrl+n or Ctrl+Shift+n ?

Both models do have some problems.

In my model, the notation to represent the keypress combination of Ctrl and Shift and 2 is Ctrl+@. The problem here is that the notation clearly shows 2 button press, yet in fact you need to press 3 keys.

In Microsoft's notation Ctrl+Shift+@, the problem is that there's really no such key @. There's just Shift+2. The Shift+@ could actually mean something else in different International Keyboard Layouts .

Note that you can also write it as Ctrl+Shift+2. More than one notation for the same key press is not good. But also, it introduces another notation .

For example, the common key shortcut to zoom-in is pressing Ctrl and Shift and +. 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 +, without the “+”. 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 key down (e.g. “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 shortcut such as Ctrl+‹symbol›, it does not always have a unique meaning, unless the layout is also specified.

Key Notation as Typed Characters vs Pressing Buttons

There's a precision advantage of notations 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 is no Ctrl+Shift+7 or Ctrl+Shift+6 alternatives that are dependent on keyboard layout. This is what emacs do. Emacs is this way because it is evolved from 1980s, where there is not much notion of keyboard shortcuts, but more about programing and character sequence entered by user.

The advantage of notation as indicating what buttons to press, is that it is more clear and better fits the purpose of communication. Because, it's more natural to think of keyboard shortcuts as pressing a combination of buttons than typing some characters with modifiers.

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.

Apple's Key Notation

Apple's OS X's key notation does not use the plus sign. 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 of notation is elegant, it but too, has problems.

Apple Mac OS X safari menu 2009
keyboard shortcut Notation used in Mac OS X, from Safari, year 2009.

In Apple's notation, symbols are placed in sequence one after another. For example, ⌥⇧⌘V .

In the Apple's model, adjacency implies pressing keys together. In order to use the Apple model, it is necessary to introduce logographs for modifier keys. If you don't use logographs, then Ctrl+N would become CtrlN. (Alternative is to render keys with boxes, example: Ctrl N)

Apple Notation Problems

Note that Apple's notation does have some limitation too.

Problem with Key Sequences

One problem is with representing shortcuts that are key sequences. For example, in Windows, you can press Alt, release, then press f, release, then press o, to invoke the menu item for Open. This is a key sequence. Also, you can press Alt+space, then c, to close the window. In this sequence, it 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+x Ctrl+c, Escape Escape Escape)

Apple's OS X does not use any key sequences as shortcuts (unless you turn on sticky keys for those physically disabled). For Apple's notation to adopt to key sequences, it needs to introduce a separator. For example, ⌘ command+h i would be written as ⌘H,I. Here, we used a comma as separator.

Note that the separator can be a issue itself. For example, if we use a comma, it is ambiguous because it could mean ⌘ command+h , i. But if we use space ⌘H I, then it leaves the question of how to represent the space key. (e.g. one of emac's shortcut is Ctrl+Space.)

Notation as Human Interface vs Programing Language Syntax

A related issue is key syntax for defining key presses. This issue is entirely separate from Keyboard Shortcut notation. Key syntax is designed to communicate to machines. It needs to be completely precise. Key notation is used to communicate to humans.

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:

It is conceivable to have a key syntax that is as precise as a computer language yet also readable for human communication. The closest might be emacs's key macro notation, yet it has many problems due to historical baggage. [see Emacs's Key Syntax Explained]

See also:

Key Label