=================================== designing a keyboard for the future =================================== by Andrew Main (Zefram) 2004-04-09 abstract -------- Current keyboard design practice is influenced by historical design decisions that no longer have a rational basis. There are benefits to be gained from a redesign of the keyboard interface. Specifically, this essay challenges the paradigm of purpose-specific keys. A new keyboard design is proposed, based on the principle of context-sensitive key meanings, with a transition mechanism from the status quo. 0. table of contents ==================== 0. table of contents 1. the need for a new type of keyboard interface 1.0. time for a rethink 1.1. touch typing versus keyboard sprawl 1.2. one key, one use, immortal 2. the shape of things to come 2.0. one key, infinite uses 2.1. an alphabet of keystrokes 2.2. designing around the hand 3. a specific keyboard design 3.0. the virtualisable keyboard 3.1. ordinary keys 3.2. extraordinary keys 3.3. final layout 3.4. transitional keyboard 4. references 1. the need for a new type of keyboard interface ================================================ 1.0. time for a rethink ----------------------- Current keyboard design practice is the result of 140 years of gradual evolution. All of the underlying implementation technology has changed radically in that time. The uses to which we put keyboards have also changed a great deal: we use keyboards as interfaces to almost anything now, whereas they used to be very domain-specific tools. Yet the nature of the interface has changed very little. If we were to design keyboards anew, starting with no knowledge of keyboards that have already existed, we would come up with something very different. The wider applicability of keyboards means we have different requirements for them, and technological advancement means we have far fewer limitations on how we can make a keyboard behave. There are practical problems with current keyboards, discussed below, that make such a redesign desirable. We even have the advantage of being able to learn from these problems. We can now design a keyboard interface that is far better than that which we have inherited. 1.1. touch typing versus keyboard sprawl ---------------------------------------- Touch typing was invented well after the keyboard was, but the interface has never been redesigned to take account of this mode of use. Some modifications of the keyboard have been invented with touch typists in mind, such as the Dvorak layout and ergonomic form factors. However, they have only ameliorated the problem; they are constrained by fundamentals of the interface that are unfriendly to touch typing. (Incidentally, it is curious that mainstream keyboard design has not adopted these useful adaptations.) Touch typists can happily type block text on a current keyboard, but the keys used for this account for fewer than half of the keys on a typical PC keyboard of the beginning of the 21st Century. As soon as there is need for any other function, touch typing stops, and the hand must be moved in its entirety to some other part of the keyboard. As discussed at length in [ZEN], such moves carry a large context-switching overhead. Simply put, current keyboards are too big to touch type on. This didn't happen overnight; it took decades of accretion for keyboards to attain their current state of sprawl. They started, of course, with little more than the character keys and Shift modifier of the typewriter. Here are a few groups of keys that have joined those in the intervening years, just on general-purpose computer keyboards: * more punctuation characters and the Ctrl modifier, for typing the full ASCII character set (including unprintables) * communications control keys such as Break (remember when your terminal and host were separate entities?) * terminal feature keys, such as cursor keys * programmable function keys * the numeric keypad of an adding machine, because it's a better layout for typing numeric data * editor function keys * more modifier keys: Alt, Option, Meta, Hyper, Super * the Windows keys * power management keys * web browser shortcut keys * audio playback control keys More are being added. See also the Dilbert cartoon dated 2003-08-30. The sprawl is such a chronic problem that it has actually led to overcrowding in the older parts of the keyboard. The main section of a typical PC keyboard has at least one of the Backspace, Shift, and Return keys smaller than it should be. Two of them on the non-US versions that have one more character key. This is after the Escape key has already been ejected to the periphery of the keyboard. The main section of four rows is thus about one key too narrow to comfortably accommodate all the keys it should. The space bar row, with its increasing collection of modifier keys, is even more crowded. 1.2. one key, one use, immortal ------------------------------- It is notable that in the previous section's list of groups of keys they were described in terms of their function. A key is defined by its purpose, as indicated by the symbol or words engraved upon it. Recent additions to PC keyboards have been prompted by the extension of the home user's computing experience to cover subject areas that were not adequately addressed by existing keys. More generally, inventions of new keys have occurred because of a desire for functionality not offered by any existing key's behaviour. Even the "function keys", F1 et al, apparently of explicitly indeterminate purpose, really had a specific purpose. On a traditional terminal they could be programmed by the user, to send some arbitrary string to the host. The function keys were, in this context, very specifically about that feature of the terminal. The previous two sentences are written in the past tense because that's not how function keys are used any more. Now the terminal and host have merged, the host sees them as just more keys. Perhaps more to the point, the host *sees* the function keys, which used to be handled entirely by the terminal. Other keys, too, have outlived their original function: a PC keyboard features a Break key, despite the conspicuous lack of a serial line to send a break pulse along. Keys are immortal even when their functions aren't. Returning from that digression, the trend is towards keys of increasingly specific intended purpose. As computers get used for more and more tasks, it is to be expected that the current mainstream line of keyboard development will produce increasingly elaborate and unwieldy keyboards. The only solution is to abandon the paradigm of purpose-specific keys. 2. the shape of things to come ============================== 2.0. one key, infinite uses --------------------------- The fundamental problem with current keyboard design is the perception that a key must have a specific purpose. It is, at this point, only perception: typewriter keys were purpose-specific because the hardware was built that way, but on a PC the only difference that the computer sees between the keys is the pattern of bits that they send down a wire. The problem of keyboard sprawl can be avoided by having a small set of keys -- small enough to touch type on -- and giving the keys context-dependent meanings. Context sensitivity is not a new idea, of course. Many programs use letter keys to control functions unrelated to letters, at least when they don't require text entry; for example, in several USENET newsreaders "n" moves on to the next message. Some programs, especially games, ignore the mnemonic possibilities of letters and assign functions based on keyboard position; for example, the "hjkl" movement keys of Roguelike games. The latter approach, assigning less significance to the characters engraved on the keys than to their physical arrangement, is the way forward. When all meaning of keys is context dependent, text entry is just another context; it's not special, and shouldn't own the keyboard. Keyboard layouts for non-text-entry contexts should be designed as keyboard layouts, rather than as character-to-function mappings. They should be optimised for the usage patterns of the set of functions, just as the Dvorak layout optimises for the usage patterns of characters in English text. 2.1. an alphabet of keystrokes ------------------------------ There is an interesting parallel between keyboards and written language scripts. An ordinary typewriter key bears an image of a character, and pressing it generates a similar image on the paper. There is a direct correspondence between the key's label and the function controlled by the key and represented by the label. The key's label is, essentially, a pictogram. Keys with a specific purpose other than to generate a printable character -- such as cursor keys, Return, and Shift -- by their nature can't be labelled with a picture of their function. They can, however, be labelled with a more abstract representation of of their function. These are ideograms. By this analogy, keys whose meanings are context dependent are approximately alphabetic in nature. A letter from an alphabet has no meaning in itself; its meaning depends entirely on the letters around it (its context). Even a sequence of letters doesn't have meaning alone; its meaning depends on the language of the text that the letters are a part of. Using an alphabet or syllabary, rather than a pictographic or ideographic script, has several well-recognised advantages. Alphabets are much smaller than other types of script; this makes them easier to learn and to process in all types of information system. Alphabetic characters are more readily distinguishable than ideograms. Because an alphabet is closed (cannot have new letters added), it is possible, and normal, to have universal support of the entire alphabet in every information-processing system that supports it at all. By contrast, ideographic scripts contain esoteric characters that may not be widely understood, and new characters may be invented. All of these advantages also apply to using a small fixed set of keys in preference to a growing collection of purpose-specific keys. 2.2. designing around the hand ------------------------------ With key functions not predetermined, they cannot dictate the number or arrangement of the keys. Instead, the arrangement of the keys should be determined by the fingers' ability to comfortably operate them. This matches the aim of being able to touch-type on the entire keyboard. The extreme case of fitting the keyboard to the hand is a chorded keyboard, in which each finger has one or two switches that can be operated with the bare minimum of movement. With such a keyboard, having very few keys, several keys are operated simultaneously. Rather than an alphabet of keystrokes, such keyboards have an alphabet of chords. These keyboards already exist, but have neither become popular nor been standardised. Once context sensitivity is accepted as a part of keyboarding, it is to be expected that keyboard designs will then mutate in the direction of improved ergonomics. It is possible that the end result will be universal use of chorded keyboards. However, current chorded keyboards are actually slower than unchorded keyboards [TIF-CHORD]. If this is fundamental to chording, rather than merely a problem with current designs, then keyboard design may gravitate towards a speed-optimal middle ground. Another possibility is that keyboard designs will remain divided between chorded and unchorded designs. The latter would be used for speed, and the former for situations requiring a small or mobile input device. 3. a specific keyboard design ============================= 3.0. the virtualisable keyboard ------------------------------- Moving towards a smaller keyboard than is currently common has a useful side-effect: many of the resulting designs can be used without building new hardware. Existing keybords have more than enough keys, so if the new design fits onto a subset of them then it is possible to pretend one is using the new keyboard and just ignore the rest. Of course, this does require new software to interpret the keystrokes, but that's required anyway to use the new breed of keyboard and is easily done. This section will explain the design of a new-style keyboard that has been specifically designed with such virtual use in mind. This design actually goes further, and intends to work with any ASCII-capable terminal or emulation thereof. The reason for this is the extensive, difficult-to-change infrastructure of hardware, software interfaces, and network protocols and links that all know that keyboards generate characters. This design does not require any new software talking to the keyboard directly, at a low level: it only requires software on the host, and can accept keyboard input via any of the existing mechanisms for getting keyboard input to a host. This design aim means that the host software unavoidably receives keystrokes already translated into characters. They've been translated using the terminal's fixed keystroke-to-character mapping, so there's a chance of being able to translate the characters back into the original keystrokes. However, the design is limited to using those keystrokes that are reliably translated. For example, may or may not be distinguishable from , depending on the terminal, so it can't be used as one of the keystrokes available on the new keyboard. Because the new keyboard is, in virtual use, to be overlaid on any terminal's keyboard, it can only have a key where every terminal has a key. It will be, in this sense, the greatest common divisor of a substantial collection of keyboards. This and the translatability requirement are the two basic design constraints that result from the decision to use existing infrastructure. 3.1. ordinary keys ------------------ First the ordinary character keys of existing keyboards will be examined. These keys are all readily translatable from characters generated by the terminal back to keystrokes: each key generates a unique character when pressed unshifted, and a different character when pressed with Shift. See [LAYOUTS] for the collection of keyboard layouts that was analysed for this work. These are all computer keyboards designed for two-handed typists to type the entire ASCII character set. Observe that most keyboards have the rows of keys offset from each other, but ergonomic ones do not. This difference will be ignored henceforth; it is a low-level feature of the keyboard hardware and does not affect the abstract keyboard layout. Keyboard layouts will from this point on be shown as regular grids; this is the ergonomically superior layout, as well as simpler, and any new hardware built to the new keyboard design should arrange the keys in this way. (The offset rows are a relic from typewriter hardware. Notice that the offsets are 1/2 key width, 1/4 key width, and 1/2 key width. The effect of this pattern of offsets is that no two keys in the main four rows are directly aligned vertically. If vertical lines are drawn through the centre of each key, the lines have a regular spacing of 1/4 key width. This was done to separate the levers of a mechanical typewriter, which follow those lines.) The division of some keyboards into two pieces, to give the hands a comfortable separation, will likewise be ignored as a low-level physical detail. Any keyboard can be split in this manner. Keyboards of the new design would likely be produced in both split and unsplit versions. They will be shown below in the unsplit form. What all the keyboards being analysed have in common is the following block of keys: +---+---+---+---+---+---+---+---+---+---+---+ | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 | - | +---+---+---+---+---+---+---+---+---+---+---+ | q | w | e | r | t | y | u | i | o | p | [ | +---+---+---+---+---+---+---+---+---+---+---+ | a | s | d | f | g | h | j | k | l | ; | ' | +---+---+---+---+---+---+---+---+---+---+---+ | z | x | c | v | b | n | m | , | . | / | +---+---+---+---+---+---+---+---+---+---+ (The QWERTY labels shown are just for orientation. We're really only interested in the layout of the keys, not the meaning that the terminal assigns to them.) All of the keyboards have more ordinary character keys than this; four more are required in order to be able to type all of ASCII. Most keyboards put most of these extras to the upper right of this common block, but exact positioning is very variable. For the new keyboard design, we shall trim the right hand group of three from the common subset shown above. This leaves a regular grid of forty keys in four rows and ten columns. This is clean, simple, symmetrical, an appropriate size, and avoids overloading the little fingers. (The clustering of punctuation to the right of the alphanumeric keys on conventional keyboards makes the right little finger excessively busy.) These keys will henceforth be referred to by alphanumeric grid coordinates, to avoid any connotations deriving from conventional character labels: +---+---+---+---+---+---+---+---+---+---+ |a0 |a1 |a2 |a3 |a4 |a5 |a6 |a7 |a8 |a9 | +---+---+---+---+---+---+---+---+---+---+ |b0 |b1 |b2 |b3 |b4 |b5 |b6 |b7 |b8 |b9 | +---+---+---+---+---+---+---+---+---+---+ |c0 |c1 |c2 |c3 |c4 |c5 |c6 |c7 |c8 |c9 | +---+---+---+---+---+---+---+---+---+---+ |d0 |d1 |d2 |d3 |d4 |d5 |d6 |d7 |d8 |d9 | +---+---+---+---+---+---+---+---+---+---+ The home keys are c0 to c3 inclusive and c6 to c9 inclusive. 3.2. extraordinary keys ----------------------- It has already been mentioned that the ordinary keys adopted in the previous section are reliably translatable when modified by Shift, as well as when used unshifted. This seems a worthwhile addition to the keyboard. Note that Shift can only be used as a modifier; the terminal doesn't send a character when Shift is pressed alone, but only when it is used to modify another key. Shifted use of the forty ordinary keys can be notated by capitalising the alphabetic row coordinate; for example, is . There is another modifier key common to all terminals: Ctrl, a bizarre legacy of the ASCII character set. Like Shift, it causes ordinary character keys to produce different characters. However, as its purpose is only to generate the 33 ASCII control characters, it does nothing reliably detectable when combined with many of the character keys. Furthermore, generating some of those control characters requires both Ctrl and Shift on some terminals, and one of the control characters (^@) can't be generated on all terminals. Some other control characters, such as ^M, are unusable for a Ctrl modifier because they're also sent by special keys that it would be better to keep in the new keyboard design (see below). Others have a tendency to be eaten by communications software. After removing all of the completely unusable control characters, it turns out that Ctrl could only reliably be used with twenty of the forty basic keys (A, B, C, D, E, F, G, K, L, N, O, P, R, T, U, V, W, X, Y, Z). These form an irregular pattern on the keyboard, which varies according to the terminal's keyboard layout: QWERTY: Dvorak: intersection: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * * * * * * . * * . . . * * * * * * * . . . * * * * . * * * . * * * . . * * . * * * * . * . * * . * . * * . . . * * . * * * * * * . . . . . . . * * * . * * * . . . * * * . . . . Fundamentally, Ctrl as implemented in most terminals is a modifier for characters, not for keys. A Ctrl modifier is clearly not a practical possibility in the new keyboard design. Of the other non-character keys commonly present on terminal keyboards, most must be rejected for a combination of reasons. (a) They're away from the main group of keys, and so fail to meet the objective of a touch-typable keyboard. (b) They're not consistently present. (c) There are aliasing problems, similar to those encountered with Ctrl. There remain five keys that are consistently present in the main part of the keyboard: Space, Tab, Return, Escape, and Backspace. All have fairly consistent positioning, except on the more radical ergonomic keyboards which shift them around to make them easier to press. These can all be reliably detected by the characters they generate, when unshifted. However, when shifted they don't necessarily do anything that can detected and distinguished from the unshifted keystroke. Because these five keys are large and conspicuous, they seem worth adding to the new keyboard, to be used for particularly important functions. They'll be referred to as "spc", "tab", "rtn", "esc", and "bsp". These keys can't be used shifted, because of the detection problem. This doesn't raise the asymmetry problem that occurred with only being able to use Ctrl with a strange subset of keys: these five are, by placement and appearance, fundamentally different from the forty main keys anyway. 3.3. final layout ----------------- The keyboard thus designed consists of 45 keys that generate keystrokes alone, plus one modifier which can be used with 40 of those keys. The keyboard generates a total of 85 distinct keystrokes. The abstract layout is thus: +-------+---+---+---+---+---+---+---+---+---+---+-------+ | esc |a0 |a1 |a2 |a3 |a4 |a5 |a6 |a7 |a8 |a9 | bsp | +-------+---+---+---+---+---+---+---+---+---+---+-------+ | |b0 |b1 |b2 |b3 |b4 |b5 |b6 |b7 |b8 |b9 | | | tab +---+---+---+---+---+---+---+---+---+---+ rtn | | |c0 |c1 |c2 |c3 |c4 |c5 |c6 |c7 |c8 |c9 | | +-------+---+---+---+---+---+---+---+---+---+---+-------+ | |d0 |d1 |d2 |d3 |d4 |d5 |d6 |d7 |d8 |d9 | | | shift +---+---+---+---+---+---+---+---+---+---+ shift | | | spc | | +-------+---------------------------------------+-------+ This keyboard layout is hereby named "ZMK0"; the "ZMK" stands for "Zefram's modern keyboard". Until keyboards are actually built in the above shape, this layout can be used as a virtual keyboard, overlaid on an existing keyboard that only approximates the above arrangement. A recommendation for anyone building such a keyboard: Shift combined with any of the five unshiftable keys should make no difference. That is, should be the same keystroke as , and so on. It should not generate a new keystroke; the set of 85 is intended to be a closed alphabet. 3.4. transitional keyboard -------------------------- If the ZMK0 keyboard sees sufficiently serious use for it to be worth building new keyboard hardware for it then there is likely to be at least a transitional need for keyboards intended to be used in ZMK0 mode that can also type ASCII conventionally. A plain ZMK0 keyboard is insufficient to type all of ASCII in the conventional manner. Seven more ordinary keys, plus the Ctrl modifier, are required. Rather than put all of these seven extra character keys to the right of the keyboard, as in current designs, it would be better to distribute them between the left and right of the keyboard. This is done by adding two extra columns of four keys, to the left and right of the main forty: +-------+---+---+---+---+---+---+---+---+---+---+---+---+-------+ | esc | ` | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 | - | bsp | +-------+---+---+---+---+---+---+---+---+---+---+---+---+-------+ | | [ | q | w | e | r | t | y | u | i | o | p | ] | | | tab +---+---+---+---+---+---+---+---+---+---+---+---+ rtn | | | = | a | s | d | f | g | h | j | k | l | ; | ' | | +-------+---+---+---+---+---+---+---+---+---+---+---+---+-------+ | | | z | x | c | v | b | n | m | , | . | / | \ | | | shift +---+---+---+---+---+---+---+---+---+---+---+---+ shift | | | ctrl | spc | ctrl | | +-------+-------+-------------------------------+-------+-------+ The above layout is hereby named "ZMK1". The extra key (for this layout adds eight ordinary keys, not seven), blank in the above diagram, should not do nothing. There is the possibility of using the grid of 48 keys in a context-dependent-meaning manner. To support this usage in cases where the support software receives keystrokes already translated into characters, the 48th key should send distinct characters, both when unshifted and when shifted. With all the printable characters already being generated by the other 47 keys, it will have to generate control characters. It is suggested that it send ^A unshifted and ^B when modified by Shift. These are the first two available control characters that will be transmitted reliably and don't conflict with other keys or likely special uses. 4. references ============= [LAYOUTS] Andrew Main, "collected keyboard layouts", 2003-09-02, . [TIF-CHORD] CTD Resource Network, Inc., "TIFAQ: Alternative Keyboard FAQ: Chording Keyboards", 01/18/02, . [ZEN] Tom Christiansen, "Zenclavier: Extreme Keyboarding", 12/01/1999, .