For years I'm very frustrated with the standard qwerty layout while doing heavy C-programming. The right pinky is used about 30% of the time and it is impossible for me to keep up strict touch typing. Some years ago I tried to solve it learning dvorak. It went quite well, but didn't really mitigate the problems when programming C. Since then I keep having an eye on new layouts.
While I'm sure colemak is great for regular text, it doesn't help when programming. The only solution seem to be to introduce more modifier keys, but I don't like the idea.
When the idea of wide layouts came up, I decided to create my own layout targeted for programming.
I tried several of the existing layout optimization programs, but none of them could fully handle relocation of the special characters. So another layout optimizing project started ;)
My goal was to fully model the usage of the shift keys, to have a real measure of the costs for special characters. At first, I imitated the existing cost functions like same finger, same hand, row jump, ..., but they had too many parameters for me.
My approach is a bit different: I measured the hands and how far every finger can reach in every direction. Also I measured the key distances on my cherry keyboard. The model now fully track hand positions, hand angles, finger positions and finger angles and the cost is mainly attached to the movements of the fingers and the hands, finger and hand exhaustion be repetition etc. Also there is a penalty on hand change. To get the cost of a specific layout, the full corpus is fed into the cost function and normalized afterwards. That way I hope to get a more accurate cost, especially because it really takes the cost of shift into account, depending on the current hand positions.
Of course this cost function is much too expensive to calculate it millions of times during the optimization process, so I tried to approximate it by using quad-grams. It only feeds the 99%-quantile of the quad-grams from the corpus, about 300.000. The error of this approximation is about 10%, but the relation to the real costs stay nearly constant, so I deemed it good enough.
As corpus I took large chunks of the linux kernel, the corpus carpalx uses and tons of perl sources.
During the coding process, someone pointed me to the upcoming TrulyErgonomic keyboard. I fell in loves with it on first sight and now eagerly await its appearance. My initial plan as stated above was to optimize for a wide layout, but a wide layout wouldn't make much sense on the TrulyErgonomic, so I stuck with the regular (narrow) hand position to make the transfer to the TrulyErgonomic easier.
But enough of this length introduction, this is the result:
% + < > / \ [ ] " . ! z ^
& l o u , @ d p _ x q j
n r e i ; k t s a c b v
h ( ) y = w m f - g
? | 2 3 4 5 6 7 8 9 ~ Z `
# L O U 0 1 D P * X Q J
N R E I $ K T S A C B V
H { } Y ' W M F : G At first sight it looks a bit crowded, but when using it, the feeling quickly goes away. Nevertheless I'm still not sure what to think about it. I'm learning it in my spare time now, and there are lots of rolls in there that feel nice, but it also alternates a lot. I tried to model the cost to prefer small roles followed by a hand change.
I find it surprisingly easy to learn, but it takes time to pick up some speed on it.
Hopefully some of you also pick up on this :)
