Home > Keyboards, Software Release > Introducing the Thumb Keys

Introducing the Thumb Keys

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?

https://github.com/MTGandP/Typing

(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.)

Advertisements
  1. phynnboi
    February 27, 2012 at 9:23 am

    Curious if you’ve been using “my” algorithm at all in this. I noticed it’s still in your source code, at least.

    Did you ever try out the WalkSAT-like algorithm I mentioned on Facebook? If not, here’s a sketch. You need two mutation operations. One is greedy–it tries all swaps and commits to the best one (even if it’s worse than making no swap at all–this is very important!). The other mutation operation is random–it does any random swap. Each iteration, with probability p you do the random mutation, and with probability 1-p you do the greedy mutation.

    The value for p is, unfortunately, something you have to find by trial and error. I believe its best value depends on how “deceptive” your fitness function is. The fitness function for my layout optimizer is not very deceptive, so I needed a small p, something like 0 < p < 0.05, IIRC. (Higher p actually failed to converge.) If your fitness function is more deceptive, you might need higher p values. (SAT tends to need a p value in the 0.5 range, but, of course, is a very demanding problem.)

    Oh, and the WalkSAT-style approach should be able to converge in a single run, unlike my original approach. Obviously, we don't know the optimal fitness value, so you'll have to set some arbitrary upper limit on the number of iterations (the "right way"), or just have it print every new best layout and CTRL-C when it hasn't done anything for a while and you get bored (the way I actually did it).

    Would be interested in what you turn up if you try it. I have far more faith in the WalkSAT-style algorithm than the one I came up with since the WalkSAT-style one is actually able to solve some tough SAT problems, unlike mine, which couldn't even solve trivial ones.

    • February 27, 2012 at 2:12 pm

      I still use the algorithm you wrote.

      WalkSAT looks promising. I’ll write some code for it when I get an opportunity. Thanks for the idea.

  2. shrugalic
    February 27, 2012 at 8:22 pm

    Interesting result. But some introduction first. I have used a Kinesis Advantage keyboard with Colemak layout for about 4 years. Recently I gave the TrulyErgonomic keyboard a 2 week trial and liked it, but missed the extra thumb keys I’m used to from the Advantage. OK, back to your post. 🙂

    What happened to the top left key (+= by default), is it unmapped?

    Not sure how I feel about Tab position, ATM it feels worse than the original particularly when using it together with the Command (or Alt) thumb key. Having used a TrulyErgonomic for two weeks, which has the Tab in an extra center column between the left and right area, I found that I liked that position quite a bit.

    Personally I’d put the CapsLock key up for remapping as well, what are your thoughts on that? I’m currently wasting that precious spot on `, see my layout here: http://homepage.mac.com/boli/ars/80329_kinesis_colemak_small.png

    Same goes for the Shifts if you’re using the left thumb for it, those keys are fairly easy to reach. Thumb is probably the best solution for Shift, though I’m not using it so as to retain some interoperability with normal keyboards. The TrulyErgonomic approach of putting Shift on the same row as the home keys also has some appeal, for regular keyboards, though I didn’t even try to get used to it.

    What layout are you currently using? Still MTGAP 2.0, or has something changed since you got the Advantage?

    Have you ever done a comparison to the carPalx layouts (popular alternatives and fully optimized in particular) using the carPalx tool?

    Are you a geekhacker? You might feel quite at home at http://geekhack.org/forumdisplay.php?69-alternative-layouts and http://geekhack.org/forumdisplay.php?68-ergonomic-designs 🙂

  3. phynnboi
    February 28, 2012 at 7:33 am

    Oh, my cloudy memory. I had the chance to play around with my layout optimizer tonight. Looks like the WalkSAT approach tends to take about 10x longer than my original approach (i.e., 10x more evaluations).

    I guess whether the WalkSAT approach is worth trying for you depends on how cjalgorithm tends to act with your fitness function. The WalkSAT approach may help if you’ve been finding that cjalgorithm, if left to run for a long time, keeps finding better and better layouts spaced by what seems to be exponentially increasing amounts of time. Like, if it finds layout A after one second, then B after ten seconds, then C after 100 seconds, then D after 1000 seconds, etc. That’s the kind of behavior cjalgorithm showed for SAT problems, and WalkSAT worked a lot better there. If, on the other hand, you’ve experienced what I have, where cjalgorithm quickly finds a good layout and then just hits a wall and never finds anything better no matter how long you let it run, then forget WalkSAT–it’ll almost surely hit the same wall, but after a lot more time.

  4. Michael Rouse
    February 28, 2012 at 6:28 pm

    This might not be useful on the Kinesis, but have your tried running your algorithm on the number pad? I’m kind of curious if telephone ordering (1 at the top left) is better than calculator/computer order (1 at bottom left), or if there is a better one than both.

    Also, it would be interesting to see how it orders the numbers on the main keyboard. Odd numbers on the left and evens on the right? Zero and 1 in the center, with 8 and 9 within reach of the pinky? I think it would be an interesting experiment.

    • bogboar
      February 28, 2012 at 7:38 pm

      I have actually heard of studies done on this. There is no noticeable difference between 123 being at the top or at the bottom.

      We just happened to get the two different standards in different applications, but that’s not a too terrible thing since it isn’t actually very hard to switch between them

      Would you learn a different numpad layout if it was more efficient? I imagine 012 would be in the middle, maybe not quite in that order. But is it worth it? I don’t write numbers all that much, at least.

      • February 28, 2012 at 7:40 pm

        I wouldn’t learn a new thumbpad. I never use it in the first place. I just use the number row on top. Usually, when I type numbers, I only type a few at a time, and it’s in the middle of typing a bunch of letters.

      • Michael Rouse
        February 28, 2012 at 8:22 pm

        I don’t know if I would bother learning a completely new format, though if they replaced all the computer number pads with telephone number pads (or vice versa), I would easily adapt.

        I do think it might be a useful (albeit imperfect) test for the optimizing algorithm, though. If it generated a result that seemed logical, you might be more confident about the entire keyboard layout. If it produced odd results, then you could tweak things a bit until it seemed right.

        I will say that I like the look of the MTGAP non-Kinesis layout (I don’t have a Kinesis to play with, unfortunately). It of course did especially well when compared to QWERTY, but I thought it was a lot more natural even when compared to Dvorak. I mentally went through a few common words just to see how I would do it on the keyboard, and was really impressed by the balanced feel.

        I might however swap places for the hyphen (-) and underscore (_). I use hyphens more often, but I think underscore is in a better position. Though maybe other criteria (overworked left forefinger?) moved the hyphen to the ring finger.

    • February 28, 2012 at 8:18 pm

      Regarding the number pad, I don’t know which order is better because I don’t know whether it’s easier to type keys at the top or the bottom. Any thoughts on that?

      Reordering the number keys is easy. Just start up the program and type “set keepNumbers 0” or “set keepNumbers 2” (two different modes; I think the one you want is 2). I ran that with the full standard keyboard and got this result:

      Hands: 50% 32% Fingers: 9.0% 9.0% 19% 14% 0.00% 0.00% 18% 14% 10% 8.0%

         ^ &  %  \  {  #   ~  }  /  @  [  ]  Z      $  P  O  U  *   |  M  D  F  G  X  Q  `      I  N  E  A  =   R  H  T  S  C  W   ?  Y  +   K  L  B  V  J 
      
        :  9  3  2  8  7   6  5  0  1  4  "  z      .  p  o  u  (   )  m  d  f  g  x  q  !      i  n  e  a  ,   r  h  t  s  c  w      ;  -  '  y  _   k  l  b  v  j 

      Fitness: 17785535 Distance: 29327 Finger work: 123435 Inward rolls: 9.54% Outward rolls: 2.46% Same hand: 34.41% Same finger: 1.84% Row change: 11.96% Home jump: 1.42% Ring jump: 2.30% To center: 4.33% To outside: 1.12%

  5. boli
    February 28, 2012 at 9:44 pm

    You wrote “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?”

    Looking forward to that. 🙂

    Someone at geekhack used the MTGAP layout on a keyboard idea, which I liked because it’s matrix layout.
    Pictures and discussion here:
    http://geekhack.org/showthread.php?27906-Ergonomic-keyboard-the-size-of-an-aircraft-carrier-First-Draft&p=529670&viewfull=1#post529670

    Having recently taken a few looks at the Maltron site (the Malt layout in particular) I noticed a few similarities between MTGAP and Malt in the center off-home columns: V, D and B. Home row keys are mostly the same, though Malt has E on a thumb, and fills the extra space in the home row with F.

    Anyway, as I wrote in the linked thread, this had me wondering how Colemak (or other layouts) can be extended to make good use of an extra left thumb key, without changing too many other things (just a few swaps maybe).

  6. phynnboi
    February 29, 2012 at 9:14 am

    For me, the whether the top or bottom row of the keypad is better depends on the finger. It’s easier for me to reach down with the index finger and up with the middle and ring fingers. So, an order of preference would probably go something like 456 189 723.

    I noticed the same thing with normal keying: It’s easier (for me, at least) to reach down with the index and pinky fingers, and up with the middle and ring fingers. This defies the standard claim that the top row is always better than the bottom row, and is something I incorporated into my fitness function. I found the layouts that resulted after adding this feature felt “smoother” and more “open” than layouts that always favor the top row over the bottom row.

    • Michael Rouse
      February 29, 2012 at 3:45 pm

      That is an interesting observation. If you hold your hand flat over the home keys of a keyboard (other than one with an arc, like Kinesis or Maltron), the index and pinky would be relatively closer to the bottom row, while the middle is closer to the top. In fact, for me the pinky is on the bottom row to start with, at least in this position. It’s also a bit easier for me to type “down” (from a higher key to a lower key — from u to j on a standard QWERTY) than “up” (from j to u), partly because it’s easier to slide down to the lower key than pick up my finger and hit the higher key.

      I’m not sure how hard it is to incorporate things like that into a fitness function, though.

      • phynnboi
        March 1, 2012 at 10:12 am

        To incorporate it into my fitness function, I first ranked each key from most preferred to least preferred. Then, I made a parameter that tries to maximize the usage of the most preferred keys (by putting the most frequently used characters there). The order of key preference, from most preferred to least preferred, by their qwerty labels, is as follows:

        JFKDLS;AHGIEOWMV/ZNURPQ.X,CTYB

        It’s one of ten parameters my optimizer tries to balance out. (The preference order would probably be different for Kinesis; the one I use is based on standard staggered-row keyboards.)

        Along the same lines, I have a parameter that tries to minimize the frequency of “bad finger sequences,” which are uncomfortable or awkward pairs of characters like qwerty’s QX, WC, and so on. Try putting your pinky on A, ring finger on W, middle finger on C, and index finger on F to see what I mean! Sequences like that basically force the typist off the home row to type them with any comfort.

  7. March 1, 2012 at 7:30 pm

    Does the shifted optimizer work with the standard keyboard? What is the result on the standard keyboard (obviously minus the thumb keys)?

    • March 1, 2012 at 7:47 pm

      I didn’t like the keyboards I was getting, so I tweaked the values a bit. (I think I was penalizing pinky use too heavily.) If you download the program right now and use it, you’ll get something different, but here’s what I got:

      Hands: 51% 49%
      Fingers: 9.0% 9.0% 19% 14% 0.00% 0.00% 15% 14% 11% 9.0%

       |    \  [  #   ~  ]  {  }  %  ^  Z    
          Y  P  O  U  *   +  F  D  C  W  X  Q  `
          I  N  E  A  =   M  H  T  S  R  K       
          &  (  )  ?  @   V  L  B  G  J          
      
       :  1  2  3  4  5   6  7  8  9  0  /  z    
          y  p  o  u  -   "  f  d  c  w  x  q  $
          i  n  e  a  ,   m  h  t  s  r  k       
          !  ;  '  .  _   v  l  b  g  j     
      

      Fitness: 17443453
      Distance: 30218
      Finger work: 47593
      Inward rolls: 9.91%
      Outward rolls: 2.41%
      Same hand: 34.53%
      Same finger: 1.52%
      Row change: 13.04%
      Home jump: 1.25%
      Ring jump: 3.21%
      To center: 2.05%
      To outside: 0.79%

      (Edit: There was a bug in how the program was calculating hand usage.)

      • Michael Rouse
        March 1, 2012 at 8:08 pm

        I notice that square brackets are split. Is there a way to combining matching characters into a single unit, kind of like a key that takes up two spaces?

        Come to think of it, double-wide characters (or whatever you want to call them) might also be useful for things like shift, enter, backspace, and tab. The TypeMatrix 2020 and 2030 put some of these keys toward the center of the keyboard rather than the periphery, and you could let them float (assuming you had good statistics on them).

      • March 1, 2012 at 8:43 pm

        I recently began using ubuntu, and I can’t get the algorithm to work on it, which is why I asked.

  8. March 1, 2012 at 7:38 pm

    Also, how’s the progress on the trigraph implementation?

    • March 1, 2012 at 7:42 pm

      Nowhere close to finished. I want to do some research on what things are fast to type, but I don’t have a lot of data. I want to get data from different people on different keyboards, but right now I only have data from myself on QWERTY and MTGAP 2.0. I especially want to get data from random keyboards, not ones that have been specifically designed to be good, because such keyboards (like Dvorak, Colemak, Arensito) are much more similar than random keyboards.

      Until I do that research, I don’t see much point in a trigraph implementation since digraphs work well enough.

      Was there any particular reason you wanted to see a trigraph implementation?

      • March 1, 2012 at 8:45 pm

        Call me crazy but the “ion” trigraph…

        I guess I could start using Amphetype to collect some data then (using QWERTY). How would I share the data with you? With the .db file Amphetype generates?

        • phynnboi
          March 1, 2012 at 9:14 pm

          Michael should add a parameter to minimize “bad finger sequences” (see earlier in comments) to avoid such common trigraphs as “ion” ending up being so awkward to type! 🙂

        • Michael Rouse
          March 1, 2012 at 10:52 pm

          If you want some trigraphs to try your hands on, I like the information from the Google Web Trillion Word Corpus here: http://norvig.com/ngrams/

          All of the 26^3 = 17,576 3-letter trigraphs appear. Here are the top and bottom 10. Some highlights (trigraph first, followed by number of occurrences):

          Top Ten

          the 82103550112____2.763%
          ing 43727954927____1.471%
          and 43452082914____1.462%
          ion 39907843075____1.343%
          tio 32705432538____1.101%
          ent 31928292897____1.074%
          for 26276145239____0.884%
          ati 25312331919____0.852%
          ter 21635845251____0.728%
          ate 19978168727____0.672%

          Bottom Ten:
          fzq 12902____0.0000004%
          jvq 12601____0.0000004%
          jnq 12291____0.0000004%
          zqh 11278____0.0000004%
          jqx 10372____0.0000003%
          jwq 10340____0.0000003%
          jqy 8871____0.0000003%
          zqy 8474____0.0000003%
          jzq 7180____0.0000002%
          zgq 6254____0.0000002%

          The irony is that the least common trigraphs will become *more* common as people point them out. 🙂

          And maybe someone would like to make the bottom trigraphs really, really difficult to type, and see what keyboard comes of it. 😀

          • boli
            March 1, 2012 at 11:17 pm

            The bottom trigraphs do feel pretty bad on Colemak. ;D The top ones feel nice (ofc I’m also much more accustomed to them, so YMMV)

          • boli
            March 1, 2012 at 11:22 pm

            Top/Bottom trigraphs Colemak-to-QWERTYed, type these in QWERTY to “feel” Colemak:

            Top Ten:
            fhk 82103550112____2.763%
            ljt 43727954927____1.471%
            ajg 43452082914____1.462%
            l;j 39907843075____1.343%
            fl; 32705432538____1.101%
            kjf 31928292897____1.074%
            e;s 26276145239____0.884%
            afl 25312331919____0.852%
            fks 21635845251____0.728%
            afk 19978168727____0.672%

            Bottom Ten:
            ezq 12902____0.0000004%
            yvq 12601____0.0000004%
            yjq 12291____0.0000004%
            zqh 11278____0.0000004%
            yqx 10372____0.0000003%
            ywq 10340____0.0000003%
            yqo 8871____0.0000003%
            zqo 8474____0.0000003%
            yzq 7180____0.0000002%
            ztq 6254____0.0000002%

          • March 2, 2012 at 3:22 pm

            I think those must be multi-lingual. On the digraphs page (http://norvig.com/ngrams/count_2l.txt), ‘in’ is more frequent than ‘th’, which I have never seen in any serious English corpus. I don’t know how they’ve weighted different languages, either, which makes it difficult to determine whether their data fit my standards.

            I’ll have to read chapter 14: norvig.com/ngrams/ch14.pdf

        • March 2, 2012 at 3:11 pm

          Yes. You can extract the .db file from Amphetype, and if you just send me the file, I can take it from there.

          If you use a keyboard besides QWERTY, it would be helpful to get some more diverse data as well. If you do switch keyboards while using Amphetype, be sure to move the first .db file to a new directory and create a new one in Amphetype’s directory. If you use the same .db file for two different keyboard layouts, Amphetype’s analysis won’t be decipherable.

        • March 2, 2012 at 3:11 pm

          The program is well aware that ‘on’ is uncomfortable, but it always seems to put o there anyway.

  9. Michael Rouse
    March 7, 2012 at 5:20 pm

    I keep checking this thread a couple of times a day, hoping that more interesting information comes my way. 🙂

    • March 9, 2012 at 11:28 pm

      You can subscribe to the comment thread and then it will email you automatically every time there is a new comment.

  10. March 10, 2012 at 6:41 pm

    Well I’ve got my hands on a mac again. Since the program has changed a little since the last time I used it, I was just wondering how to “lock” some keys in place. I have an idea, but I would just like to verify that I’m correct.

    If I want to lock some keys for the standard keyboard (for example the eight home row keys), I modify bigLegalBox[] to:

    1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 
    1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 
    1, 2, 3, 4, 5, 1, 1, 6, 7, 8, 9, 1, 1, 1, 
    1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
    

    and then I edit fulllayoutstore.txt to change the layout the program begins with? If I understand correctly fulllayoutstore.txt holds the layout that the program starts optimizing. Currently it’s Colemak, so if I were to simply leave the Colemak layout, the program would leave the arstneio keys alone (with the above bigLegalBox)?

    • March 10, 2012 at 7:38 pm

      That’s correct, if you run the program using the full standard layout (by typing “setfk standard”).

  11. March 10, 2012 at 8:08 pm

    Well, after some experimentation, I have found a layout that satisfies me. I am using the standard layout because I do not always have my kinesis with me and the keys on the corners are can be moved around with relative ease.

    ^ @ [ * + |  ~ \ ? ] % Q Z
      Y G O U $  K F D C W # J `
      I S E A ;  M H T N R X
      }  = &  V L B P {
    
    : 1 2 3 4 5  6 7 8 9 0 q z
      y g o u -  k f d c w / j !
      i s e a ,  m h t n r x
      ( " ' . _  v l b p )
    

    In my opinion this layout removes the major discomforts of ineahtsr (primarily the “on” digraph) while still remaining pretty good. What I find interesting is that if we consider only the most common letters of the alphabet (i.e. ignoring kxjqz), only four keys change place from the standard layout you gave above: “sg” and “np”.

    I’ll still keep gathering data on amphetype with qwerty, however.

    • March 10, 2012 at 9:22 pm

      That looks like a great layout! How did you come up with it? I think I might like it even better than INEAHTSR—the “on” digraph bugs me as well.

  12. March 10, 2012 at 9:45 pm

    Well I originally liked iseahtnr variants, but when ‘g’ was placed under ‘t’ I did not like the ‘ng’ digraph. Also, when ‘d’ was placed above ‘h’, ‘nd’ bothered me. So I simply locked ‘g’ and ‘d’ above ‘s’ and ‘t’ and ‘isea’ and ‘htnr’ on the home row. The algorithm did the rest. As far as I can tell, most common digraphs and trigraphs are comfortable. The first couple that become slightly uncomfortable are ‘us’ and ‘ld’, but I think that’s not so bad.

  13. March 11, 2012 at 7:07 pm

    Well, I am currently trying out the layout, and I have in fact noticed that ‘pr’ is not the most comfortable digraph. It’s not that common, but from simply glancing at the layout, I thought maybe ‘b’ and ‘p’ could be switched. I do not currently have my mac, however, so I cannot test to see what changes.

    Otherwise it’s all good. The ‘l’ on the bottom row does not bother me as much as I thought it would.

  14. March 14, 2012 at 11:31 pm

    Okay after running the optimizer again I found something I prefer. The major change is that “d” is on the qwerty “m” position instead of “l”. Qwerty’s “lm” is more comfortable than “li” in my opinion. Now the first uncomfortable digraph (imo) that appears is “mp”.

    ^ % | \  [ ] + Q Z
      Y G O U ? K F L C W X J `
      I S E A ! P H T N R $
      { } * / @ B D M V &
    
    = 1 2 3 4 5 6 7 8 9 0 q z
      y g o u - k f l c w x j :
      i s e a , p h t n r "
      ( ) ; . _ b d m v '
    

    This layout gets a fitness of 18.3m, whereas the ineahtsr layouts can get around 17.9m, and I might have seen them get 17.7m. I’m pretty sure it’s just the “in” digraph that gives it those extra points, and it’s not worth the discomfort of “on”. The isea layout above has virtually no uncomfortable common digraphs (“mp” is the first). Maybe values of rolls and row change should be tweaked a little. I’m not sure how effect small tweaks have, however, as I have not tried them very much.

    Another thing. I do not know how your program values shifted keys. From what you’ve said, I don’t think it knows about shift keys, but the way I see it, anything that is shifted on one hand requires the use of the pinky on the other. So while the program may place “=” as the above layout’s shifted “,” the finger work is actually more than if it is where I placed it above. So I find that it would be better to place all the most common keys in unshifted states, even if those positions are far, instead of placing them in good, but shifted, positions.

  15. sasuley
    April 4, 2012 at 3:09 pm

    Michael Dickens :
    Yes. You can extract the .db file from Amphetype, and if you just send me the file, I can take it from there.
    If you use a keyboard besides QWERTY, it would be helpful to get some more diverse data as well. If you do switch keyboards while using Amphetype, be sure to move the first .db file to a new directory and create a new one in Amphetype’s directory. If you use the same .db file for two different keyboard layouts, Amphetype’s analysis won’t be decipherable.

    What volume of data are you looking for in words?
    I am typing on one of your older layouts
    qz
    .pou_vflg”;j
    inea,dshtrx
    \!-‘y:bcmwk

    • April 4, 2012 at 3:13 pm

      I can use any amount of data, but more is better. If you plan on continuing to use Amphetype, it would be better for you to hold off for a while and send me your data in a few months (the best time would be June or July).

  16. sasuley
    April 4, 2012 at 3:35 pm

    Will do, my typing speed will have doubled by then thought!

  17. Sam
    April 12, 2012 at 1:25 pm

    As the program stands, is there a simple way to lock say ‘Enter’ to somewhere other than the thumb so that ‘e’ has a chance to make it down there. I think that if ‘e’ goes to the thumbs there is an excellent chance of having no really difficult trigraphs because the fingers won’t need to move away from the other vowels. I imagine something like a quartet of vowels in the QWERTY WESD positions with easy rolls through them on both sides. Or perhaps e and u or o could go together to the same thumb.

    I’m expecting to have more than 2 easily reachable thumb keys per side so I’m not too worried about whether ‘Enter’ and ‘Backspace’ will find a position,

    • April 12, 2012 at 1:36 pm

      That only makes sense to do if both thumb pads are available. Right now, the program doesn’t include the left thumb pad because there are some complications involved in adding it.

      Right now, the program doesn’t put ‘e’ on the right thumb because the e-space/space-e digraphs would make same finger way too high.

      • Sam
        April 13, 2012 at 8:27 am

        So the only hack that would work right now would be to remove spaces from the corpus or at least the e-space digraphs? I promised myself that I wouldn’t get overly caught up in keyboards again until I have my PhD more under control, so I can wait a little while for the other pad.

        It’s great that your blog has become such a melting pot for so many layout ideas. I always look forward to new content!

        • April 13, 2012 at 1:29 pm

          If you remove the e-space digraphs, that should do it.

          I’m glad you enjoy my blog, and I will continue to write about keyboard layout design.

      • bogboar
        April 21, 2012 at 7:02 pm

        If I want to predetermine keys on the thumbpad—or any other location—would you recommend to just lock the keys there (with a clone of your keepTab code), or remove those locations altogether from indicesCopy & co?

        Are your program files supposed to be encoded in ISO 8859-1 or something else? My code editor can’t detect it, so it’s likely not UTF-8. I’m worried about breaking something.

        I must say, I’m envious of all the work you’ve done on this project. You must have learned so much! With the rising complexity of the program, I bet you must be wishing you did it in something like Haskell. Am I right?

        • April 21, 2012 at 7:39 pm

          There is a series of arrays at the top of keyboard.c with names legalBox[], legalBox2[], bigLegalBox[], kinesisLegalBox[], etc. Ignore all the ones that have numbers at the end of the name. For whichever keyboard you want to use (main-30, big (standard), or Kinesis), modify the LegalBox as follows:

          Any index of a given number may be swapped only with other indices of the same number. So all the 1’s can swap with other 1’s, the 2’s can swap with other 2’s, etc. If you don’t want a key to be able to move around, change the number at that position in the array to a number that doesn’t exist anywhere else in the array. Then go to the layout store file, and make sure all the keyboards have the key you want already in the correct position (if it’s not in the correct position, it will never move there).

          I have no regrets about using C. It’s a lot faster than Haskell. Plus, I don’t know Haskell nearly well enough to be able to write a program like this, and not many people know it, so other people wouldn’t be able to use my program. The only other popular languages that are even close to fast enough are Java and Fortran, but those are no better than C. Essentially, any simpler language is either too slow or too unpopular. Besides, the complexity isn’t rising all that much: it’s only about 7000 lines of code, which isn’t much compared to most major programs. (Amazon is rumored to have 100 million lines of code.)

          • bogboar
            April 21, 2012 at 11:24 pm

            I re-downloaded your program (New commit! Neat!) and changed only kinesisLegalBox. Some of the keys persist in migrating.

            It seems as though, if I do this:

            1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
            1, 2, 3, 4, 5, 1, 1, 1, 1, 1, 1, 1,
            1, 6, 7, 8, 9, 1, 1, 1, 1, 1, 1, 1,
            1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
            1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
            1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,

            the result will be as though this were what I did:

            1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
            1, 2, 3, 4, 1, 1, 1, 1, 1, 1, 1, 1,
            1, 6, 7, 8, 1, 1, 1, 1, 1, 1, 1, 1,
            1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
            1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
            1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,

            I’ve elected to use the legalbox trick on only the thumb-keys, so in my case it doesn’t matter anymore, since that’s working admirably.

            I figured out that UTF-8 saving works, by the way. It fixed an anomaly I was having.

          • zolaryc
            April 28, 2012 at 3:16 pm

            What about writing the program in Common Lisp? Wouldn’t that be a good idea?

          • April 30, 2012 at 6:57 pm

            C is a lot faster than Common Lisp. This program uses a lot of low-level optimizations, such as searching through strings byte by byte, which are harder to do in a high-level language like Common Lisp. Plus, Lisp is not nearly as portable.

  18. bogboar
    April 22, 2012 at 11:02 pm

    I’d like to lock the numbers into shift-layer.

    KeepNumbers doesn’t seem to do its job. After I’ve moved the numbers in the layout string. The numbers move around willy-nilly.

    BTW, I’m receiving a Kinesis Advantage next week. I intend to use a MTGAP layout off the bat, although I could have to wait due to studies. Mainly, I want numbers and E out of the way and see what the program comes up with after that.

    • April 23, 2012 at 6:42 pm

      Did you move the numbers from their original QWERTY positions? If you do that, keepNumbers won’t work correctly.

      • bogboar
        April 23, 2012 at 10:17 pm

        I don’t figure there’s an easy hack to at least, say, make sure the numbers are all in the shift layer?

        Even if they’re reordered willy-nilly – I’m actually interested in trying that, but not so much when some numbers end up unshifted and others are shifted.

        • April 24, 2012 at 12:04 am

          Actually restricting where a key goes is pretty difficult, since I have to change the code in the initialization function, the file read, and the mutation function. What I can do without too much trouble is add a penalty for not putting numbers on the shifted layer. This doesn’t guarantee that they’ll go there, but it at least makes it more likely. And once I’ve written the code, you can adjust the penalty as you desire. Do you think that would work for you?

          • bogboar
            April 25, 2012 at 6:50 pm

            Yes, that sounds fabulous.

          • May 2, 2012 at 1:01 pm

            Go ahead and pull the new version from GitHub. Then run the program and type:

            > setfk standard > set keepNumbersShifted 1 > algorithm

            And it should work. I tested it out, and it appears to consistently keep numbers on the shifted keys.

  19. May 26, 2012 at 11:00 pm

    Latest iseahtnr:

    Hands: 42% 57%
    Fingers: 8.0% 8.0% 15% 11% 0.00% 18% 12% 11% 9.0% 8.0% 
    
        `  <  +  [  #   @  ]  $  >  %  
     ^  Y  C  O  U  *   B  D  L  P  M  X
     &  I  S  E  A  =   F  H  T  N  R  /
        |  {  }  ?  \   K  G  V  W  J  
        ~ \t                     Z  Q  
                                   \n SP
    
        1  2  3  4  5   6  7  8  9  0  
     :  y  c  o  u  -   b  d  l  p  m  x
     (  i  s  e  a  ,   f  h  t  n  r  )
        ;  "  '  .  _   k  g  v  w  j  
        ! \t                     z  q  
                                   \n SP
    
    Fitness:       51959340
    Distance:      78905
    Finger work:   117235
    Inward rolls:  5.98%
    Outward rolls: 1.32%
    Same hand:     39.99%
    Same finger:   1.40%
    Row change:    26.00%
    Home jump:     5.69%
    Ring jump:     1.95%
    To center:     4.03%
    To outside:    0.54%
    

    I added the extra key on the left side because that makes the keyboard more symmetric. Besides, with shift on the left thumb, caps lock is obsolete.

  20. July 21, 2012 at 11:57 am

    I was thinking about whether adding a key for th and such digraphs would make a better layout. The most common digraph would then be (th)e. Then t and h become less common so they may not be where they normally are and some rarer key would have to move to a more difficult key.
    I think it would be interesting to consider calculations based on this.
    I actually lost most of my typing data from Amphetype but I still have a smaller backup of the file. Do you still want that?

    • July 21, 2012 at 4:50 pm

      I don’t think it’s very efficient to have a key for th. The th digraph may be the most common, but it still occurs less frequently than most letters. It doesn’t really make mathematical sense to put th on its own key. Perhaps it may make sense to put trigraphs or words on a special layout that’s accessed with a modifier key.

      If you plan to use Amphetype more, wait a while before you send it to me. I want to get as much data as possible. If you don’t think you’ll use it much, go ahead and send me your data now.

  21. July 22, 2012 at 5:01 am

    I will use it more.

    Based on the data from http://www.math.cornell.edu/~mec/2003-2004/cryptography/subs/hints.html , th occurs more times than u, c, m, f, y, w, g, p, b, v, k, x and z. It almost beats out h once you removed the ‘h’s from the th counts.

  22. anonymous
    November 17, 2012 at 5:41 am

    https://github.com/MTGandP/Typing says:
    “You can also use it to evaluate the entire keyboard by changig it at runtime or by changing this line near the beginning of initValues() in values.c:
    fullKeyboard = ;
    To use the main 30 keys write FK_NO, for the full keyboard use FK_STANDARD, and for a full Kinesis keyboard use FK_KINESIS.”
    But it doesn’t actually appear to be possible to set this variable at runtime. Also I tried setting fullKeyboard=FK_KINESIS in initValues in values.c and recompiling, but then when I run the program, the generated layout appears to be corrupted. I’m using version e8b767b54d.

  23. martinedstrom1
    April 5, 2013 at 10:48 pm

    Hello Michael Dickens,

    This recent commit broke your program for me – I can’t run ‘make’ to compile it:
    https://github.com/MTGandP/Typing/commit/f55d89120188694d12493c14d31b0d3f04fc0ab8 “Removed some unnecessary files”

    I get this error. I’m running OS X and installed no gcc, but XCode with Command Line Tools, which lets me ‘make’ your prior commits all the same.

    gcc -std=c99 -Wno-unused-result -O3 -c -o accessories.o accessories.c
    cc1: error: unrecognized command line option “-Wno-unused-result”
    make: *** [accessories.o] Error 1

    • April 6, 2013 at 12:00 am

      Hi,

      It’s weird that you’re getting that error. I don’t know how much C you know, but I’ll try to explain what’s going on. Basically, when the makefile runs the compiler, it tells it what warnings to print. The “-Wno-unused-result” flag tells it not to print the “unused-result” warning. I have no idea why this doesn’t work for you. You can fix it by opening the Makefile and removing the part that says “-Wno-unused-result”.

      Michael

      • Martin Edström
        April 6, 2013 at 1:36 pm

        Alright. I suspect it has to do with my previous installation and removal of gcc. The program compiles now, but (actually in the older versions too) algorithm runs out of steam immediately with a “Floating point exception: 8”.

        I’ll take the opportunity to reinstall OS X for a clean system. Get back to you on how it works out.

        By the way, do you think it’ll be time to post a new “prime layout” on the blog soon? Maybe with a variant that puts E on a thumb? I’m about ready to take such a layout and start using it. It’d be the first direct competitor to the Maltron layout ever published, and it’s high time that one got a challenger.

        • April 6, 2013 at 3:09 pm

          Right now I’m focusing more on improving the program itself rather than finding a new layout, but it may be a good idea to come out with a new thumbs-based layout soon. The one I posted here (https://mathematicalmulticore.wordpress.com/2012/02/27/introducing-the-thumb-keys/) is very good, and if I release a new one, it won’t be much different from this

          Right now the program is putting weird keys on the thumbs. Maybe it knows what it’s doing, but I want to investigate a bit.

  24. Michael Rouse
    February 2, 2014 at 10:48 pm

    I’m just curious if there have been any updates. I’m getting an 18×8 matrix keyboard (Cherry G86-63400 POS keyboard) in a few days, and it would be fun to try out the latest version. Thanks!

    • February 2, 2014 at 10:51 pm

      Thanks for asking! There haven’t been any major updates lately; I’ve mostly settled on the current version. I have some plans for the future but nothing in the short term.

      • February 3, 2014 at 7:55 pm

        Thanks! I will try out the current version, and keep an eye out for any modifications. 🙂

  25. Michael Rouse
    February 22, 2014 at 8:40 pm

    I am not sure if you are interested, but on my very first attempt with the Kinesis format, I got a result that didn’t have space and enter on the thumb keys. Instead, it put P and N there. Space is under the left index finger, and enter is below that. It is very curious!

    I have ran it for over 4 hours now, and keep expecting it to say “Hey, wait a second…” and flip it to space-enter. I just might have to experiment with a P/N left thumb instead of an E. 🙂

    snarfangel :
    Chance to use previous layout is now 0.717940.
    Number of swaps between rounds is now 19.

    ***Found from greatToBest()***

    Hands: 52% 47%
    Fingers: 8.0% 8.0% 15% 21% 0.00% 7.0% 13% 11% 9.0% 7.0%

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

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

    Fitness: 51957952
    Distance: 15601505
    Finger work: 317642
    Inward rolls: 7.36%
    Outward rolls: 1.09%
    Same hand: 32.73%
    Same finger: 1.55%
    Row change: 15.61%
    Home jump: 2.24%
    Ring jump: 1.50%
    To center: 1.82%
    To outside: 0.45%

    Time elapsed: 3 hours, 17 minutes, 3 seconds

    • Michael Rouse
      February 22, 2014 at 8:45 pm

      Hmm, it messed up the formatting. I hope it’s readable.

      • February 22, 2014 at 8:48 pm

        You can fix the formatting by putting it between <pre> tags.

    • February 22, 2014 at 8:49 pm

      That’s interesting! I’ve actually been getting a similar result. I may have to try it out and see how it feels.

      • Mike Rouse
        February 22, 2014 at 9:27 pm

        One of several things I find interesting is that the only letters on the left hand are vowels, but it has *all* of them (even y, which is kind of iffy). Plus plenty of punctuation, of course. Maybe Dvorak was on to something. 🙂

        I tried a few common words. ” The ” (including spaces) is fun to type (which is good, since it’s so popular). “And” is fine, though a bit odd (from thumb to index finger outstretched). “People” has the annoying “eo” bigram, but compared to QWERTY, it’s a breeze. “Because” would be a little challenging to start with, but still less than with QWERTY jumping across the home row from E to C.

        All in all, it looks really logical, and putting P/N on the thumb would probably be fine. Wrapping my head around putting space on the left index finger will take some getting used to — I can see where it fits with the scheme, but it goes against every keyboard layout I’ve seen. Which of course means it’s very interesting trying to find out why! Quoting Isaac Asimov, “The most exciting phrase to hear in science, the one that heralds new discoveries, is not ‘Eureka’ but ‘That’s funny…'”

        • February 22, 2014 at 9:31 pm

          Good observations! I think it’s okay that “eo” is annoying, since “eo” is pretty uncommon in general text.

          It actually makes sense to put SPC on the left index finger. “e” is the most common last letter of a word, so “e ” is a very common digraph. The “e ” finger roll is quite comfortable.

  26. Michael Rouse
    April 26, 2014 at 4:03 pm

    I just wanted to let you know I was still working on the “Thumb-E” version of the keyboard. If anyone is curious, I have posted a couple of basic images of my work in progress here:
    http://geekhack.org/index.php?topic=48292.msg1309062#msg1309062

    Sadly, their swearing filter mangles Michael D’s last name (or at least it had a bunch of asterisks in the preview), so I had to alter it for that.

  27. Paul
    August 21, 2014 at 8:20 am

    Hey Michael.

    Just in case you are interested, a while back I wrote some code to make layouts too. I am about to start a new program based on a different method but I thought I would come and see what you have been up to.

    The source code for the program is at https://gitorious.org/keyboard-layout/keyboard-layout/

    The layout I finalised with, I am not sure if that is the exact code for it, the config would have been different too, I am not even sure if the program works; it has been a while since I used it. But the source is there to look at the method. I think a lot of the evolution code is redundant, I changed method half way through development because I found it was faster to make a singe change to one layout, over and over, then start with a new layout and compare.

    The layout I use now is this (I suspect the space formatting will be destroyed):

       %  /  [                 ]  v  z 
       .  !  a  &        q  f  l  g  k  j
       i  e  o  n  ,     b  h  t  s  c  d
    y  _  -  '  u  ;     r  x  w  m  p
    

    I have numbers, brackets and such on the alt gr layer.

    I would not have posted this but I noticed your post on the 26th of April, 2014 referenced your latest work with a htsc on the right hand.

    • Paul
      August 21, 2014 at 8:22 am

      The formatting was destroyed so to clarify, there is an unused key after the & key, the 1, 4, 6, 7 keys from qwerty are unused, and this is a British layout so the y is half of the US shift key.

    • August 22, 2014 at 3:42 am

      Thanks for the link! That’s pretty neat! I haven’t seriously modified my program in over a year, so I don’t have any new developments or ideas if that’s what you’re looking for. Best of luck with your own program–it looks like it’s producing strong results. (But why is the ‘R’ key in such a strange location?)

      You can properly format a keyboard layout by surrounding it in <pre></pre> tags. I did my best to fix the formatting, but please make sure I did it correctly.

  28. Stein
    May 11, 2016 at 7:36 pm

    Michael, are you able to put together an optimal layout for Hebrew keyboard including the ‘nikudot’ vowels?

    The Hebrew Bible with vowels works for the text source for frequency.

    • May 13, 2016 at 10:15 pm

      The program only directly supports ASCII. You can sort of simulate other symbols if you translate them into ASCII and then run the program on the result. If there are more than 128 characters then you’re out of luck. I would have to do a lot of work to rewrite the program to support non-ASCII. If you know how to program and want to take this on that would be great, but I don’t plan on doing it myself.

      • Stein
        May 17, 2016 at 10:17 pm

        Hi. I converted the Hebrew Bible into two ASCII text files.

        One file represents the letters only.

        The other file is the same text but represents the letters (mainly consonants) plus the pointings (mainly vowels).

        If possible, each file needs a separate optimized keyboard. The one with letters only is necessary to understand the minimal ‘same finger’ typing.

        The one with the vowel pointings is necessary to understand where is the best place to put vowels.

        The following ASCII symbols represent the 27 Hebrew letters:

        ‘ B G D H U Z X t Y K k L M m N n C ^ P p J j Q R S T

        Notice the symbols are case sensitive, so uppercase T and lowercase t represent two unrelated letters, and both need to be in the lay out separately. Also notice, the apostrophe ‘ and the caret ^ are two letters.

        In a separate file, the 14 pointings are added.

        i E 3 A 4 O W ` 8 7 0 ! h s

        Notice the numbers represent pointings and should be treated like normal letters, and might show up anywhere in the layout depending on frequency and miscibility.

        The punctuation is mainly period . and comma , plus if space allows then less importantly dash – and parentheses ( )

        Let me know the best way to send you the two ASCII .txt files, if you are able to run them. You have my email too, if that helps.

        • May 17, 2016 at 11:53 pm

          You need to convert the text files into two files, allChars.txt and allDigraphs.txt, and replace the files with the same names in Typing/data/ in my typing program. You can look at those files to see what format they should have. I wrote a program that does this conversion if you want to use it: https://github.com/michaeldickens/Frequency

          My keyboard optimizer always pairs lowercase and capital letters on the same key, but you can fix this. Go into tools.c and look at the keepShiftPair function (should be on line 767). It says

          return keepShiftPairs || isalpha(c) || isspace(c) || c == '\b';

          Change it to say

          return keepShiftPairs || isspace(c) || c == '\b';

          I haven’t tested it but I believe this should work.

          • Stein
            May 22, 2016 at 9:25 pm

            Hi, I got hold of a program called, optimization.exe, that is attributed to Michael Dickens with web address.

            It seems to run on my Windows 7, but I am unsure how to use it.

            It prompts as follows:

            >>>

            What should I do now?

            Can you give a step-by-step walk thru for what I need to enter, when and where?

  29. Stein
    May 31, 2016 at 1:36 am

    Michael, it appears I am unable to get the keyboard optimization program to work.

    Are you able to run it on your computer for me?

    • May 31, 2016 at 10:19 pm

      It sounds like it would be a lot of work to pass the program back and forth between us. Can you elaborate on why it doesn’t work? Maybe I can help.

      • Stein
        June 20, 2016 at 12:33 am

        The main problem is, the Optimization program is not in the Windows environment.

        As far as I can tell, the Optimization.exe executable for Windows doesnt allow alterations of any coding files that were used to build the .exe.

        Also, there are no instructions about how to use .exe, not even what commands are necessary to enter to make it work.

        It seems you developed an excellent algorithm (and at least you can to get it work).

        It will probably help many people around the world if it is usable in Windows and with a friendly interface.

        • June 20, 2016 at 2:37 pm

          You need to compile the program for Windows. Unfortunately, compiling C programs on Windows is a pain. I’ll try to create a Windows executable using my VM.

          For what commands are necessary: just run the program with no input and it will tell you what inputs to use.

          • Stein
            July 3, 2016 at 10:35 pm

            The VM Windows executable sounds awesome. It will help me alot, and probably many others too.

  30. Stein
    November 15, 2016 at 5:55 am

    Any news about a keyboard optimizer for Windows, that can be used for Hebrew letters?

    • November 15, 2016 at 6:21 pm

      Hi Stein,

      I know that you can get it running on Windows if you can compile C–I haven’t personally done it, but other people have.

      As for supporting Hebrew, I’m not actively developing the keyboard optimizer. This would be a pretty big change so I don’t plan on developing it. The code is open source, so anyone who wants to is free to make this addition: http://github.com/michaeldickens/typing

    • Mycroft Jones
      December 28, 2016 at 11:30 am

      Stein, contact the guy who did the neo-Paleo encoding standard. He’s done lots of related work with Hebrew vowel points, cantillation marks, etc. http://loveandtruth.net/neopaleo.html

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: