Philosophical Multicore

Sometimes controversial, sometimes fallacious, sometimes thought-provoking, and always fun.

New Keyboard Layout Project: Overview

Posted by Michael Dickens on August 19, 2009

New Keyboard Layout Project: Efficient Genetic Algorithm Optimization

For p = 48, b = 16, k = 1, o = 1024, q = 2048, the program got the best layout possible in just over fifteen minutes. Considering that to find the best layout by brute force would take a billion times longer than the universe has existed for, that’s a pretty impressive feat.

Even more impressive is q = 64. You might say, “Why in the heck was q so large in the first place?” My rationale was this: it’s the final round. You want to get the best possible layout. And even in the worst-case scenario, if q = 2048 the keyboard has a 99% chance of improvement. But it looks like that was excessive, because q = 64 has about a 50% chance of getting the best possible layout, and in only about ten minutes. (I ran it twice: one time it got the best layout, and the other time it got a layout that is very very close to the best, but not quite.) That all-star round with 1024 layouts and 2048 iterations was gobbling up a lot of time.

I am currently using this cost distribution. See my keyboarding page for an explanation of what these mean.

Inward roll:  -14
Outward roll:  -4
Same hand:      2
Same finger on...
    pinky:    100
    ring:      90
    middle:    70
    index:     55
Row change:    10
Home row jump: 40
	index: -30
To center:     10

Also, each position on the keyboard has a cost based on its difficulty to reach. These costs are not just based on my own assessment, but also on the placement of keys on some of the better keyboards out there.

 70 40 30 30 60   80 30 30 40 70
 10  4  0  0 30   30  0  0  4 10
 90 85 60 50 95   70 40 60 80 90

Normally the ring finger and pinky would cost 0 since no movement is required, but I wanted to keep E and T off of the pinky and E off of the ring finger. Those letters are far more common than any other, and it would put too much stress on those fingers.

And the best possible layout under this scoring system is:

k c f p b  j h u w .
o s a t d  l n e r i
q v , g z  ; m y x '

By the way, this layout is officially called MTGAP 3.2. You don’t have to worry about the version-numbering system; it’s a little erratic.

Is this really the best possible layout, or is the scoring system flawed? Let’s look at some of the problems with this layout.

-The fa/af digraph is fairly common. I assume that the program made it because the middle finger can handle same finger usage rather well (at least according to the scoring system). Also, if you’ve ever tried, it is exceptionally hard to find stuff to put on the same finger as ‘a’. It is usually placed on the pinky and then put with either a really rare letter like q or j, or with punctuation. But the algorithm thought it better to put a on the middle finger. Why?

To find out, I worked with rearranging some parts of the layout.

-You can’t switch i and a. i can only be paired with u, y, and punctuation. The spot above the middle finger is too good for y, so that won’t work. e is already using u and there isn’t really anything else for e to go with, so u is out. That just leaves punctuation. But the spot above the middle finger is still too good for punctuation. What does that leave? Pretty much nothing. f, though, is common enough that it can be placed in that spot. (By the way, if all this talk about letter frequency is confusing you, check out this graph.

-You can’t switch a and s. You end up with the exact same problem as you had initially: what do you put over the a?

-You can’t switch o and a. o has the same problem as a and i, only worse. Remember when I said that a is exceptionally hard to pair with other letters? Well, o and i have it even worse, and e has it worst of all.

So how have other layouts coped with this problem? By making sacrifices.

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 , . /

Colemak copes with the problem by sacrificing some finger travel distance. Colemak has the lowest same finger usage of any layout I’ve seen, but it can only do this by making sacrifices. c is placed in a hard-to-reach position, for one.

Colemak actually copes remarkably well. Capewell and Arensito do not cope very well at all. They end up placing punctuation and rare letters where they shouldn’t be. Dvorak is even worse. So it looks like having the fa/af combination on the same finger is the best choice after all.

I will look for more potential problems later. Right now I’ve got some other fish to fry. As always, I welcome comments and feedback.

8 Responses to “New Keyboard Layout Project: Overview”

  1. phynnboi said

    I don’t see how Dvorak is “even worse.”

    • It puts period in one of the better spots on the board (IMO the 12th best) and comma on a spot that’s really too good for it. J and K are in spots that aren’t great, but even so, J and K are both very rare so it’s still overstated. Also, R and L are pushed over into the corner and they really deserve better.

      • phynnboi said

        The thing is, Colemak, which you praised, also puts two pieces of punctuation on one of the pinkies, and those two are even rarer than the comma and period! That’s why I don’t see how Dvorak is any worse in that regard. I agree that Dvorak’s L is poorly placed (as is its I).

        Anyway, I think you’re weighting far too heavily against same-finger. Low same-finger can be an important consideration, but there are other things that are equally important. Heck, I don’t even find same-finger occurrences all that bad as long as they end on the home row. For instance, in the layout I tried where I just swapped most of the top and home rows of Qwerty*, having ED end on the top row annoyed the heck out of me. Qwerty’s ED, however, which ends on the home row, isn’t too bad at all.

        A while back I read a quote from Shai talking about same-finger. He basically claimed that the reason he put so much emphasis on a low same-finger ratio was, he felt that people who were comparing layouts would just look at the numbers and if they saw some flaw in the numbers (like that Colemak had a higher same-finger ratio than Dvorak, say), they’d immediately dismiss the layout. I can’t seem to find the quote, anymore, though; it may have come from his comments in the contest he designed Colemak for; I’m not sure. Anyway, while understandable and probably true, that still seems like a pretty weak reason to make a bunch of design sacrifices. (That’s not the only reason he did it, of course, but I definitely got the feeling it was the main reason he took it as far as he did.)

        * Fun fact: Shai himself did something very similar before moving on to develop Asetion and ultimately Colemak. We even both thought to call our layouts Aserth.

      • I find that same finger poses a few problems. It is uncomfortable if it happens too much. And it may be hard to notice because of how fast we type these days, but it takes several times longer to type two keys with the same finger than with two different fingers.

        I was just looking at the Colemak forum and I happened upon this thread: http://forum.colemak.com/viewtopic.php?id=727 This person has trouble with the few relatively common same finger digraphs on Colemak. And by my count, Colemak has the lowest same finger of any of the relatively well-known keyboards.

        Michael Capewell and Hakon Hallingstad (the Arensito guy) both agree that same finger usage is bad.

  2. feurry said

    Nice work. I’m currently using you’re layout 2.0 but I am still looking for something suited more to my preferences. I am really excited about the latest work you have been doing. Version 3.2 looks really good.

    I was wondering if I could download your program to try and use my own preferences, or if you could try some different settings. In short I like hand alternation, inward rolls and the bottom row easier then the top row. Specifically i was thinking of using version 3.2 but switching h/m and p/g. Does that change really mess up the layout? Maybe i could just switch the whole top and bottom rows.

    I also don’t see anything about hand alternation in your cost dristribution. Is the program specifically written for hand rolls instead of alternation.

    Keep up the good work!

    • I’m honored. I didn’t realize that anyone was actually using my layout. (Do I know you, or did you just find this site?)

      I have same hand at 2 points. I keep the cost low because I prefer hand rolls. I am still tweaking the program, but I will make it publicly available after it’s a complete package. Unless you want my current version, which is fine.

      I can’t remember the effects of switching p and g, but I have them written down somewhere. I’ll tell you when I find them. And you can switch h and m and I don’t think it would have much of a negative effect. I was thinking of switching h and l since I find the current “he” digraph to be uncomfortable, but the program doesn’t pick it up and I don’t want to write in such a minor point.

    • k c f p b j h u w .
      o s a t d l n e r i
      q v , g z ; m y x ‘

      Fitness: 23041
      Distance: 20876
      Inward rolls: -1855
      Outward rolls: -373
      Same hand: 788
      Same finger: 1057
      Row change: 1747
      Home jump: 242
      To center: 558

      k c f g b j h u w .
      o s a t d l n e r i
      q v , p z ; m y x ‘

      Fitness: 23044
      Distance: 20868
      Inward rolls: -1855
      Outward rolls: -373
      Same hand: 788
      Same finger: 1057
      Row change: 1749
      Home jump: 251
      To center: 558

      When p and g are switched, distance is marginally better (though not enough to matter), row changing is worse, and home row jumping is worse. If I were to guess, I would say that this is mostly due to the “g,” digraph.

      • feurry said

        Wow!! In the time I read your post and got ready to reply you’ve already added another!

        I didn’t realize the implications of the same hand setting of 2 and hand alternation. I guess you’d just crank that number up to optimize for hand alternation.

        It’s funny that you mentioned the “HE” digraph, because that is exactly what I was thinking. I find the top row for the index finger to be much more uncomfortable, i.e. difficult than the bottom row. Since you were thinking of moving it too.. maybe the cost distribution system could reflect that instead of re-writing the program.

        Looking at the g and p data above; it doesn’t seem like a major problem. I don’t really like the idea of switching l and h… the “ME” combo in 3.2 would be really nice for the often used he.

        I thought about my preference for the bottom row… and I think that it’s really a preference for the index finger on the bottom row. It seems to suit the natural curvature of the hand better.

        I’m going to stick with 2.0 for now, because I can’t be bothered to switch again. I’ll hold out for the layout of my dreams.

        I would love to help any way I can… and i’m pretty sure we have not met. I came upon your layout after being unhappy with dvorak (several years use) and colemak (one year). I started reading about all these different layouts, and for some reason yours wasn’t really recognized among the community (didn’t appear to have the same status as others) but I still found it. I tested a whole bunch of layouts a few hours here and there, and ended up coming back to mtgap 2.0 every time.

        I hate the idea of sacrificing a layout in order to make it “easy” to learn or to keep zxcv in the same positions… so what you are doing really appeals to me. Plus you seem to be good at it. After all i’m using mtgap 2.0 and 3.2 looks promising.

        I’d love to chat more but I don’t really want to hog all this comment space with my hot air.

        p.s. thanks for posting those results.

Leave a comment