Skip to content

Instantly share code, notes, and snippets.

@trishume

trishume/velo_stats.md

Last active August 29, 2015 14:08
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save trishume/3725b2ca0950d018970a to your computer and use it in GitHub Desktop.
Save trishume/3725b2ca0950d018970a to your computer and use it in GitHub Desktop.
Download ZIP
Data on Chording Keyboard Layout Efficiency
Raw
velo_stats.md

Pure Velotype system without layout:

the theoretical maximum for an orthographic chording system based on start+vowels+end

3.2 characters per stroke = 1.49 strokes per word

Velotype with extra suffixes no layout (er|ed|en|e|ion|able|ing|al):

same as above, but with the ability to type common suffixes is the same stroke

3.46 characters per stroke = 1.38 strokes per word

Velotype system no double characters:

same as first, but not allowed to type same character twice with same hand

3.15 characters per stroke = 1.52 strokes per word

Velotype system with layout collisions:

Simulation of using the actual Velotype layout, no suffix strokes

2.98 characters per stroke = 1.622 strokes per word
7% of words take more strokes on real layout than theoretical optimum (first one)

Best layout I've come up with

A layout I tried to design based on the co-occurence of letters and other fancy heuristics. It worked out worse than Velotype, turns out Velotype is actually very well designed even though it was done manually. I can't do better using fancy computer models that crunch hundreds of thousands of possibilities.

2.93 characters per stroke
10.4% of words take more strokes on real layout than theoretical optimum (first one)

Stenotype with briefs and shortest dictionary entries:

3.74 characters per stroke = 1.14 strokes per word

Stenotype no briefs and longest dictionary entries:

3.0 characters per stroke = 1.60 strokes per word

Velotype with autocomplete based on the first strokes (no layout):

an idea to display most common word on screen that starts with strokes entered so far, if the user wants that word they move on to next word, otherwise they enter the rest of the strokes or type a "don't complete" stroke. This increases efficiency at the cost of needing a feedback loop, which means that very high speeds are not possible because the user needs to incorporate info from the screen into what they are pressing.

4.26 characters per stroke = 1.18 strokes per word
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment