Introducing the Thumb Keys

February 27, 2012 88 comments

The Kinesis keyboard layout option on the keyboard layout optimizer now includes thumb keys (and a Tab key). It currently only includes the two right thumb keys, not the left, for two reasons:

1) I think it makes sense to put shift and backspace on the left thumb keys, and I don’t need the program to tell me that. Shift and backspace both have very high same-finger ratios with almost every key, so it doesn’t make sense to put them on a finger with other frequent keys.

2) Using shift and backspace (especially shift) is much more complicated than using other keys, because they interact so strangely with the rest of the layout. Shift is difficult to measure, because its frequency changes every time the shifted keyboard changes.

Once I began including the position for the tab key, the computer immediately moved it and started throwing it around to different parts of the keyboard. Apparently its original spot wasn’t so great. I decided to let it keep messing with tab because I don’t think aesthetics are very important in this case, but I did create an option for keeping tab in place. I haven’t created an option for leaving space and enter in place, but so far I haven’t needed to: the best keyboard always ends up putting them in their original positions.

The completed keyboard for Kinesis, including thumbs and shifted keys:

Hands: 42% 41%
Fingers: 7.0% 8.0% 16% 12% 0.00% 18% 12% 11% 9.0% 7.0%

    `  %  /  +  #   ^  <  >  {  }  Q
 |  \  P  O  U  [   ]  D  L  C  W  @
    I  N  E  A  *   M  H  T  S  R  X
    &  K  =  Y  !   B  F  V  G  $  
    ~ \t                     J  Z  
                               \n SP

    1  2  3  4  5   6  7  8  9  0  q
 ;  .  p  o  u  -   "  d  l  c  w  :
    i  n  e  a  ,   m  h  t  s  r  x
    (  k  '  y  _   b  f  v  g  )  
    ? \t                     j  z  
                               \n SP

Fitness: 51887480
Distance: 77500
Finger work: 67705
Inward rolls: 6.56%
Outward rolls: 1.54%
Same hand: 42.23%
Same finger: 1.51%
Row change: 27.27%
Home jump: 6.18%
Ring jump: 1.76%
To center: 3.42%
To outside: 0.40%

I have some speculation as to why it always places space and enter on the thumb keys. The space key, for one, is the most frequent key, and frequently occurs before and after almost every other character. It is very hard to place it on the same finger as any other character, especially a common character. The only key that doesn’t have a frequent character on it is the thumb.

Similarly, newlines occur before and after almost every character, so it hurts to put it on a key with a number of other characters. This move is less obvious—sometimes the program places something other than enter on this position, but it usually ends up relenting and putting enter in its spot. It just makes sense to put enter here—it doesn’t conflict with other characters, and to put a cherry on top, it’s about the right frequency for a spot that’s about that difficult to reach.

As for those who want to put E on a thumb key, that probably won’t work until the left thumb keys work. Until then, how might one modify this keyboard to put E on a thumb key?

(Note: As of this writing, GitHub hasn’t registered that I’ve uploaded the new files. If you don’t see the updated version of the program, let me know and I’ll see what I can do.)

Introducing the First Fully-Optimized Shifted Layout

February 19, 2012 21 comments

The typing program now fully supports shifted keys. The updated version is on GitHub.

Optimized shifted layout for Kinesis:

Hands: 51% 48%
Fingers: 9% 9% 18% 14% 14% 14% 11% 8%

 [  ]  +  {  #   @  |  $  }  %  Q
 Y  P  O  U  :   B  D  L  C  K  J
 I  N  E  A  ;   M  H  T  S  R  V
 &  ?  *  =  <   >  F  W  G  X  
 ~  `               Z  ^  

 1  2  3  4  5   6  7  8  9  0  q
 y  p  o  u  -   b  d  l  c  k  j
 i  n  e  a  ,   m  h  t  s  r  v
 (  "  '  .  _   )  f  w  g  x  
 \  !               z  /

Fitness: 18449175
Distance: 89177
Finger work: 326100
Inward rolls: 10.08%
Outward rolls: 2.53%
Same hand: 34.47%
Same finger: 1.69%
Row change: 12.64%
Home jump: 0.89%
Ring jump: 2.89%
To center: 2.47%
To outside: 0.19%

Shifted layout for a standard (asymmetric) keyboard:

Hands: 50% 49%
Fingers: 8% 9% 19% 14% 17% 11% 12% 8%

^  @  (  )  +  &   ~  [  ]  %  #  Q  Z   
   <  P  O  U  *   V  F  L  G  >  $  J  `
   I  N  E  A  =   D  S  H  T  R  X     
   {  }  ?  Y  |   B  C  M  W  K       

\  1  2  3  4  5   6  7  8  9  0  q  z   
   .  p  o  u  _   v  f  l  g  "  ;  j  /
   i  n  e  a  ,   d  s  h  t  r  x     
   !  -  '  y  :   b  c  m  w  k

Fitness: 18019920
Distance: 27161
Finger work: 87915
Inward rolls: 8.63%
Outward rolls: 2.77%
Same hand: 34.45%
Same finger: 1.93%
Row change: 13.34%
Home jump: 1.35%
Ring jump: 2.02%
To center: 2.63%
To outside: 0.43%

Compare this to Colemak for a standard keyboard:

Hands: 46% 53%
Fingers: 8% 7% 11% 18% 18% 15% 10% 9%

~  !  @  #  $  %   ^  &  *  (  )  _  +   
   Q  W  F  P  G   J  L  U  Y  :  {  }  |
   A  R  S  T  D   H  N  E  I  O  "     
   Z  X  C  V  B   K  M  <  >  ?       

`  1  2  3  4  5   6  7  8  9  0  -  =   
   q  w  f  p  g   j  l  u  y  ;  [  ]  \
   a  r  s  t  d   h  n  e  i  o  '     
   z  x  c  v  b   k  m  ,  .  /

Fitness: 22955565
Distance: 25239
Finger work: 347475
Inward rolls: 4.51%
Outward rolls: 2.50%
Same hand: 42.63%
Same finger: 1.89%
Row change: 18.63%
Home jump: 1.33%
Ring jump: 3.86%
To center: 7.71%
To outside: 1.18%

Typing Program on GitHub!

February 15, 2012 37 comments

I uploaded the typing program to GitHub. I will no longer be updating the version at

From now on, the latest version of the typing program will be available at:

Stanford Free Classes

January 10, 2012 Leave a comment

I recently read an article by a Stanford student, Ben Rudolph, in a Machine Learning class that uses a “flipped classroom” model: the students watch lectures at home and then go into class to talk to the professor about the homework. This is an interesting model that’s been gaining some attention lately, and I have some experience with it. I mostly agree with what the article says, and I have a few additional points.

Rudolph complains that the online questions are too easy. As reported in another article,

Mr. Rudolph took particular exception to the programming exercises, in which the computer automatically informed students whether or not they got 100 percent on the task. “It’s so black and white,” he tells Wired Campus. “They have to make it easy enough so everyone can get 100 percent, basically. In the past I’ve turned in programming assignments, and only the really smart kids got stellar scores, because they went above and beyond. This model kind of discourages that.”

Those are some poorly constructed programming assignments. A computer can still grade a difficult programming assignment, because a computer program can—by definition—run on a computer, and the computer can check if it gives the correct output. For example, TopCoder offers a series of programming challenges that could take anywhere from five minutes to a few hours, and all of them are graded by computer. The computer grades not only on accuracy, but also on speed, memory efficiency, and code concision.

The main problem with this is that if you’re stuck, there’s not much you can do by yourself to figure out the next step. I suggest that students work on sophisticated problems like those at TopCoder, and the students who are struggling can talk to a professor about how to get the program a little closer to where it needs to be.

Kinesis Contoured Keyboard

December 25, 2011 38 comments

I finally purchased the Kinesis Contoured Keyboard, and I thought it prudent to write a brief review.

When I got this keyboard, I immediately noticed how little my fingers have to travel. The bowl shape makes it easy to reach keys that are relatively far away—so easy, in fact, that I kept accidentally hitting the number row instead of the top row. The fact that the rows are symmetric is a serious advantage, because it makes the B and Y keys (QWERTY positions) far easier to reach.

The thumb pads prove themselves to be very useful. I remapped the thumb pads to put space and enter on the right thumb, and shift and backspace on the left thumb. This greatly reduces the workload on my right pinky, because it doesn’t have to keep stretching to hit backspace. But there are two issues with the thumb pads. First, they are placed too high up, so my thumbs have to sit above the rest of my hand. Second, I have trouble reaching the smaller keys on the outer edges of the thumb pads—ctrl, alt, and command (on a Mac). I would prefer if the pads were shifted outward more so that the thumb could rest in the center of the thumb pad, instead of on the edge, and then reach all the keys more easily.

It has taken me some time to adjust to the keyboard. When I first got it, my speed was only at about two-thirds of my speed on a standard keyboard, and I am improving by about 5 wpm per day. I have kept practicing on a standard keyboard, and my speed there has not decreased at all.

Now that I have some experience with a Kinesis, I plan on modifying my keyboard layout optimizer for contoured keyboards.

Categories: Keyboards

Typing Data: Preliminary Analysis

November 27, 2011 9 comments

I have collected a large quantity typing data using Amphetype, on both QWERTY and MTGAP 2.0 (the two layouts that I currently know). I do not have any conclusive results, but I have some interesting data that I thought worth sharing.

My most interesting discovery is that there is a statistically significant correlation between frequency of a trigram and the average speed at which it is typed. On MTGAP 2.0 the correlation is 0.34 and on QWERTY it is 0.33. This means that a trigram’s frequency accounts for about 10% of the variation in typing speed—not a lot, but still enough to merit consideration.

Then I analyzed the speeds of various key combinations. For example, on MTGAP 2.0, the average speed for a trigram containing an inward roll is 121 words per minute (wpm); for a trigram containing an outward roll, the average is 110 wpm, and for a trigram containing neither, it is 111 wpm.

When all three keys are typed with one hand, the average is 104 wpm; when two are typed with one hand and one with the other, the average is 118 wpm; and where the hand alternates, 107 wpm.

Where the total finger travel distance is short, the average is 120 wpm; for medium distance, 111; and for a long distance, 105.

It would be premature to draw conclusions from these data. For example, the reason why short finger travel distance is faster may be because MTGAP 2.0 intentionally places common keys on the home row, and common keys tend to be typed faster. On QWERTY, the average speeds for short, medium, and long distance are 96, 102, and 104 wpm, respectively. In this case, the short-distance keys are the slowest.

I am currently looking for anyone who uses Amphetype or is willing to contribute some time to using it. I want to get as much typing data as possible, especially on a variety of keyboard layouts. Leave a comment if you are interested.

For those who are interested, here are all the data I have acquired.


Average WPM: 112

near distance average: 120
medium distance average: 111
far distance average: 105

inward close keys average: 120
outward close keys average: 107
not close keys average: 110

in roll average: 121
out roll average: 110
not roll average: 111

same hand average: 104
two and one average: 118
alternation average: 107

triple finger average: 73
same finger average: 91
different finger average: 115

twice jump average: 73
home jump average: 92
home jump index average: 113
not jump average: 112

twice to center average: 105
to center average: 116
not to center average: 112


Average WPM: 104

near distance average: 96
medium distance average: 102
far distance average: 104

inward close keys average: 106
outward close keys average: 113
not close keys average: 102

in roll average: 104
out roll average: 116
not roll average: 102

same hand average: 98
two and one average: 106
alternation average: 105

triple finger average: 72
same finger average: 87
different finger average: 107

twice jump average: 71
home jump average: 82
home jump index average: 116
not jump average: 104

twice to center average: 100
to center average: 108
not to center average: 102

RGB Cipher

Like my first haiku,
It came to me in a dream.
I saw its colors.

(Note: This will only make sense if you know a thing or two about ciphers. For the rest of you, I’m afraid this won’t be very interesting.)

Last night I had a dream that I was trying to break a cipher. But this was no ordinary cipher: instead of using numbers, it used colors. Ciphers were suddenly even more beautiful than they had been before.

When I woke up, I was dismayed to realize that it is mathematically impossible for an encryption algorithm to use colors. Nonetheless, I was infatuated with the idea.

What would it mean to have a colorful cipher? I realized that the rounds could be colored. There are three core rounds (red, green and blue) that each represent a different operation. For instance, the red round could be a data rotation, and the green round could be a substitution-box permutation.

The encryption would move through a six-round cycle as the algorithm flows through the color wheel: red, yellow, green, cyan, blue, magenta. Each secondary color represents the combination of two primary colors: yellow is a red round plus a green round, cyan is a green round plus a blue round, and similarly for magenta. Then there are the black and white rounds. The black round is no operation (maybe just adding the key to the text) and the white round is all operations. These eight colors could be arranged to paint a picture—the world’s first cryptographically-secure picture.

How exactly these colors would be arranged to create a secure algorithm, I do not know. All I know is that this is what I saw in my dream, and it was beautiful.

Categories: Cryptography, Math

Get every new post delivered to your Inbox.