Evaluating Keyboard Layouts

Pre-processing a sample text

Before feeding a text to a keyboard in order to evaluate performance, the text is reduced to a list of words. Each word in the list comes with a number indicating the number of times it occurred in the sample text. The idea here is that we don't want to repeatedly process a word. We only want to go through it once and multiply the effect by the number of occurances.

At this point, the sample text is also changed into all lowercase so that "Either" and "either" won't look like different words. However, "either" and "either." are treated like different words as much as "dog" and "dogs" would be.

Processing the Word List

Each word is changed into a series of letter groups. Letters are grouped together if they occur in the same hand as the word is typed. Example:
things
breaks into the letter groups
t
hin
gs
for the QWERTY keyboard, because 't' occurs in the left hand, 'hin' occurs in the right hand and then back to the left for 'gs'.

Scoring Parameters

Each of the letter groups is used to search a list that associates letter groups to numbers that represent the "goodness" of that letter group.
Example: Let's say "things" occurs 10 times. 't' is worth 10 points. 'hin' is worth 30 points. 'gs' is worth -1. 
            t  : 10 x 10 = 100
            hin: 10 x 30 = 300
            gs : 10 x -1 = -10
            ------------------
                    total: 390
So the score for all the occurrances of "things" in the sample text is 100 + 300 - 10 = 390.

For my program, this list of letter groups and scores resides in a text file read by the program. This allows the user to adjust values assigned to each letter group. There is some work involved. My parameter file defines nearly 800 letter groups. Also, there will be some letter groups that don't receive a score. This is a weakness or at least a questionable method, but so far, I like the results. I have tried to address this weakness by having the program tell me which finger combinations were occuring often and yet going unscored. I gave a score to those combinations I found most significant.

With 800 scoring parameters, it would be hard to experiment by changing the parameters, producing a new set of high-scoring layouts and then testing them to see which parameter setting produce the "best" layout. In other words, it's hard to know how to create a scoring system that would produce the best possible layout because it's hard to know (or learn) what would make that layout "the best." Searching a 37-dimensional space for a global minimum would be hard enough if we would know the minimum at a glance, which we wouldn't.

Scoring by Finger Odometer

My program has a provision for measuring the distance travelled by fingers during the typing of the sample text and using that distance as the score. Since my program tries to find the layout with the lowest score, scoring by distance travelled causes the program to search for the layout that requires the minimum finger movement.

Minimizing finger movement seems like a good idea, but I have found that I prefer typing on best-scoring keyboards to typing on the keyboards with minimal finger travel. This might be because scoring solely by finger travel disregards aspects like finger spreading and wrist twisting. In creating my scoring parameters, I have tried to reward finger combinations feel good to type. As it happens, this tends to minimize finger travel, though not as well as if minimum distance were the only goal.

Last changed: $Date: 2008-09-16 17:45:26 $
Hosted by www.Geocities.ws

1