Metrics for computation

[HughP]

@michaeldickens You might remember me form some previous comments, issues #16 and my recent pull request. I am posting again because if nothing else it seems that your work here could be an academic publication presenting your model (so I also include some citations to academic publications in this comment). But beyond that I have an interests in your stats model for my work. I see several statistics in your blogposts. I went through some of the inline comments in your code. And found that /doc/Fitness.txt was helpful to an extent. That is, I am trying to compare your work here in this repo with other sets of metrics and methods of evaluation used in academic publications (PDFs available of all citations on request) such as those listed below using Ant Colony Algorithm and the Cyber Swarm method:

Ant Colony:

• Eggers, Jan, Dominique Feillet, Steffen Kehl, Marc Oliver Wagner & Bernard Yannou. 2003. Optimization of the keyboard arrangement problem using an Ant Colony algorithm. European Journal of Operational Research 148.3: 672-86.
• Wagner, Marc Oliver, Bernard Yannou, Steffen Kehl, Dominique Feillet & Jan Eggers. 2003. Ergonomic Modelling and Optimization of the Keyboard Arrangement with an Ant Colony Optimization Algorithm. Journal of Engineering Design 14.2: 187-208.

Cyber Swarm/GKAP

• Yin, Peng-Yeng & En-Ping Su. 2011. Cyber Swarm optimization for general keyboard arrangement problem. International Journal of Industrial Ergonomics 41.1: 43-52.

Let me run down your list of metrics and explain what I understand then hopefully you can comment and make suggestions.

HANDS

• Hands: Right and left for balance

FINGERS

• Fingers: for finger load Both of these metrics seem to be standard part of the discussion since Dvorak made his famous claims.

These first two metrics are pretty standard and strait forward (and are also mentioned here):

• Parkinson, Robert. 1972. The Dvorak simplified keyboard: Forty years of frustration. Computers and Automation 21.11: 18-25.

FITNESS I did read your three lines about fitness computation in fitness.txt but it wasn't very clear, I mean: How from a list of digraphs is this really computed? I know what a digraph is in a language like English, but would it be better to articulate this as 'keys needed to create and orthographic set'? I mean on standard OS X QWERTY if one wants to type an umlaut < u > one must hold alt then press e and then press u. So would this be considered a "digraph"? There are other keyboards in the world which use dead keys, so for instance if I wanted to type < é > in some African languages I might type ; followed by e... does that become a "digraph" in this computational model? It doesn't seem that Fitness is a measure of reach strain. Or by "digraph" to you really mean "Bigram" (aka an n-gram with 2 values)?

DISTANCE How is distance really computed? in Fitness.txt you talk about both distance and effort. I wonder if these should be more clearly discussed? I don't see any reference to concrete figures. My Apple wireless keyboard with 15mm² keys have center point values and can be measured, so in your app is the distance measure tied to a concrete measure or is it more abstract, and if abstract how so? I would imagine that keyboards with larger keys have an impact on distance too.

As a side note about distance, I did read an interesting article about the spacing between the keys affecting things link reach strain.

• Pereira, Anna, et al. 2013. The Effect of Keyboard Key Spacing on Typing Speed, Error, Usability, and Biomechanics: Part 1. Human Factors: The Journal of the Human Factors and Ergonomics Society 55.3: 557-66.

ROLLS

• Inward Rolls: Where the first key hit is on the outside of the keyboard (hand asdf or poiu) but the second key hit is on the inside (These key need not be concurrently located but must occur in the same row.)
• Outward Rolls: Where the first key hit is on the inside of the keyboard (jkl) but the second key hit is on the outside (These key need not be concurrently located but must occur in the same row.)

I buy the validity of rolls. I don't see Wagner et al. citing anyone for their validity but the following papers seem to confirm the general notion:

• Rempel, David, Alan Barr, David Brafman & Ed Young. 2007. The effect of six keyboard designs on wrist and forearm postures. Applied Ergonomics 38.3: 293-8.
• van Galen, Gerard P., Hanneke Liesker & Ab de Haan. 2007. Effects of a vertical keyboard design on typing performance, user comfort and muscle tension. Applied Ergonomics 38.1: 99-107.
• Kim, Jeong Ho, Lovenoor Aulck, Michael C. Bartha, Christy A. Harper & Peter W. Johnson. 2014. Differences in typing forces, muscle activity, comfort, and typing performance among virtual, notebook, and desktop keyboards. Applied Ergonomics 45.6: 1406-13.
• Zecevic, A., D. I. Miller & K. Harburn. 2000. An evaluation of the ergonomics of three computer keyboards. Ergonomics 43.1: 55-72.

RHYTHM BREAKS

• Same hand: Is a measurement where the same hand is is used to tap two consecutive keys
• Same finger: Is a measurement where the same finger is is used to tap two consecutive keys

Measuring the same hand and the same finger seem pretty strait forward. (However, is same finger include movement of the index finger from h and y on the QWERTY keyboard? or does the same finger only apply to tt or ee kinds of situations?) Dvorak and others argues for the validity of rhythm in the following (however what I don't see is a tap and hold measure which OS X introduced about 10.7):

• Dvorak, August. 1935. Developing Rhythm in Typewriting. The Journal of Business Education 10.6: 19-34.
• Kinkead, Robin. 1975. Typing Speed, Keying Rates, and Optimal Keyboard Layouts. Proceedings of the Human Factors and Ergonomics Society Annual Meeting 19.2: 159-61.
• Shieh, Kong-King & Chin-Chiuan Lin. 1999. A Quantitative Model For Designing Keyboard Layout. Perceptual and Motor Skills 88.1: 113-25.

The following metrics are still a bit confusing to me.

• Finger work: ??? I see the definition you have applied but what about the scale? What is the scale and how does it rate or change? How do we known when a finger is overloaded?
• Row Change: ??? Smooth and Warp both make sense but how is this different than distance computation?
• Ring jump: ??? When a percentage is shown, this would be the percentage of all bigrams in the training text, correct?
• To center: ??? What are the outside columns? and what is an inside column? if you need a picture diagram for reference consider my Jpeg here.
• To outside: ??? In Wagner et al. (mentioned above) there is some interesting work in providing penalties for fingers. These penalties are based on some of the same ideas I think you have about reach. But I wanted to make sure these are same-same.

In the academic literature there are also other keyboards you might be interested in. For instance a modification of Dvorak (for the list of modified keyboards):

• Martin, Alec. 1972. A new keyboard layout. Applied Ergonomics 3.1: 48-51.

[michaeldickens]

Fitness: Yes, I mean bigram. Right now every character that the program uses can be typed with a single keystroke, unless it's a shifted character. Shifted characters are counted separately.

Distance: I really use effort here, not distance, although distance approximates effort (more distant keys have higher penalties, but the relationship is not linear).

Rolls: You are correct about how these work, except that the two keys do have to be adjacent to count as a roll. If you look at calcInRoll() (or calcOutRoll()) in fitness.c., you will see that there are two versions of the function defined, and one of them is commented out. The commented-out version does what you describe.

Same Finger: This counts any time when you use the same finger twice in a row, even on different places on the keyboard.

A lot of the rest are similar to metrics used by Michael Capewell. You can see his page for more info.

• Finger work: The program calculates the percentage of the time that a certain finger is used, and adds a penalty if it exceeds a certain threshold.
• Row change: Distance penalties only account for single keypresses based on the absolute position of the key, not based on distance traveled from previous position. Row changes penalize every time you change rows on one hand.
• Ring jump: The shown percentage is the percentage of all bigrams in the text, yes.
• To center/to outside: Inside columns are the columns in between where your fingers lie on the home row, so TGB and YHN. Outside columns are the columns outside where your fingers lie on the home row.

Do you have a freely-available link to Alec Martin's 1972 paper? I can't find one.

[HughP]

@michaeldickens Should I email it to the gmail account in the help section of the application?

[michaeldickens]

@HughP Yes, that works fine, thanks.

[iandoug]

Just curious: is the thinking that led to Workman factored in anywhere? To pick up on key size, it's related to hand size and finger length. I've got an inherited condition that gave me pinkies missing the last joint. This affects typing (and music). I've been thinking about how to compare one layout against another, and the current models generally make some assumptions, like a standard size keyboard in slab configuration. To my thinking, that's part of the problem. If we're dumping QWERTY why are we still sticking to rectangular slabs? Ergo designs (MS Natural / Maltron / Kinesis / etc) are a start, but are they optimal?

So I'm trying to think outside the box (or slab), but now need a way to evaluate a given non-standard design (and if the program is smart enough to suggest improvements, then yes please).

I feel that an analysis program needs to work with physical measurements, both of the keyboard and keys and placements, and the user's hand size. Or is that just too complex? For example, knowing the distance between forefinger tip and pinky tip may rule our some common key combos (ctrl-V etc...).

[michaeldickens]

1. Each finger has a relative cost set at the bottom of values.c. If you want to avoid using pinkies, you can increase fingerWorkCosts[0] and fingerWorkCosts[FINGER_COUNT - 1], which correspond to the pinkies.
2. You can add new physical keyboard layouts if you want; see the README.