Hi,
Following on from my earlier messages, I've now written a very simple
Twiddler simulator and run it over two very different samples of text (a
2,700 word short story, and the source code to the Twiddler simulator
itself) using three different keyboard layouts (the default alphabetical
layout supplied by Handykey, Brad Rhodes' SHRDLU layout, and Brandon
Rhodes' Tabspace layout). The results are, to say the least,
interesting...
First off, though, I should say that these results should be taken with a
liberal dose of salt: they're interesting, but not very scientific. See
the postscript for the various limitations and possible problems with this
simulation.
The simulator works by reading in a standard Twiddler ".ini" file (thanks
to Bradley Singletary for suggesting this) to get a keyboard layout, and
then simulates typing a sample body of text (taken from a text file) using
that layout. It analyses the finger actions required to type the sample
text using the given keyboard layout, and provides a variety of statistics
which can then be used to compare, in a very crude way, the
efficiency/useability of different keyboard layouts.
Okay, so here are the results of running the simulator over two different
types of text and three different keyboard layouts:
Story Story Story Code Code Code
Default Shrdlu T/Space Default Shrdlu T/Space
------- ------ ------- ------- ------ -------
Num chars typed: 15013 15013 15013 17085 17085 17085
Num thumb-presses: 337 337 337 1094 1069 765
Num thumb-releases: 337 337 337 1093 1068 765
Num keys pressed: 14884 17355 15633 17819 20008 18090
Num keys released: 14882 17353 15631 17816 20006 18087
Num keys held: 3584 4002 4255 7428 8482 6867
Num finger switches: 7297 7601 3288 8133 7366 5768
Num 1-key keystrokes: 6510 6696 6177 6195 6422 6870
Num 2-key keystrokes: 7121 2801 4959 8669 5415 5537
Num 3-key keystrokes: 75 4289 1020 1171 4276 2383
Num 4-key keystrokes: 0 94 218 0 159 147
Finger 1 L presses: 3756 1115 684 3380 2022 1317
Finger 1 M presses: 2990 2258 3767 3032 2543 3703
Finger 1 R presses: 1559 2716 46 1543 3158 531
Finger 2 L presses: 639 1372 1244 930 1904 1651
Finger 2 M presses: 1158 1606 2014 1736 2126 2417
Finger 2 R presses: 1726 3337 1133 2124 2479 1274
Finger 3 L presses: 376 1485 1204 1137 2206 1549
Finger 3 M presses: 737 1496 1598 1032 1117 2304
Finger 3 R presses: 1389 3093 1159 1150 2575 1503
Finger 4 L presses: 107 1148 1035 602 1621 1263
Finger 4 M presses: 1633 1399 1285 1463 1540 1109
Finger 4 R presses: 1445 2851 1172 1978 1993 681
Time factor: 51442 53633 40205 69621 69085 57270
Okay, some explanations: "Num keys held" is the number of keys held from
one keystroke to the next, allowing for the fact that you have to release
at least one key to register a keystroke (eg, ML00 -> 0L00 -> ML0L). "Num
finger switches" is the number of times a finger has to lift off one key
and press another to go from one keystroke to the next. Finger 1 = index
finger; finger 4 = little finger. For information about the time factor,
see the postscript (bigger values very roughly equate to more time required
to type).
So what does all this mean? Well, basically Chris George at HandyKey is
right: the alphabetical layout is actually rather good. I was *very*
surprised to compare the SHRDLU layout with the default and see that, for
my sample texts at least, the SHRDLU layout required more keypresses than
the default. In fact, even using my (very rough) estimation of typing
time, the default layout is faster than the SHRDLU layout for typing plain
English text. The SHRDLU layout is (assuming my model is accurate -- a big
assumption) slightly more efficient than the default at typing Java source
code. So, making far more assumptions than might be healthy, if you're
coding, the SHRDLU layout would be very slightly more efficient than the
default, but if you're typing plain English text, the default wins hands
down.
But...take a look at the results for Brandon Rhodes' Tabspace layout. IN
THEORY (and again, I'm making big assumptions here), this layout is *much*
more efficient than the default at typing both plain English text and Java
source code. On the face of it, these results are very impressive
indeed...in the order of a 20% reduction in the amount of time it takes to
type a given amount of text.
Of course, all this *MUST* be taken with a healthy dose of skepticism. The
tabspace layout is unproven, and the fact that my simulator shows a 20%
reduction in typing time may not translate to any significant improvement
at all -- the fact that this layout requires you to memorise the order of
common letters and only ever use the macro when the letters appear in that
order may make this layout less efficient than these results show. My
simulator is, of course, idealised (and may well be buggy)...but still,
these results do look promising for Brandon's layout...
I'd love to hear from anyone who has actually memorised the tabspace
layout...does the letter-ordering become a nuisance at times?
One thing that would be interesting would be to pull apart the time factors
and see just how these savings are being achieved...I'll have a play with
this over the weekend.
Okay, that's more than enough verbage from me. Does anyone else find these
results interesting? Does anyone have any suggestions for ways to improve
the simulation, or other things to look for when analysing the results?
I'd be happy to pass on the source to the simulator to anyone who is
interested -- though be aware that it's written in Java (alas, the only
language I'm currently set up to develop in quickly) and not fully tested
on various platforms...
- Erik.
PS: Okay, for those of you keen enough to still be reading, here are some
caviats about these results, and further explanation of how the time factor
was calculated. As I've repeatedly said, these results are very
unscientific...here's why:
* I've just knocked this programme together quickly, and there may well be
bugs in my simulator logic.
* The results are idealised. They assume that the user will *always* use
the most efficient keyboard command to type a certain body of text. In
practice, shortcuts which are hard to remember or hard to type would
probably be ignored, and the user would just type out the individual
letters.
* The sample text only includes ASCII characters -- this test didn't
examine the efficiency of typing control-key sequences, backspace
characters, arrow keys, function keys, etc. If I was to do this test
properly, I'd use a Twiddler as my main input device for a length of time
and record every keystroke made, then run that record through the simulator
to see how various layouts would cope.
* I've made a huge number of assumptions in my simulator to calculate the
"time factor" for a particular body of text and keyboard layout. Playing
with the Twiddler for a while, I started to think about what constrains
your typing speed, and included these constaints into the simulator.
Obviously, this is a highly unscientific process...and as for the "time
cost" associated with various finger actions, those were a complete guess.
********
And finally, an explanation of how the time factor was calculated. The
time factor is basically just a *very* crude way of comparing the amount of
time taken to type a given body of text using different keyboard layouts.
This value has no relationship to any real-world measurement of time; all I
did was look at finger motions required to type text using a particular
keyboard layout, and rather arbitrarily assign a "time factor" value to
each type of finger motion (eg, if you press a key with a finger that
wasn't being used at the time, that action was given a time factor of 2;
moving a finger from one key to an adjacent key was given a time value of
4, while moving a finger to the key two columns over was given a time value
of 6). The time factor was calculated for each of the four fingers, and
the highest value used as the overall time factor for the keystroke. I
then added extra time for any use of the thumb-switches (since I find these
awkward to use), and also adjusted the time factor upwards if two, three or
four fingers had to move from one key to another (the time factor was
multiplied by 1.5, 2, and 2,5 respectively). The resulting number is
basically meaningless, except that larger values mean that, according to my
rather crude model, more time would be spent typing the text using that
layout. Thus, this value can be used to (very roughly) compare different
keyboard layouts...
--
Subcription/unsubscription/info requests: send e-mail with subject of
"subscribe", "unsubscribe", or "info" to 
Wear-Hard Mailing List Archive (searchable): http://wearables.blu.org
From Wear-Hard Mailing list Archive (WH)
Maintained by R. Paul McCarty
Archive created with babymail