For a few months now I have been working on a new keyboard layout, and it’s finally complete! I got sucked into the layout wormhole after I started learning Colemak and just wasn’t finding it comfortable. To find this layout I created a scoring system that favoured movements I found to be comfortable, and used randomisation and a simple genetic algorithm to find high scoring layouts. There was also a long period of trialing and tweaking to get it just right.
The qualities I considered important are – low single finger bigrams (of course), a high inwards roll : outwards roll ratio (I don’t like outwards rolls that much), avoiding particularly bad rolls like pinky -> middle finger while keeping particularly good rolls such as adjacent finger rolls and pinky -> index finger rolls. Low travel distance was favoured, but not too highly – it’s trivial to beat qwerty by almost 50% on this metric, but it’s not worth a lot of attention due to diminishing returns.
Here is the layout, inventively named Kaehi –
That’s a short rundown. For those interested I have documented the development of this layout in further detail below.
The number of possible keyboard layouts is vast, so I created a simple program to rapidly prune the possibility space. This program creates a score for a given layout based on the overall key positioning (frequently used keys being more accessible), hand balance (relative amount of work done by left and right hand), and the motions used to type bigrams (bigrams are letter couplets) . For bigram motions, my scoring favours inward rolls over hand alternations over outward rolls. Single finger bigrams receive a large negative score. This scoring reflects my personal preferences. While I do not like hand alternations that much, my scoring favours them over outward rolls, which I really dislike. Outward rolls definitely get easier with practice, but I think our hands are inherently less suited to doing them. As a demonstration of this, try rapping your finger tips on a table, you will invariably be able to do this in an inwards rolling pattern very quickly, but you might struggle to do it with much consistency at all in an outwards rolling pattern.
In addition to scoring a given layout, the program generates new layouts based on the current one by randomly swapping keys around. It cycles through thousands of variations per second and checks if any of those variations score higher than the original. Every few minutes it sets the highest scoring variation as the new base and begins making variations on that. It is a simple hill climbing algorithm. The higher the base layout is up the scoring terrain, the longer the program spends looking for variations.
I did place some restrictions on the layout generator. For this new layout I wanted to keep the ZXCV cluster of keys in their original QWERTY positions. This is helpful because it means the most commonly used shortcuts (undo, cut, copy, paste) do not move. It also means that there are at least four character positions that you do not have to relearn, and the impact on the efficiency of the layout should be minimal. I wanted to leave most of the punctuation alone, with the exception of moving the semi-colon key into the ‘P’ position. This is a no-brainer, most newer alternative layouts do this. The ‘P’ position is a little annoying to reach, better to have some obscure punctuation there than a letter. I later swapped the colon and forward slash positions, as a C coder, I use colon a whole lot, and that position is much easier to reach.
While the program was essential to arriving at a layout with decent metrics, I still had to put a lot of time into testing and refining based on my experiences. An algorithm cannot arrive at the optimal layout for me without complete information about my preferences, and I cannot know my own preferences perfectly. The algorithm may have done 95% of the work, but that last 5% of manual tweaking really makes the difference. I agonised over every key placement, both from an efficiency and a comfort perspective. I tried common words and bigrams on a half dozen variations. It might be hard to sell anyone else on this layout as it is so finely tuned to my own tastes, but I think that peoples hands are probably not all that different.
My program quickly generated a few promising layouts. Some of these I gave a few extra hours of variation searching to fully refine. In the end, this is the one I was most impressed by –
I began practicing with it, thinking that I had arrived at the best possible layout for my preferences, however I started to notice a big problem. I learned from trying this layout that the top left key position is not just bad, it is really, very, incredibly bad. Now this may vary based on the shape and size of your hands, but for me, this is the most uncomfortable position to reach. It is so awkward to reach that I actually do not want it to be part of inward rolls, because rolls only make the reaching more strenuous. ‘PL’ and ‘PR’ combinations were torturous to type. As it turns out, this makes that top left position the perfect place for the ‘Q’ key. ‘Q’ is inevitably followed by ‘U’, which is on the right hand, and this hand alternation avoids rolls and gives you time to reset your left hand to a neutral position. As an added bonus, it is the same location as on the QWERTY layout, so it should be easier to adjust to.
I also discovered that I did not like the position of the ‘W’ key. ‘W’ often leads into ‘H’, and I was finding this movement, followed by a vowel, very uncomfortable. I decided that ‘W’ and ‘H’ should not be on the same hand. Additionally, I found that I wanted to avoid movements that used the pinky followed by the middle finger. This is because the ring finger is more tightly bound to it’s neighbours than the other fingers. You can see this for yourself – simply lay your hand flat on a table and tap the table with each finger individually, while keeping the others touching the table. You will find that it is much harder to tap with the ring finger than with any other finger. And so when typing, rolling from the pinky to the middle finger, it is very hand to exclude the ring finger from that motion.
I also felt it important to optimise for the common bigrams involving H – ‘HE’, ‘HA’ and ‘HI’. ‘HE’ is the second most common bigram in English, and all three are in the top 20. I wanted to avoid any of these being pinky -> middle finger rolls, and this led to the odd position of the H key in the final layout. It does mean that ‘HI’ is now an outwards roll, but this is the least common of the three, and a comfortable outwards roll is better than a pinky -> middle finger inwards roll. ‘HI’ is now ring finger -> pinky, the most comfortable outwards roll in my experience.
After a few more minor tweaks to the inner columns and the bottom row, Kaehi was born.
Here are some stats for the final layout. The top 50 bigrams in English account for 54.96% of bigram frequency. On this layout, 10 out of the top 50 bigrams are inward rolls, and these account for 11.95% of all bigram frequency. None of the top 50 bigrams are typed with a single finger, unless you count ‘LL’. Only one of the top 50 bigrams is an outwards roll (‘HI’), 0.76% of bigram frequency. It is worth mentioning that this single outwards roll is actually the result of my manual fine-tuning, and not the work of the algorithm. The algorithm very much wanted the H key under the pinky, but I would much rather have the less common ‘HI’ bigram (0.76%) be a decent outwards roll, than have the very common ‘HE’ bigram (3.07%) be a very uncomfortable pinky->ring finger inwards roll.
19 keys are moved from their QWERTY positions, with 4 keys swapping hands. Finger travel distance is roughly halved compared to QWERTY (about 52% of QWERTY, depending on how you measure it).
As a sanity test I consulted an online layout analyser created by Patrick Gillespie. I do not know the exact metrics used, but it rates Kaehi highly –
So I guess I should answer the obvious questions.
Q: Why not just use Colemak?
A: Colemak is very impressive on one metric – single finger bigrams. It has a letters-only single finger bigram rate of 1.064%, I found the lowest possible while retaining the ZXCV positions to be 0.805%, so colemak is not far off. Very impressive for the relatively low number of changes it makes from QWERTY. Unfortunately I did try it for a while and simply found it uncomfortable. The common “he” and “hi” bigrams I found particularly unpleasant, being outward rolls that also involve reaching to the inner-most column. It sports a fairly equal ratio of outward rolls to inward rolls, whereas I prefer to maximise inward rolls and minimise outward rolls. Here are the stats for Colemak –
Q: Colemak mod-DH then?
A: I think the theory behind this colemak variant is sound, and I feel that it is a straight up improvement over vanilla colemak, but it does not address my specific issues – the “he” bigram is not much more comfortable, for instance. It also breaks up the ZXCV cluster.
Q: Why not just use Dvorak?
A: Ew, no.
Q: Why not just use [other layout]
A: All other layouts I have seen have some combination of undesirable properties. Norman is hardly any better than QWERTY. MTGAP is pretty radical and hard to learn, for seemingly minimal benefits. Workman has higher outward rolls and single finger bigrams than I would like.
Q: So, how is this layout working out for you?
A: I have been using it for almost two months, and while I am not up to speed with it yet, there are no glaring issues jumping out to me like there were with the other layouts I have tried. Is it absolutely optimal? Probably not, but I think any possible improvements would suffer greatly from the law of diminishing returns. Given that, I absolutely plan to stick with it for the long term. If you try it out yourself, or have any kind of feedback, I would be very interested to hear it!
6 thoughts on “The Kaehi Keyboard Layout”
Is it possible to get the program that you created to make the Kaehi keyboard layout. I left QWERTY went to Dvorak, then thought there has to be something better. I like the Kaehi layout and the reasoning behind the design inward rolls etc. I would like to use the program to come up with a design that keeps the A either in it’s original position or near by to make cntrl A easy to hit. Thank you for your time and thank you for sharing your keyboard layout. Hope you have a great day.
Hi Todd, thanks for reading! I don’t mind sharing my code, but it’s very messy and you’ll need to know C++ to get much use out of it. As it happens, I did investigate layouts keeping the A in place way back when. Here is the best layout I found –
Q W L D G J P O U
A R S T M K N E H I
Z X C V B Y F
The trade-offs here are that you get much more outward rolls – 14% vs 7% for kaehi, but also more inward rolls – 22% vs 19% for kaehi. As soon as you put the A on the left hand, you get less hand alternation (probably good), but more outward rolls (bad). With the above layout you can move D,G,M,B,J,P,K,Y,F around according to preference, as long as they stay on the same hand/finger. Let me know if you try it out!
Hi, I recently discovered your blog here researching alternative keyboard layouts and really liked the principles you put into finding the kaehi layout. I’ve been trying to use it as a basis for a layout the carries out most of the same principles but minimizes middle two row usage on an ortholinear keyboard, but I’m thinking this is probably a challenge that would best be started with a search under these parameters as you did to find kaehi itself. If you could publish the code used or provide any ideas or insights you have that’d be greatly appreciated!
Hey, thanks for reading! I’m happy to share the code with you directly if you’d like, but I’m not too keen to publish it publicly. It’s very messy and poorly commented as I never intended to share it. If you’d still like it, let me know and I will email it to you. I haven’t tried an ortholinear keyboard before, but I would imagine the same principles apply. The inner rows on the KAEHI layout are already some of the least used keys, as I found the heavy middle row usage on colemak pretty unpleasant. The only way to reduce it any further is to break up the ZXCV cluster, and even then it would be pretty marginal gains.
I’d love to take a look at your code. I’ve given up on keeping the zxcv cluster at this point, and will likely just be accessing zxqj with key combos, and zxcv shortcuts on a layer, since I’m aiming to make a keyboard with 3 keys per finger including the thumbs, but want to make a layout that makes sense for that.
Huh, ok that’s pretty different. Sounds interesting, but I’d really recommend against having any characters on a layer or key combo, as I imagine that would make pressing shift or control+ that character a nightmare. I think it would slow down typing as well. But good luck!