Home > Keyboards > Kinesis Contoured Keyboard

Kinesis Contoured Keyboard

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
  1. Tim Johnson
    December 30, 2011 at 11:27 am

    You’re right that the thumb keys are too high. Other people have complained about them too. The Maltron correctly puts the thumb keys down low; unfortunately, it’s absurdly expensive. It’s strange that the Kinesis gets the thumb keys wrong, since the Kinesis is a copy of the Maltron, and according to the Adaptation Exercises booklet included with the Kinesis (at least as of a few years ago), “Mr. [Jack] Litewka was a senior consultant and master trainer for Malt Keyboard Dynamics in the 1970s … and was instrumental in designing the European Maltron … Mr. Litewka is a consultant to Kinesis Corporation.” So Kinesis certainly knows that their thumb keys are wrong.
    Fortunately, there is some hope. Look at the original Maltron, and you’ll see that the center thumb keys (by default delete and enter on the Kinesis) are each split into two square keys, like home/end/pgup/pgdn, not enlongated like the space key. That gives an extra thumb key for each thumb, but it’s ergonomically terrible; they fixed it in their latest version, a fix which I believe they copied from the Kinesis. So innovation is occurring, and being copied in both directions.
    Thumb keys as on the original Maltron:

    New version:

    I’m not sure what you mean by the Mac ctrl, alt, and command on the “outer edges” of the thumbpads. I use a PC, but according my Kinesis manual, the Mac has the following layout for the thumb keys:
    left thumb, left column: backspace/mac delete
    left thumb, middle column, top to bottom: command, forward delete
    left thumb, right column, top to bottom: alt/option, home, end
    right thumb, left column, top to bottom: ctrl, pgup, pgdn
    right thumb, middle column, top to bottom: command, enter
    right thumb, right column: space
    Is yours the same?
    I also don’t understand what you mean by shifting the thumb pads “outward”, or how this would enable the thumbs to rest comfortably in the center.
    For me, besides being too high, the Kinesis thumb keys are also positioned too close to my body; my thumbs extend beyond the top of the backspace and space keys. Maltron’s positioning is better. The following image of the flat Maltron makes this positioning more clear than do the above images of the curved versions; notice how the corners of the backspace and space keys meet the corners of the qwerty B and N keys:

    Another problem is that the home/end/pgup/pgdn keys on the Kinesis are wrong. Maltron gets them wrong too (it also assigns them different functions than Kinesis does, but that’s irrelevant here; I’m just talking about physical layout). It seems to me that the best thing to do would be to replace these keys also with enlongated keys, so that each thumb has three parallel enlongated keys, rather than just two. This would eliminate one key from each thumb, but they can be restored by putting keys above the backspace and space keys (as Maltron already has).

    I’m not sure what the patent situation used to be, or whether it had any effect, but any relevant patents must have long since expired. If enough people voice their complaints, maybe both companies will fix their designs.

    While I have your attention, can you rank the following 8 digraphs on the Kinesis with the qwerty layout, from easiest to type to hardest?
    as, sa, ad, da, sf, fs, af, fa. The differences aren’t extreme, but I’d still like to know how you’d order them. If multiple digraphs from that group are of equal difficulty, then group them together rather than arbitrarily ordering them. Also rank the digraphs for the right hand (using “jkl;”), if you don’t get symmetric results for your hands. The order for me is (af, fa), (sf, fs, as, sa), (ad, da), and the right hand results are symmetric.
    Also rank the following 4 trigraphs:
    asc, csa, asv, vsa. For me it’s (asv, vsa), (asc, csa), and the right hand results are symmetric.
    It seems that ad and da are the hardest digraphs because of the ring finger being the hardest to lift above the others, and I assume you’ll agree that ad and da are the hardest. But I’m not sure why asc and csa are harder than asv and vsa, and I’m not very sure you’ll agree that they’re the hardest.
    Of course, my reason for asking about these is for evaluating alternative layouts which have commonly-used digraphs and trigraphs on these keys. For example, Maltron puts the fairly common trigraph “wor” on the qwerty “ml;”, qwerty’s right hand equivalent of “vsa”.

    • December 31, 2011 at 5:42 am

      Thank you for your thoughtful analysis of keyboard hardware.

      My point regarding the ctrl and alt keys was that they seem too far away. The thumb pads would be easier to use if there were three columns, and the thumb rests in the center column—so that it can easily reach the columns to the left and right—instead of the rightmost column. As it is, the leftmost column (where the ctrl and alt keys are) is hard to reach. That would be like resting your fingers on the bottom row instead of the home row.

      My ranking: as, af, sf, sa, fa, fs, ad, da

      asv, vsa, asc, csa

      Right and left hands are symmetric.

      I agree that jumping over the ring finger is difficult. I also find inward rolls to be much easier than outward rolls, which is why I don’t rank any of the digraphs as equally difficult.

      For the trigraphs, I think asc/csa is harder because the middle and ring fingers are relatively strongly connected, so it is difficult to move the middle finger downward right after typing with the ring finger.

  2. Tim Johnson
    January 1, 2012 at 1:33 am

    It’d be a good idea to modify your program to measure and penalize ring finger jumps. Your currently optimal layout has a substantial number of them.
    For inward vs. outward rolls, do you find it as significant for the index and middle fingers as for the ring and little fingers? I.e. is “df” as much better than “fd” as “as” is than “sa”? If not, it’d be a good idea to modify your program to reflect the difference, so that, for example, it wouldn’t apply too much of a penalty for swapping “t” and “h” from your currently optimal positions.

    Considering your rankings, I have two more digraphs to ask about: sc and se. (Assume the letters before and after will be on the other hand, so it won’t be e.g. the “asc” trigraph). Where do sc and se fall in your as, af, sf, sa, fa, fs, ad, da ranking? For me, I get (af, fa), (sf, fs, as, sa), se, sc, (ad, da); it’s interesting that lifting the middle finger above the ring finger is easier than vice versa, even when consequent movement of the index and little fingers doesn’t matter.
    I’ll try not to bother you for any more rankings after this. 🙂

    It appears that by “outward” you meant moving the thumb pads farther away from the center of the keyboard; I was assuming you meant farther away from the center of the hand in question (thus toward the center of the keyboard). But then you would mean ctrl and alt are placed on the inner edges, not the outer edges.
    Anyway, lay a piece of paper on a flat surface, rest your hand naturally on it, with your fingers curled comfortably for typing, and trace your fingertips, including your thumb. Then draw a 19mm square around each one, which is the standard keyboard (and Kinesis) key center-to-center distance. Use 19x38mm for the thumb. Adjust the squares so they’re aligned horizontally, but leave them vertically staggered (the opposite of standard qwerty). Add one more square next to the index finger’s square, horizontally and vertically aligned with it, to be the home row center column key for that index finger. Now add another square below that last one, to be the bottom key of that center column. Notice that it just barely fits; you might even have to push the thumb key out a bit to make room. Your paper should now be starting to look like the flat Maltron which I linked in my previous message. There’s room for two keys (actually, even more, but more than two would be awkward to reach) below home row in the index finger’s home column, but room for only one key below home row in the center column. There’s room for more 19x38mm thumb keys outside the thumb’s home key (i.e. toward the center of the keyboard), but no room for another one inside the home key (i.e. toward the other fingers), except by deleting the bottom key from the index finger’s home column and putting the new thumb key in an awkward position, which defeats the purpose. Do the same experiment for a 3D contoured keyboard, and you get the same result.

    My point is that the thumb pad can’t be positioned so that the thumb naturally rests on the center column. No matter how you try it, you’ll either end up with the thumb’s home key in an unnatural position, or the inside key (the one between the home key and the center of the hand) in an awkward position, on either a flat or ergonomically correct contoured keyboard.
    On the Kinesis, the thumb pads could be shifted slightly toward the center of the keyboard, making room for another square key for each thumb, placed beside space and backspace (below the index fingers), which would be only somewhat awkward for the thumbs to press by curling in, but this is only because the thumb pads are too high (in the third dimension); if the thumb pads were lower as they should be, then these additional keys would be completely unergonomic.
    I recommend a much better solution: palm keys, like this:
    This would have the side effect of very quickly teaching you to obey the professional typing teachers, and not type with your palms resting on the keyboard. 🙂

    • January 1, 2012 at 9:18 pm

      I think se is harder than sc.

      My ranking: as, af, sf, sa, fa, fs, sc, se, ad, da

      Regarding ring finger row changes, I just modified the “hand warp” penalty so that it includes any row change of adjacent fingers except for middle and index where the middle finger is above the index finger, e.g. ef or dv. Any other row change with adjacent fingers is especially difficult, including the middle and index finger where the index finger is above, e.g. dr or cf.

      I got the following as the best Kinesis keyboard:

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

      Compared to the old version:

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

      This is almost identical. The worst digraph in terms of row change is still ON. Apparently the increased penalty was not enough to significantly change the layout. If I further increase the penalty for difficult row changes (“hand warps”), this is the result:

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

      This substantially reduces hand warping, at the cost of other factors such as increased same finger usage.

  3. Patience
    January 2, 2012 at 6:09 am

    Just out of curiosity, what is the standard keyboard layout (i.e. non-Kinesis) given by your program with the same hand warp value as the “heai” layout?

    • January 2, 2012 at 6:25 am

      hand warp = 45 (normal is 15):

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

  4. January 2, 2012 at 6:50 am

    Could you upload your optimizer after you’re done modifying it? My issue with the inea layout was really some slightly awkward row changes with the left hand.

    Also, is it just me or should the letters m, l and c be switched in the standard layout you just gave? Since those are the only big differences with the Kinesis version.

  5. January 2, 2012 at 7:16 am

    Uploaded: http://mtgap.bilfo.com/Typing.zip

    Run the program, type in “set handWarp 45” (or whatever value you want), and then type “algorithm”. Type “help” for more options, e.g. changing the layout type from standard to Kinesis. Note that if you set handWarp to be too high, it may cause integer overflow and you will get erroneous results.

    It is probably intentional that m, c, and l are in those positions. There are some small differences between standard and Kinesis, so it makes sense to move around a few keys.

  6. Patience
    January 2, 2012 at 7:47 am

    I like the changes to the keyboard position costs. What’s the new “finger work”, though?

    • January 2, 2012 at 4:24 pm

      Before, the way it worked was that each position on the keyboard had a certain cost, based on how hard it is to hit overall. I changed it so that the position cost is only based on how hard it is to reach—i.e. on a symmetric keyboard, QWERTY z costs close to the same as v. Then I added a penalty for overworking each finger. So using the pinky up to a certain amount (say, 8% of total work) is free, and any amount after that has a high cost that increases the higher the workload is.

      The percentages for pinky, ring, middle, and index are 8, 13, 22, and 22. In practice, this prevents the ring fingers from taking the bulk of the work and keeps the pinkies’ load light.

      And that also explains why I changed the keyboard position costs. I think this new model more accurately reflects how people actually type.

  7. Tim Johnson
    January 2, 2012 at 10:11 pm

    I agree that penalizing row changes involving the ring finger is also a good idea, but what I meant in my previous message by “ring finger jumps” was column jumps over the ring finger (either on the same row or not), e.g. “ad” on qwerty, and “ie”, “io”, and “tr” on your optimal layout, which you agree are even harder than qwerty’s “sc” and “se” hand warps. That’s also why I asked about inward vs. outward rolls for the index and middle fingers; if there’s not much difference (unlike for the ring and little fingers), then a good way to get rid of the “tr” ring finger jump on your optimal layout would be simply to swap “t” and “h”.

    I think I see why you find “se” harder than “sc”: it’s another design flaw in the Kinesis (and the Maltron). Try turning the keyboard left, to a 45 degree angle to your body (rotating around the z axis; leave the keyboard flat on your desk), and use just your left hand. Now, “sc” on qwerty is natural, “sd” is as hard as “se” was with the keyboard straight, and “se” is effectively a ring finger row change. Notice that “se” remains harder than “sc” at any angle between 0 and 45. So why does it remain harder even when the keyboard is straight? Because when it’s straight, although the angle to your body is zero, the angle to the perpendicular of your arm is not zero; it’s still about 15 degrees, and the only ways to make it zero are to move the keyboard off center (which results in an even bigger angle for the right arm), or hold your elbows unnaturally in front of your body instead of at your sides, or split the keyboard in half and spread the halves apart, or cut a 30-75-75 triangle out of the center of the keyboard and close the diagonal edges together to set the keys at a natural angle (the Kinesis actually is slightly angled, but only at a few degrees, not nearly enough).
    Notice another symptom of this design flaw: the outer column of keys for each hand, where the shift key is, is shifted up (along the y axis) a few millimeters relative to the little finger’s home column. This is necessary only because the natural position of the hand isn’t parallel to the columns; if it were parallel, then the outer column’s most natural position would be vertically unshifted, aligned with the little finger’s home column. You can see this by setting the keyboard off center, so your left arm is parallel to the columns, resting your fingers on the home keys, and then trying to press caps lock; notice that your little finger now lands not on the center of the caps lock key, but on the bottom of it.

    But after all that, maybe you’ll still say that even with your hand parallel to the columns, “se” is still harder than “sc”. Well, I tried. 🙂

    By the way, I figured out how to solve the thumb pad positioning problem as you want, which I said in my previous message was impossible. On the Maltron, simply insert a vertical thumb key (pressed horizontally), like on the Datahand, between the Maltron’s home thumb key and the index finger’s home column’s bottom key. Press it by squeezing the thumb inward, which requires no more motion than pressing the thumb home key. Ta-da! In effect, each thumb now has two home keys, one horizontal, one vertical.
    Some mechanical engineering finesse would be required, but it would fit. Everybody who’s interested, call Maltron and ask if they’ll do it. 🙂

    • January 3, 2012 at 12:08 am

      Ah, thanks for clarifying. I have some hesitation about adding new measures—there are already 22 variables to measure 10 types of finger motions—but I suppose it is better to be accurate than overly simplistic. I added a penalty for ring jumps.

      I got the following average words per minute for trigraphs doing ring jumps.

      MTGAP 2.0

      twice ring jump average: 103
      ring jump average      : 119
      not ring jump average  : 113


      twice ring jump average: 119
      ring jump average      : 104
      not ring jump average  : 104

      Controlling for trigraph frequency, we have:

      MTGAP 2.0

      twice ring jump average: 9
      ring jump average      : 13
      not ring jump average  : -1


      twice ring jump average: 25
      ring jump average      : 9
      not ring jump average  : -1

      These results are weird.

      Here is the keyboard for Kinesis where the cost for ring jumps is set to 40:

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

      This reduces ring jumping from about 3.8% to 2.3%.

      • Atle
        January 7, 2012 at 6:16 am

        Im glad to see the ring jump penalty. (For example, the qwerty-AD keys. “Ring jump” is a good name for this.)

        I mentioned a while back in an earlier thread, the problem with ring jumps seems to be negligible for less-frequent digraphs, but straining (perhaps even injurious) for a very high-frequency digraph.

        I noticed the problem when I assigned the digraph HE to the left inward ring jump. Usage increased discomfort, even soreness. But the somewhat less frequent RT digraph on the right didnt seem to be an issue.

        I feel the new penalty helpfully prevents layouts with the highest frequency of ring jumps.

        • Patience
          January 10, 2012 at 2:24 am

          You don’t find the “ion” pattern to be bothersome? I have never tried a pinky-ring H-E layout, but the frequency of “ion” worries me a little.

          • Atle
            January 10, 2012 at 5:54 am

            Actually, Iv been using an “isea” layout, so I have no issues with the ion trigraph. For me, the same keystrokes would spell ios.

            I actually the “isea” because the digraph es for the outer roll, mid-ring, is less frequent than er or en. It seems os is also less frequent for or or on. So, I havent had to deal with the on in ion.

            I agree the left upper-mid-home-ring is an awkward roll.

          • January 10, 2012 at 2:53 pm

            I don’t like that “ion” pattern, but it is important to consider the keyboard layout as a whole. If almost every common trigraph is very comfortable, it is okay if just one is not so comfortable. Right now the program evaluates keyboards using digraphs rather than trigraphs—I want to change that at some point down the road. “ion” is especially bad because it not only changes rows but reverses directions. I would penalize direction changes if the computer used trigraphs rather than digraphs. But for now, it consider “io” and “on” separately.

            The program knows that both “io” and “on” are uncomfortable, and it still produced this as the best layout. I think we humans have a tendency to focus on the most common character patterns, whereas the computer looks at all patterns. I would be more inclined to trust the computer here.

            Of course, how uncomfortable a pattern is may not be a linear function of how frequent it is—it may be something like quadratic, that is, an uncomfortable digraph that is twice as frequent is four times harder to type. If that’s the case, how exactly would we model the growth function? If it can be modeled, the program can take it into account.

  8. Patience
    January 4, 2012 at 3:21 am

    I was wondering about something for number optimization. Instead of forcing the numbers to be in order on the top row, they could simply be confined to the top row, meaning that they would still be able to move around a little. For example, I imagine that 0 and 1 would be placed on the middle fingers. How hard would it be to implement that?

    • January 4, 2012 at 6:16 pm

      Here you go.

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

      This layout may not be optimal, but there is a bit of a bug that I am trying to fix.

  9. Patience
    January 7, 2012 at 11:45 pm

    How annoying do people find the QWERTY “aes” trigraph? It’s the “ion” digraph in the ineahtsr layout, and I can’t really decide whether it’s too annoying for how frequent “ion” is.

  10. Atle
    January 12, 2012 at 2:00 pm

    It is important to consider the keyboard layout as a whole. If almost every common trigraph is very comfortable, it is okay if just one is not so comfortable.

    Yeah, thats the cool thing about MTGAP approach to the keyboard layout. It remains open to whatever keyboard is objectively (or at least measurably) best. And from there, individuals can customize it by (carefully) swapping one or two keys if they happen to have a personal preference.

  11. Patience
    January 17, 2012 at 7:18 am

    Just curious about this, but I have noticed that the main-30 optimizer and the full layout optimizers use different char/digraph frequencies. For example, 30digraphs.txt lists th, in, re as the top three digraphs, and alldigraphs.txt lists th, he, in as the top three digraphs. “He” is actually 28th in 30digraphs.txt. This would explain why the main-30 gives an areihtsn layout compared to full layouts that give ineahtsr.

    So I was just wondering if there was any particular reason for this difference.

    • January 17, 2012 at 7:04 pm

      That’s an error. I think the most recent version I’ve uploaded should be correct. If not, soon I am going to make some changes based on your previous comment (about confining keys to certain positions) and re-upload it.

  12. Patience
    January 20, 2012 at 4:18 am

    Just out of curiosity, do you know how to type both qwerty and mtgap 2.0 on your kinesis? I can’t for the life of me type qwerty on my kinesis. I would have to relearn it from zero. I wonder if that has to do with the fact that the first layouts I learned to type on my kinesis were dvorak, arensito and colemak.

    • January 20, 2012 at 3:00 pm

      Yes I do. I do most of my typing at school, where I use my laptop keyboard, and use either QWERTY or MTGAP 2.0 depending on what I’m doing. When I’m at home I usually use Kinesis with MTGAP 2.0, but I can use QWERTY as well.

  13. bogboar
    February 13, 2012 at 11:41 pm

    Hello, awesome programming-master(s). I love the work being done in this project and I have read through the entire blog on this topic.

    I am planning on getting a Kinesis, and I’d love to start using a MTGAP layout on it. But I have a few questions:

    1. I plan to put my E-key on a thumb-key. I read that, as a band-aid solution I can replace the “e” in the kinesislayoutstore.txt to make the program run as though “e” doesn’t exist? But I’m a bit confused as to what to replace it with? Am I completely off-track?

    2. I plan to remove Shift, Caps Lock, the arrow-keys and all the numbers to relocate them to thumb-keys and footswitch-layer. I’d love to see what results all this would produce with your layout generator. Any chance a part of it is easy to do through existing settings?

    • February 14, 2012 at 12:37 am

      1. The keyboard has 47 keys (technically Kinesis has 48, but my program ignores one of them). So in kinesislayoutstore.txt, put whichever 47 characters you want on there. If you remove ‘e’, I’d suggest replacing it with some fairly common punctuation. This will work better once the program supports shifted characters, which I’m working on.

      2. Unfortunately, the program currently cannot evaluate modifier keys. (I am working on this.) I suggest you use the following thumb key remapping:

      backspace –> shift
      delete –> backspace
      home –> esc
      end –> delete

      Then you could remap Shift or Caps Lock to a dead key that allows you to type less-frequent special characters, sort of like Option on a Mac. (I find that having a Shift key that I can press with my pinky is still useful if I have to do a multiple-key modifier sequence, like ctrl-shift-tab.)

      • bogboar
        February 14, 2012 at 9:00 am

        Alright, so I can replace ‘e’ as well as 1234567890 with whichever punctuations I want from “allchars.txt”. The order doesn’t matter, I presume.

        The program is still using these symbols though. I have to run ‘make’ again after those changes are done, if I understand correctly? I’m not at a workstation allowing me to do this at the moment.

        Another question. In “values.c” the costs entered for key locations are now only used to represent how hard things are to reach – hence pinky and ring fingers having the same costs etc, if I’ve understood it correctly. I can’t by any chance “reserve” certain positions by entering 999 in these fields? The program is not made to work like that?

        • February 14, 2012 at 2:32 pm

          Sorry, this part gets tricky. You don’t need to run ‘make’ again because it reads those files at runtime, but you do need to modify alldigraphs.txt and allchars.txt to include whatever characters you want. (Right now they only include the exact characters that layouts use by default (for efficiency reasons).) You probably don’t have the necessary materials to do that. I’ll try to modify those files to include all ASCII characters, and make a few modifications to make it more efficient.

          What do you mean, “reserve” positions? Do you want to put a character there that the program isn’t allowed to move around? Putting 999 for the cost doesn’t actually do anything except indicate to the reader that nothing goes there.

          • bogboar
            February 14, 2012 at 8:03 pm

            Alright, but if I stick to those characters you’ve included in allchars.txt, it should work fine, right?

            I change the characters in kinesislayoutstore.txt and I run “setfk kinesis”. I am then able to run “improve kinesislayoutstore.txt” and it reflects the changes I’ve made. But the “algorithm” command still runs with the original characters.

            Is this intended? Do you think I should run “algorithm”, then change the characters, and run “improve” on the result? It doesn’t seem like “improve” does a perfect improvement at all.

            I am running this stuff in MinGW though. I’ll get around to trying it in a Linux environment later in-case that’ll make a difference.

          • February 14, 2012 at 10:26 pm

            I’m working on fixing “algorithm” so it uses whatever keys you tell it to use. The reason it works and “improve” doesn’t is because “improve” only gets keyboard layouts from layoutstore.txt, whereas “algorithm” sometimes uses layoutstore.txt and sometimes makes its own layouts.

            “improve” only goes until the simulated annealing algorithm runs out of steam—the result should be very good, but probably not perfect. “algorithm” runs the simulated annealing algorithm many times (usually several hundred or thousand) and picks the best result.

        • February 19, 2012 at 5:15 am

          I modified the program to make it easier to change what keys are in the layout. Now you can use any printable, non-whitespace ASCII character. All you have to do is change layoutStore.txt (or kinesisLayoutStore.txt, or whichever you’re using) so that every layout includes only the characters you want to include. Then, when you run the program, type in:

          >>> use

          You can get the latest version of the program at https://github.com/MTGandP/Typing

    • February 26, 2012 at 8:35 pm

      When you put E on a thumb key, what key do you plan to displace, and where do you plan to put it? Can you show me what you want your keyboard to look like?

      • bogboar
        February 27, 2012 at 11:27 pm

        I envision a layout something like this:

        ESC ¤  ¤  ¤  ¤  ¤   ¤  ¤  ¤  ¤  ¤  ¤
        TAB ¤  ¤  ¤  ¤  ¤   ¤  ¤  ¤  ¤  ¤  ¤
         ¤  ¤  ¤  ¤  ¤  ¤   ¤  ¤  ¤  ¤  ¤  ¤
         ¤  ¤  ¤  ↑  ¤  ¤   ¤  ¤  ¤  ¤  ¤  ¤
            ¤  ←  ↓  →         ¤  ¤  ¤  ¤
        SPC SH                          BS e

        Placement of E obviously has two rules:
        • to be put under the opposite thumb to Shift, so Shift+E combo is easy.
        • to not be next to Space, as many words end with E and a space would naturally follow.

        Due to computer games I prefer to press space with left thumb, so from that the positionings work themselves out. The only thing left to discuss is Backspace versus Enter.

        Arrow-keys all under the left hand are so I can use the mouse with my right hand at the same time.

  14. bogboar
    February 14, 2012 at 8:13 pm

    What do you mean, “reserve” positions? Do you want to put a character there that the program isn’t allowed to move around?

    Yes, that or keep the slot empty. “Lock out” a certain slot. Maybe this would involve a lot of programming, I don’t really know.

    I am thinking about placing arrow-keys in the traditional inverted-T layout right under the middle-finger.

    This would mean that you only need to move down a row and you have instant access to all arrow-keys, even while your other hand is busy using the mouse.

    Like this (I’m hoping this formatting turns out good-looking):

    ! @ # $ % ^ & * { } z
    . p o u – k m d c w x
    i n \ a y f h t s r ”
    ‘ , ↑ ) _ v l b g q
    / ← ↓ → j =

    • bogboar
      February 14, 2012 at 8:20 pm

      Good God. I need to establish a WordPress account so I can edit my comments. Alright, my second shot at formatting it nicely…

       !  @  #  $  %   ^  &  *  {  }  z
       .  p  o  u  -   k  m  d  c  w  x
       i  n  \  a  y   f  h  t  s  r  "
       '  ,  ↑  )  _   v  l  b  g  q
       /  ←  ↓  →                     j  =
    • February 14, 2012 at 10:41 pm

      In cjalgorithm.c, you’ll find a number of arrays called legalBox1, legalBox2, etc. Using the following instructions, modify whichever legal box is appropriate for the keyboard you’re using (legalBox1 for main-30, bigLegalBox1 for full standard keyboard, kinesisLegalBox1 for Kinesis).

      The number indicates which keys may be swapped. Any number 1 may be swapped with a number 1 but not any other number; any number 2 may be swapped with a number 2; you get the idea. Change the keys you want to lock to a new number, and make sure the starting keyboard doesn’t put anything important on any of those locked keys.

      Let me know if this doesn’t work.

  15. bogboar
    February 28, 2012 at 10:35 pm

    Michael Dickens :
    On that layout, where would you put Enter?

    Well, it seems to me rather ambiguous where exactly it should be. I think it’s most æsthetic if it sits somewhere along an edge of the keyboard. I’ve yet to come into any insight for placing it a particular location. It’s basically just another key.

    As it is I’d place it below Tab just to keep it close together with the other “special keys”. Though it might as well be in its conventional, right-hand-pinky position to reduce on relearning, there is merit – for right-handed people – if it were to be under the left hand, because you don’t have to take your hand off the mouse.

  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: