In a previous post, I mentioned the Keyboard.io Model 01. One thing that slightly worried me about it was the keyboard layout of the prototype – it was yet another symmetric-grid arrangement similar to, but distinct from, each of the other Kinesis/Maltron layouts already out there. We are promised of course a fully programmable model, which means I can fix it up just the way I like, but it would be really nice if modern keyboards would pick a standard and stick to it – not least that maybe the keyboard legends would be useful. 😉
So it was with great interest that I saw they are requesting feedback before finalizing the key layout. This post is my contribution.
Keymaps, arrangements and layouts
In the following I use “keymap” for an OS-level mapping of “physical” scancodes to “logical” code points, and “arrangement” for the physical location of the keys that generate particular scancodes. When taken together, these form a “layout”, which is normally represented by the labels on the physical keys. One can usually change the keymap in the OS (e.g. via a menu in the taskbar) so that the layout no longer matches the key labels. On some keyboards (such as the Kinesis Advantage and keyboard.io), one can effectively change the physical arrangement in firmware so that the same OS keymap produces a different layout.
Alternative keyboard arrangements
Most keyboards manufactured today follow the pc104 (USA) or pc105 (everywhere else) paradigm, which derives from the original Scholes typewriter, and was set out in the 1980s with the IBM XT. Many keyboards since then have either added extra keys (e.g. multimedia controls) or left out a few (e.g. laptops) but the basic arrangement remains the same. This is notably asymmetrical, with the keys located along staggered diagonals and the right hand (for touch typists) having significantly more keys to cover than the left.
By contrast, in the Maltron keyboard and its various grid-symmetrical derivatives, this basic arrangement has been changed so that the left and right hands are equal and the staggered diagonals have been made vertical to match the natural movement of the fingers. This has required a number of changes to the pc105 layout to rebalance the key arrangement. In most such grid-symmetrical keyboards, a selection of keys (usually modifiers) have been moved under the thumbs and the total number of keys under the fingers reduced to (typically) two 6-by-4 grids, sometimes with extra keys under the “z” row and/or between the hands. There are exactly 48 keys on a pc105 keyboard that produce printable, non-whitespace characters, so they would fit perfectly into 2x6x4 if all the whitespace and modifier keys could be relocated elsewhere, e.g. under the thumbs. However the shift keys in particular have often been kept under the little fingers in grid keyboards for user familiarity, requiring further compromises elsewhere. Unfortunately these are almost always made with only us_ascii in mind.
When keymaps go bad
The default Kinesis Advantage arrangement (for example) is tolerable under a pc105 us_ascii keymap, but is nasty under alternative keymaps, as it differs too much from the traditional 105-key arrangement and so breaks too many assumptions that most keymaps are designed under (e.g. that “[” is to the immediate right of “p”). It leaves the shift, tab and caps-lock keys inside the core 2x6x4 grid and moves four printables to a row below “z” along with the cursor keys. It also rearranges some of the remaining symbol keys to slightly non-standard positions. This is where the trouble starts.
Kinesis Advantage default arrangement + us_ascii keymap:
= 1 2 3 4 5 6 7 8 9 0 -
tab q w e r t y u i o p \
cap a s d f g h j k l ; '
lsh z x c v b n m , . / rsh
` § <--> ^--v [ ]
(NB the key I’ve labelled “§” is the “international key” that is normally located to the left of “z” outside the USA and produces a variety of symbols depending on your exact keymap)
It’s only if you speak English that these innocent rearrangements are mere “symbol keys”. In most other language keymaps, one or more of these scancodes maps to an accented letter. And if the key you were expecting to be at the right of “p” disappears to somewhere below “.” your touch typing is screwed.
Consider for example what happens if we ask the OS to apply the us_dvorak keymap instead of us_ascii:
] 1 2 3 4 5 6 7 8 9 0 [
tab ' , . p y f g c r l \
cap a o e u i d h t n s -
lsh ; q j k x b m w v z rsh
` § <--> ^--v / =
A Dvorak touch typist (particularly a programmer!) expects “/” to be the key to the right of “l”. Kinesis try to get around this by recommending their users not to use their OS-supplied Dvorak keymap, but instead use a hotkey to change the keyboard’s firmware arrangement to another custom one that they provide. This however has just as many oddities as their QWERTY arrangement:
= 1 2 3 4 5 6 7 8 9 0 -
tab ' , . p y f g c r l /
cap a o e u i d h t n s \
lsh ; q j k x b m w v z rsh
` § <--> ^--v [ ]
Sorry, but the key to the right of “s” in Dvorak should be “-“. For touch-typing, this is even worse than losing “/”!
Dvorak is bad enough, but in other language keymaps the scancodes just to the right of “0” and “p” are even more vital. In a Scandinavian keymap, the key to the right of “p” should be “Å”. In Italian, this should be “è”, and in German it should be “Ü”. And now look at how many accented letters the Hungarian layout requires.
Most other symmetric-grid arrangements make similar errors. Here’s Maltron with us_ascii:
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 , . /
- =
Again, the key to the right of “p” has gone walkies, as have the keys to the right of “0”, which have disappeared into the extra row. On the bright side, the keys to the left of “q” and “a” are used relatively sensibly.
One commonality between all these imperfect arrangements seems to be a desire to keep the square brackets “[]” together on the keyboard. But for touch-typists, particularly those who speak a language other than English, it is much more important that “[” is to the right of “p” and above ” ‘ “. But all is not lost!
A universal keyboard arrangement
The following 2x6x4 arrangement minimizes the pain across a wide selection of standard European language keymaps:
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 , . / ]
This only relocates three keys when compared with pc105 — “`”, “]”and “\”. The first is only moved by one position and the second by two, but the third unfortunately has to move the whole way to the opposite side of the keyboard — we just don’t have enough spare keys under the right hand to do otherwise. Considering though that this is the key most inaccessible to touch-typists on a pc105 keyboard, its new position could be considered an improvement (and for UK keymap users, its placement beside the “international key” is entirely sensible!). Other than these three changes, no surprises lie in store for touch typists — and the only ones likely to find a letter (rather than a symbol) at the wrong side of the keyboard entirely are the Hungarians.
Sorry.
Note that the positions of “-” and “=” have been preserved by left-shifting the number row (as per Maltron). This is not as far-fetched as it seems — old-school touch typists were taught to hit “5” and “6” with their left index finger etc., because the number row on pc105 is shifted almost a whole key width to the left of the home row due to column stagger. The placement of the numbers is also particularly suited to keyboards that have the function keys in an embedded layer, as F1 can be trivially mapped onto 1, F2 onto 2 etc. without running out of keys for F11 and F12.
Also note that “[]” are not totally disassociated — they remain close together and symmetrically arranged around the home row little finger position. The slight inconvenience for us_ascii users here should be weighed against the vast increase in usability for non-English keymap users.
(BTW it is relatively easy to apply this arrangement to existing programmable keyboards such as the Kinesis Advantage, although in that particular case it is easier to keep the number row in the position that matches the labels and live with “=” being in an odd position).
A plea to keyboard.io
You don’t have to use the exact arrangement I suggest above, but if you don’t then please take into account that not everyone uses us_ascii, and being able to change keymaps in the OS and touch type is a desirable feature for many people, particularly those who work in more than one language.
And maybe if we do find a key arrangement that works acceptably for everyone, it could become a de facto standard for grid-symmetrical keyboards — and everyone will ask for a “keyboard.io layout” in the future…!
The Fifth Wheel of andrewg 
