Home Hand Evaluation in Bridge C Programming Keyboard Layout

Note: This is a page under constructon. See arensito for viewing a finished keyboard layout.

An Optimal Keyboard Layout Project

Abstract

This is a status document for the OKL project. The goal is to produce the best possible layout, by first finding the best possible physical layout of the keys, and then the best possible layout of the characters. All characters should be considered, even shifted characters, the shift character, backspace, etc...

When this project is finished, we should provide all information needed to fully understand (and redo) the whole project. We will also need to provide the user with a java applet that let anybody compare optimal layout with the qwerty, dvorak and maltron layouts.

Current Status

I am looking for opinions and/or people with programming skills. Currently, the following people are working on this project:

The Physical Layout Of The Keys

The two main deficiencies in the standard physical layouts today is that the column do not align up with the natural movement of the fingers, and that the thumbs should access more keys. I think that in the future, such keyboards will become standard, and already today we see the early stages of this development. Both the Contoured Kinesis and the Maltron keyboards are such keyboards. We should not take for granted that these two keyboards are perfect. This chapter tries to find the optimal layout of keys (in 2D space. The layout will typically have a bowl-shaped form in 3D).

The characters/keys we should try to place are

Character Group Number of Chars Number of Keys Characters
Letter 52 26 a A b B c C ...
Punctuation 42 21 0 1 2 3 4 5 6 7 8 9 ! ? + * - / = ^ # $ ( ) { } < > [ ] & @ % " ' ` . : , ; _ | ~
Navigation 8 8 Home, end, page up, page down, and the four arrows.
Functional 12 12 F1, F2, ..., F12.
Modifier 4 4 Shift, Control, Alt, Alt-gr
Special 8 7 Space, Enter, Backspace, Delete, Tab (and Backtab), Esc, Insert
SUM 126 78

The Thumb Pads

The Modifiers Keys

The thumb should control keys that typically have to be pressed simultaneously with any other keys, ie the modifiers keys. The alt-gr should not have to be used for english users, while other users either include a alt-gr or include more keys on the keyboard to make up for the extra characters. However, there could be great uses of the extra modifier. For instance the alt-gr might be used to control the workspace/windows.

Having the modifier keys under the control of the thumbs, will releave much work of the pinkies. Especially when you will want to hit two or more consecutive keys with the same modifer key, but when the keys are found on each hand. (Such as control-a, control-p, or shift-1 shift-=.)

A note on the caps lock: It may be built into the shift key with the following mechanism: Caps lock should be turned on/off if you press and release shift without pressing any other keys.

The Special Characters

The thumbs could also control keys that are common non-letters, typically the special characters. For instance, it is a bad idea to put the space under any of the non-thumb fingers, because it is very frequent and occurs before and after any other character. Putting backspace and enter under the thumbs should also relieve the right pinkie considerably.

Not all special character keys need to be placed under the thumbs, it depends on how much the thumbs may take without stressing them. If you have any experience with Contoured Kinesis or Maltron, please tell me of your experience with them. At this moment it seems that the thumbs easily may the number of modifers and special characters.

Placing The Thumb Keys

For most of these keys, analysing texts will not help finding how these are used. The backspace- and delete- keys will not leave any trails in any texts, and the enter, control-, alt- and escape- keys will be used in non-text operations that leave no trails in texts. The best way to do statistics on these keys would be to hack the X server to log key use. The result for some of the keys will be very dependent on the environment used (KDE/GNOME/...) and the habits of the testperson. However, any statistics is better that none.

I will assumed that space, backspace, return and shift are by far the most used keys of the thumb keys. The space will be used very frequently while writing text, so it should not be on the same finger as backspace and shift. To balance the load we should probably put the return with the space, although there might be too high frequency of space-return digraphs...

TODO: Log keysstrokes in the X server

Thumb Pad Layout

If all of the modifier keys and the special characters are placed under the thumbs, we should get something like following. I have sorted the keys in descending order of importance.

Thumb Pads
Left thumb Right thumb
Backspace Space
Shift Enter
Control Control
Alt Alt
Esc Tab
Alt-gr Delete

(Note: I left the Insert out of the thumb pads, for no other reason than to balance the table. The key is not much in use however, and it may be put on the hand pads instead.)

The keys that should be the easiest to access are put in the middle.

The Hand Pads

We should have a top row of the functional keys, and a bottom row of navigational keys. This leaves us with 48 keys for the letters and punctuation characters (and the insert), 24 for each hand. So we get the following

F1 F2 F3 F4 F5 F6
           
           
           
           
  pg up up down pg dn  
F7 F8 F9 F10 F11 F12
           
           
           
           
  home left right end  
Esc
Alt
Shift
Bspace
Control
Alt-gr
Delete
Alt
Enter
Space
Control
Tab
Indexing the keys
The keys may be reference independent on either hand by a coordinate <row> <column>. When the hand needs to be referenced, precede the coordinate with l (left) or r (right).
Rows
The row from bottom up will be called b (bottom), l (lower), h (home), u (upper), t (top) and f (functional).
Column
The column (on the left hands from left to right) will be called e (extreme), p (pinky), r (ring), m (middle), i (index) and c (center). Similar notation on the right hand. The thumb is given the column name t (thumb).
Home keys
The home keys are shown in black. Their coordinates are hp, hr, hm, hi and ht. The home columns are the columns index, middle, ring and pinky.

The above layout fits excatly onto both the Maltron- and the Kinesis- keyboards. The only difference is that the Maltron has 8 thumb keys per pad, while the Kinesis has 6 thumb keys per pad.

The Scope Of The Layout

The keyboard will be optimized for english, with adjustments due to other western languages. Western languages are quite similar, and we should therefore try to include other non-english languages to get a bigger scope of the keyboard layout. The weight of the different languages should be according to the people speaking/using the language, except that we should overrepresent english (as it is an international language), and underrepresent languages in the development countries (which do not use the keyboard to the same degree).

I found the number of people speaking the different western languages at infoplease.com (search for 'languages') from 1996, and decided for the following weights of the different languages.

Language Population Percentage Factor Weight National Characters
English 322 30.6% 2.0 58%
Spanish 332 31.6% 0.5 15% ñ ç ¨ ´
German 98 9.3% 1.0 9% ß ü ö ä
Portuguese 170 16.2% 0.5 8% ç ¨ ´ ª º
French 72 6.9% 1.0 6% é è ç à ¨ ù
Italian 37 3.5% 1.0 3% è é ç ò à ù
Dutch 20 1.9% 1.0 1% ¨
SUM 1051 100.0% 100%

The national characters are fit into a standard qwerty keyboard by using the alt-gr modifier. We should allow for national variants of the layout, but only in a few characters. The basic structure should remain the same, in particular, all english letters should remain fixed in all variants. We will disregard the national characters, but we should try to include statistics on the other 'english' letters for the given languages weighted by the above numbers.

The Corpus

We should now try to find a corpus that may represent the use of the keyboard. The American National Corpus will very soon provide a wide diversity of text for analysis. The ANC will release the first texts in the Fall of 2002. We will need other corpuses for different languages.

We should define the representation of different classes of texts ourselves, as the ANC collection does not seems to represent typicla typing at the computer.

Share Class Examples
20% Literature Books
20% Media News, magazines, periodicals
20% Easy writing Mailing lists, news lists, emails, essays, letters
20% Informative Scientific and business texts
20% Programming Source code from C, C++, Java, Latex, Linux user manual, Matlab, numbers, Perl, Python, XML

Todos

  • Agree on the composition of the corpus
  • Collect and make the corpus available

Finding The Strain

We should now try to find a metric that measures how easy it will be to write with a given keyboard, and how much strain there is to the fingers, hands, arms and shoulders. The metric should account for the following factors

Repeated use of a finger
We should avoid using the same finger in digraphs and even trigraphs. Excessive use of a finger causes strain.
Unatural stretching
We should avoid writing digraphs on the same hand when the characters are separated by rows, since that involves twisting the hand, and spreading and straining the fingers. This is especially true for adjacent fingers.
Fast one-handed one-directional sequences
Often a hand resting will position itself to hit a one-directional sequence of characters, almost in one hand movement, once activated. This is especially true for adjacent fingers on the same row. This burst-typing is experienced for instance with the "er" combination on the qwerty keyboard. The arensito layout contains many more examples.
Slow one-handed bi-directional sequences
The fast one-handed sequences let your hand roll in the typing direction. This is prevented if the sequence goes in both direction, for instance an "aser" sequence is easier to write than an "asre". (Long one-handed sequences automatically involve bi-directoinal finger movement.)
Individual Finger Load
The pinkies should have less load than the rest of the fingers, while the thumbs may have more load. Only the pinkies, index fingers and the thumbs are flexible for off-diagonal movement.
Hand load
The right hand may have slightly higher load than the left.
Extra work if shifting is involved
Perhaps the most extra work when writing is when there is need to access a character in the shifted state. This must be modeled in the strain.
Visible rows
It is easier to find characters in the visible rows above the home row than in those rows that are hidden. This makes a difference for beginners and for typing infrequent characters.
Logical layout
With the above, it is not likely that the "A" will be found in the shifted state on the same key as the "a". We will have to enforce this for all letters. And it is not likely that the numbers will be put out in an ordered sequence like 1234567890. We will have to permutate them after the optimial layout have been found by the algorithm.

Contra-Lateral Versus Lateral Typing

Dvorak made his keyboard on the assumption that contra-lateral typing is faster and less strainful than lateral movement. From the above, I largely agree to this, but we should remember that

  1. Whenever a sequence of characters are either outwards (like "fdsa") or inwards (like "asdf"), the hand may type those characters in one hand movement, as opposed to many hand movements if they are typed with alternating hands.
  2. For two consecutive characters, it is easier (for the brain) to coordinate the movement of two fingers on the same hand, than coordinating two fingers on separate hands. This means we should expect slower typing and transposition errors for contra-lateral typing.

Lillian Malt, the designer of the Maltron keyboard, provides some interesting data that shows that lateral typing actually is quicker. See the Keyboard Design in the Electronic Era, especially the chapters following "Effect of keyboard design". She also has found that placing frequently used vowels next to each other confuses the brain, leading to substitution errors.

Before you make any judgement as to whether the above holds true I must, to your defence, say that part of the difficulties related to writing long sequences of characters are related to the physical layout of the standard layout. Both unaligned columns and that the fingers have unequal length makes typing with one hand difficult. Both of these obstacles are removed on a optimal physical layout. I am currently using the Kinesis and notices a BIG difference in the comfort when typing, ESPECIALLY when writing one-handed sequences. (This was also noted by Dvorak, even though it did not seem to affect his design.)

The Unit Of Strain

A strain of 1.0 is defined to be the strain of writing the key rhm (right hand side, home row, middle column), when the characters before and after are written with the left hand. Whenever we refer to a percentage of strain, it is relative this strain. So a strain of 5% is equivalent to 0.05.

The Finger's Coordinates

The coordinates of the keys under the right hand finger's control are shown below.

Right hand coordinates

The Strain Algorithm

Hand load

To account for the (generally) better agility and strength of the right hand, we will add 5% (or 0.05) to the strain of typing all keys by the left hand.

Single character typing by one hand

First we will add some strain to add for far off keys. This will be a simple measure of how easy accessible the keys are (or should be if you are not using a good physical layout), under the condition that both the previous and next characters are typed by the other hand.

Simple row/column strain addition

For instance, for the rtp we should add 50%.

How typing a key affects the strain on the same hand

Typing "de" (on qwerty) is quite a lot more strainful than typing "di". If you write "die" your ringfinger is put under almost the same strain as when writing "de". For "dime" the ringfinger is much more relaxed and for "dinne(r)" is extra strain is unnoticable.

Related to this is the extra strain of typing an digraph with like "eb" (where the "b" is written by the left index finger) or "xe". The strain of typing "b" after having typed "e" also will diminish if more letters are written between the two. On the other hand if you write "er", the effect would be to reduce the strain of writing the "r".

So we will provide one table which lists the extra strain in writing any two possible digraph on one hand with 0 characters written between the two characters. And we should provide a similar table when there is 1 characer written between the two characters, ... etc. Note that this strain is in addition to the strain found by the placement of the keys (above figure).

Todos:

  • Propose and agree on a strain algorithm

The Keyboard Layout Strain Measure

The strain measure on a layout is defined as the average strain per character written.

Finding the Best Layout

Now that strain has been defined, we will try to find the layout that gives the least average strain. Peter Klausler has made an evolutionary algorithm for picking out the best layouts.

The Evolutionary Keyboard Algorithm

We got 68 characters to place on 48 keys, 26 for the alphabet and 42 for the punctuation characters (plus one for the insert key). There are then about 68!=2.5 10^96 number of possible layouts. This is so huge, that we should verify that the algorithm is any good.

We would expect the less frequently used characters to play a minor role in the placement of the characters. This means we could reduce our problem to finding a optimal layout for a smaller subset, and then use that as a seed. We could do this for 24, 36 and 48 keys respectively.

The shifted state of a key is much more expensive than the unshifted state. This means we could look at characters in the unshifted states first.

We should also look for more efficient ways to permute/mutate a keyboard.

  1. A mutation that moves 'e' to a peripheral key should be less likely than the opposite move.
  2. Moving a frequent character to the shifted state should be less likely than the opposite direction.

I am sure there are other smart mutation rules.

Todos:

  • Modify the Evolutionary Algorithm to include 48 keys, and possibly let us define characters for the thumbs.
  • Modify the EA to make smart mutations
  • The calculations must not use a list of the most frequently used words. Trigraphs may include characters from two different words, and punctuation characters break the word definition. We should base the information on monograph-, digraph- and/or trigraph-statistics (quadruple-statistics?), and possibly include additional statistics.
  • (I have not studied the code yet, but we should...) Stop calculating the strain on a keyboard if it will be too high.
  • Distribute the calculations of strain to clients on the internet. Or make a version that will run as a client process on people's machines that calculates strain and forward results to a server.

The Sensation Keyboard Layout

<The keyboard that has the least strain.>

Home Hand Evaluation in Bridge C Programming Keyboard Layout
Håkon Hallingstad MyEmailAddress Valid XHTML 1.0! Valid CSS!
Last modified: Sat Aug 17 00:21:41 CEST 2002