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 ProjectAbstractThis 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 StatusI am looking for opinions and/or people with programming skills. Currently, the following people are working on this project: The Physical Layout Of The KeysThe 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
The Thumb PadsThe Modifiers KeysThe 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 CharactersThe 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 KeysFor 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 LayoutIf 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.
(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 PadsWe 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
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 LayoutThe 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.
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 CorpusWe 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.
Todos
Finding The StrainWe 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
Contra-Lateral Versus Lateral TypingDvorak 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
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 StrainA 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 CoordinatesThe coordinates of the keys under the right hand finger's control are shown below. The Strain AlgorithmHand loadTo 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 handFirst 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. For instance, for the rtp we should add 50%. How typing a key affects the strain on the same handTyping "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:
The Keyboard Layout Strain MeasureThe strain measure on a layout is defined as the average strain per character written. Finding the Best LayoutNow 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 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.
I am sure there are other smart mutation rules. Todos:
The Sensation Keyboard Layout<The keyboard that has the least strain.> |
Home | Hand Evaluation in Bridge | C Programming | Keyboard Layout |
Håkon Hallingstad |