Yesterday I finished the Prototyper hardware and wrote software to collect information on timing between keypresses. The firmware I wrote accepts commands over serial that specify a first key and a second key. Then it sends back the number of milliseconds between when the first key is pressed and when the second is. A Processing sketch running on a PC prompts the human being tested to press specified randomly chosen key sequences. It records the data collected from the hardware to a CSV file.
Data
After finishing the firmware and PC software and working out a couple of bugs I did a test run on myself. I recorded about 1000 key sequences (~2000 key-presses). Then I wrote a Python program to generate the matrix graph below, where average timing for every key sequence is normalized and color coded. The left-hand vertical axis is the "from" key, and the horizontal axis is the "to" key. The numbering starts with 0 at my right hand pinky and goes to 9 at my left hand pinky.
Observations
The data is noisy and I suspect that there is not yet enough of it to draw strong conclusions. But some preliminary observations can be made:
- The yellow spattering in the upper right seems to indicate that it generally takes me longer to go from my right hand to my left hand.
- My left pointer finger is pretty fast overall, which is strange because I am right handed.
- My right pointer finger is slow if the next key is on the left hand, but generally fast otherwise.
- Pinkies are the overall fastest. I think this has to do with the weird way I learned to type on QWERTY keyboards.
Improvements
Having data is exciting, but I need to make sure it really tells me what I need to know before relying on it. There are a couple of problems I need to resolve before I use Prototyper to collect much more data:
- While collecting those thousand samples I noticed that it took me a lot longer to get ready for certain key sequences. Because I was only recording the time between the first press and the second, that setup time was lost. For the future I will collect that time on the PC side and record it.
- The data gathering PC application indicates key sequences with colors. Green is the first button to press and red is the second. Often I would simply make the mistake of messing up the order of presses. This reflects a poorly designed GUI, not problematic sequences, so I'm going to replace colors with an arrow that pulses in the right direction.
- Just taking the mean of times for a key sequence when analyzing the data is probably a bad idea because a single outlier can mess up the whole set for a key sequence. I don't know much about statistics, but friends of mine do, so I'll get their help in future analysis.
- I should be recording when completely incorrect keys are pressed, because that is also indicative of a problematic sequence.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Even with that said 120wpm averages out to 10 chars a second, 100ms find time. People push a on little from there. Records beyond 130 or so are typically done by stroking full words. Stroking those words in a slower time that is probably averages closer to 200ms, maybe because many odd words are multi stroke in steno devices. Hear me right.. fastest speeds are probably unimportant for most people, just trying to set context for data gathering.
Character to character testing might be more practical information for you, as thinking and commitment of memory ends being more the bottleneck for most people rather than phisical cabability.
Are you sure? yes | no