Miryoku, and Really Small Keyboards

Mechanical keyboards these days have computers in them which can be used to program non-trivial behaviors. You can configure a key to do one thing when tapped, another when held, another when double-tapped, yet another when double- tapped and held; the list goes on. You can assign macros to keys. You can define combos, such that when two (or more) keys are pressed at the same time, you get something else – like CTRL-ALT-DEL, only you can set anything with any combination. One of these features is layers, where a key switches the keyboard layout to something else. Again, since this is programmable there are a variety of ways of switching layers: temporary toggles which like shift only switch while you’re holding down a key; layer switches, which switch the layer until you do something to switch it back, and so on.

This is really powerful. It lets you do more with less, and it lets you fix some of the shortcomings of standard keyboards. For example, the pinky finger – used for common functions such as shift, carriage returns, and tabs – is a weak finger and especially prone to RSI. Meanwhile, the strongest finger – the thumb – is usually relegated to pressing the space bar. Two of your most powerful and durable fingers only ever press the space bar. It’s really quite a bad design, and while layouts like Dvorak and Colemak address the inefficiencies of the QWERTY layout by maximizing the most common (English) letters under the home row so that you don’t have to stretch your fingers into such contortions quite so much, they’ve mainly been limited by the standard keyboard hardware, which still only has one long bar for the space bar, and which is really the only key your thumbs can conveniently get to.

With the advent of home fabrication, this situation has changed dramatically over the past decade. You can now get keyboards in a bewildering array of designs and layouts. Two of the most common are fixing the terrible ergonomics of row stagger for column stagger, and putting more keys under the thumbs. Another almost ubiquitous change has been heavy utilization of the programmability of keyboards.

If you learned to touch type, or if you have ever worked as an accountant or any job accountant-adjacent, you probably learned 10-key number pad typing. I worked for a year in college doing data entry, and it was 8 hours a day of 10-key entry, and it’s incredible just how fast you can get at typing out numbers. It’s a great thing to have, and if you have ever done 10-key entry, having a number row at the top of a keyboard is almost an insulting and painful user experience. A dedicated 10-key pad is a lot of valuable real estate that often competes with the mouse, and fewer and fewer keyboards include one now. The mechanical, programmable keyboard has a fix though, and it’s even better than a dedicated 10-key: you just define a layer where the keys under your right hand become a 10-key keypad. Since 10-key is a 1-hand typing experience, you can assign any key on the (commonly) left side, and while you’re holding it you have a 10-key keypad without ever moving your hands off the keyboard.

It’s hard to explain just how fantastic this is unless you’ve experienced it. It’s so useful that I use software called kanata to add this functionality to dumb keyboards. There are other, similar programs, like kmonad, but kanata has the fewest limitations and has the most POLS defaults I’ve encountered.

Now, this all has led to a minimalist movement within the mechanical keyboard community. I fell into this, opting eventually for a Piantor Pro, which has 42 keys:

It’s small, but I’d had enough experience by then to know I didn’t want to go to extremes, like this 36 key Corne:

[Credit: https://absolutepcbassembly.com/what-is-corne-pcb/]{.marginnote}

The home layer on this is going to be[In general; who knows how any given person is going to program their keyboard?]{.marginnote} your normal alphabet. To get numbers, you have a layer switch. To get punctuation, you have a different layer switch. To get arrow keys, page up, page down, Home, Insert, Delete, Backspace, Print, mouse movement and mouse buttons, function keys… all of that stuff, you have layers. Almost everyone with a programmable keyboard – most of them use firmware from a project called QMK – has some layer functionality. On my 42, I’ve kept the shift and tab keys where they normally are, because that’s how I learned to type. I put the Enter key undor one thumb, and space under another, and I have 9 layers defined for various things: one for window management for jumping between windows and desktops, one for tmux control sequences, one for my number pad and another for punctuation, and a layer that just switches to a QWERTY keyboard because trying to remap the entire Factorio keymap configuration is insane. To play Factorio, I load it up, hit both shift keys at the same time, and I have a standard QWERTY keyboard. Hit those shifts again and I’m back to Dvorak.

Ok, so now we get to Miryoku, and something important I’ve discovered about layouts. A user (or organization?) called Manna Harbour created a “universal” keyboard layout called Miryoku. It’s mainly targetted at programmable keyboards, but it can generate configs for kmonad and such. What attracted me to this is that it does two things diffently than I do: first, it’s based on a 36-key keyboard, so the extra 12 keys on my Piantor would be unused, or bind-able to other things. Second, while I have my layer switches under my left-hand home row, Miryoku puts them under the thumbs… which makes a lot of sense. Third, it has all the modifier keys – the GUI (the Windows/Apple key), shift, control, and alt keys – under both the left and right side base layer. Which is kind of fantastic: with my layout, I get left and right shift and control, but the alt keys are sort of wonky, and shift/ctrl are still under the pinkies, like I learned in touch typing class 40 years ago. I was interested in reducing how much I used my pinkies, and Miryoku does this. So I tried it.

I’ll preface that I’m a reasonably fast typist. Not world-class, but when I get going I can get over 80wpm, and those speeds[In my case, at least]{.marginnote} there’s a lot of rolling keypresses: I don’t always let up on a key before I press the next one. what I discovered with Miryoku is that despite there being a setting specifically for rolling keys, I was regularly either accidentally triggering a modifier combination (“uninvited” would come out “Ninvited”), or more commonly, keys would be dropped. In typing tests, my error rate went way up, and because I’m a correct-as-you-go, my typing speed went way down. Even if I did not try to correct, when a key would get swallowed the next three words would be incorrectly typed: if you try to type “the quick brown fox” and the space between “the” and “quick” gets missed by the keyboard, everything after “the” is wrong in the test.

The second thing is that Miryoku was clearly designed by someone who never took typing classes, or did much 10-key typing, because the 10-key layer is located under the left hand, by default. The arrow keys, similarly, are designed afer cheap keyboards with the keys in a row up-down-left-right, rather than in an inverted T as on larger and more traditional layouts. The project has configuration options to address both of these, but the third issue is that they project doesn’t support the increasingly popular Via/Vial QMK format, so you have to manually create your configuration if you use Vial and want to try Miryoku.

But the real blocker with Miryoku, and probably with any layout that puts modifier keys under the home row, is that it’s going to impact your typing speed. Either you configure a long delay to avoid rolling issues, or when you do want to shift, you have an unacceptable lag before you can completely type the capitalized character. With the layer switches under the home row, the delay is less important: on a 42-key keyboard, I can have common punctuation (;:.,!?) on the base layer or accessable via a modifier key, and all layer shifts can have an acceptable delay: a small lag in switching windows in my window manager does not affect my typing speed, whereas a lag to get a period or comma will.

Miryoku taught me an important lesson: that it’s not a good idea to put modifier keys on standard language keys, like the alphabet, and the space key. There is such a thing as “too small”, at least for me, and the extra keys are necessary to avoid those rolling conflicts. By far the worst was the space bar, but I also had a few moments where I accidentally triggered a window management binding because the keyboard sent “LGUI-t” instead of “at”, and I have “LGUI-t” bound in the window manager to execute a sequence of typing out 40 characters.

After trying variations, including removing everything I could from the home row and putting the layer switches under the thumbs like Miryoku, that space bar issue kept biting me; and with only 6 thumb keys and 9 layers, taking a layer switch away from one of them is a real handicap. So I’m back to my original layout, with the layer switches under the left-hand home row with reasonable delays that mean I never accidentally trigger them, and every key that I might want to type quickly on the base layer.

Sometimes, what you have is good enough, and even a compelling theory turns out to be not very good in practice.