Neon Vagabond Sitemap Index About the Author Cyberpunk Archive Mirror

Category: Input Devices

Table of Contents

1. Why I Prefer Keyboard-Driven Interfaces

This is not a controversial position to take, I think among the computer programming set. However, I think it deserves a little more of a centralized, rigorous defense, instead of the general appeal to "common sense" and preferences that usually happens. Especially in response to some critiques of this preference which I'm going to respond below.

I prefer keyboard-driven interfaces to mouse-driven interfaces for three predominant reasons.

1.1. Throughput

Imagine that instead of having a keyboard to enter text, you're forced to use a point and click onscreen keyboard with your mouse. Now imagine that you have to write this essay.

It's excruciating, right?

At best you'll probably be able to get around 20 wpm out of it (I got 18 when I tried this experiment, and that was with me clicking my heart out trying to go as fast as I could), compared to the vast majority of workers that get more than that, often double or more (I can get 130 on my best day, and 110 on average).

This illustrates just one of the reasons that I prefer keyboard-driven interfaces to mouse-driven ones: keyboards are inherently higher throughput devices than mice are.

To think about throughput of input devices a little more rigorously, if you have a point-and-click interface, you can supply about 24 bits of information at a time by clicking, assuming X,Y coordinates and a 4K screen or assemblage of screens that add up to 4K. Since I can click about 96 targets in about 60 seconds across my quad-HD monitor going as fast as I possibly can to a stressful and strenuous degree, that comes out to around 37 bits of information per second. Meanwhile, each key on the keyboard conveys around 8 bits of information – assuming ASCII, a lot more if we include compose keys or alternative shifting configurations like the Space Cadet had – and let's say that an English word is on average five keys long. Since I can currently type around 130 words per minute if I go all out, that comes out to around 86 bits per second of throughput. Around double!1

That's because, on a keyboard, I have around 80 buttons all within easy reach of my fingers, at much shorter distances than one typically has to move the mouse to reach a button (unless you've turned up your mouse speed so high accuracy is probably significantly sacrificed). It's also because my fingers are much more dexterous and fast than my shoulder, elbow, or even wrist, which are typically what you use to direct a mouse. Additionally, when I'm using a keyboard, I'm able to use all ten fingers at once, allowing me to, for instance, parallelize my button entry, preparing one finger to type a character while the previous finger is typing its character, sort of like processor instruction pipelining, or even enter multiple keys simultaneously (for key chords) thus massively increasing the bit value of my key entry. Whereas, in comparison, the mouse essentially turns your entire arm into one single appendage with perhaps five digits at most, usually only two or three, and those digits can't be used to speed up pointing, only for determining the actions you do when you get there.

Thus you can't really get better at point-and-click: typing speed with the onscreen keyboard, for instance, is monumentally dominated by intrinsic factors like simply how long it takes to move your entire shoulder and arm (since that requires course-grained motor skills and moving a lot of mass, relatively speaking), the distance you have to move your mouse to get from one key to another. Meanwhile, with all the keys a mere (usually small) finger movement away, the biggest hurdle is your dexterity and reaction time (and ability to spell).

Of course, the natural objection here would be that we're not comparing like-for-like: we're not using mice for what they're best at, instead we're using them to emulate keyboards. That's not really true if you think about it, though – we're using mice here for exactly what they're meant to do: activating buttons on the screen in a point-and-click fashion in order to achieve a certain behavior. We're just using them for a task where higher throughput is expected and traditional (text entry) instead of a task where people have learned, thanks to a historical accident of interface design, to expect slower throughput communication with your computer (point-and-click GUIs). Mice aren't really out of their element here, it's just that we typically have higher expectations for text entry compared to other aspects of our user interface, so it feels more like mice are out of their element because you know what you're giving up. If you were someone that's used to using Emacs interfaces like Magit or Dired, you'd feel just as frustrated and slowed down moving from that to a point-and-click GUI as you feel trying to use a point-and-click onscreen keyboard instead of a real one.

1.2. Tactile Feedback and Location Invariance

Another thing is that when you're trying to click buttons on the keyboard (assuming that each key on your keyboard corresponds to some functionality in your application, either directly as in Emacs special-mode interfaces or transients/hydras, or with a modifier key as in most applications) you always know exactly where each button is, and your hands are always in the same position (the home row) relative to those buttons, and there's tactile feedback when you're in the right homing row location, and tactile feedback for the layout and separation of the buttons, and for when they've been activated. Thus, if you know what buttons to press, you can very easily do it with very little mental attention at all, even blind or looking at something else. This location invariance and tactile feedback also makes it a lot easier to encode keybindings into muscle memory practically without trying.

This is excruciatingly difficult to do with a mouse. You always have to figure out where you are (searching for that cursor does take time, even for the best-sighted of us), then looking around for where you need to go, and then and only then can you go there, and there's absolutely no tactile feedback for getting there or successfully clicking the button when you do. By involving your vision, this takes a lot more of your attention and processing power, and by lacking tactile feedback, it's much more difficult to encode into your muscle memory. You can get rid of having to wonder where the buttons you want are if you always fullscreen a certain application, put buttons always in the corners of the screen, and always perfectly adjust your mouse to the screen size of whatever device you're on, so the distances you have to move your mouse always stay the same, but even then it will be a lot harder simply for the fact that there's no tactile feedback, and it'd also be really difficult to achieve this kind of consistency with a point-and-click interface embedded into a multitasking operating system and window manager.

There's of course the added wrinkle here that you can press a wrong key on the keyboard, so the identity between pressing a key and successfully performing a certain action isn't perfect, but I would argue that since you have an array of keys that usually have certain meanings, and you can reliably at least press them, that's closer than a single button which changes meaning based on much more fine-grained screen locations, and which you can't reliably move to a given location to give it a certain meaning.

1.3. Convenience

This is an obvious one, so I won't spend a lot of time on it. If your job or hobby involves a lot of typing, then your hands are already on the keyboard in order to do that, so keyboard-focused interfaces are a lot more efficient, because instead of having to pick your right or left hand up of the keyboard and put it on the mouse – and involve a fast, but still subconsciously noticeable, mental context switch from keyboarding to mousing – to operate your user interface when you're in the middle of entering text, you can just manipulate your interface "inline."

1.4. Memorizability

One of the most common quotes trotted out by opponents of the idea that keyboard-focused interfaces are superior to mouse-focused ones is this one from "Keyboard vs. The Mouse, pt. 1" on Ask Tog:

We’ve done a cool $50 million of R & D on the Apple Human Interface. We discovered, among other things, two pertinent facts:

  • Test subjects consistently report that keyboarding is faster than mousing.
  • The stopwatch consistently proves mousing is faster than keyboarding.

This contradiction between user-experience and reality apparently forms the basis for many user/developers’ belief that the keyboard is faster.

People new to the mouse find the process of acquiring it every time they want to do anything other than type to be incredibly time-wasting. And therein lies the very advantage of the mouse: it is boring to find it because the two-second search does not require high-level cognitive engagement.

It takes two seconds to decide upon which special-function key to press. Deciding among abstract symbols is a high-level cognitive function. Not only is this decision not boring, the user actually experiences amnesia! Real amnesia! The time-slice spent making the decision simply ceases to exist.

While the keyboard users in this case feels as though they have gained two seconds over the mouse users, the opposite is really the case. Because while the keyboard users have been engaged in a process so fascinating that they have experienced amnesia, the mouse users have been so disengaged that they have been able to continue thinking about the task they are trying to accomplish. They have not had to set their task aside to think about or remember abstract symbols.

Hence, users achieve a significant productivity increase with the mouse in spite of their subjective experience.

There are a number of problems with this quote. Let's set aside the fact that Tog here is conceitedly referencing a study which we have no access to in order to determine its sample size, methods, or other crucial aspects, seemingly believing that the price tag involved in a study is somehow, some way, an indicator of quality. Let's also choose to ignore the fact that this study was done by a company that had a vested interest in winning over the last hard-core keyboard users because every user convinced that the mouse was superior to the keyboard was a user that was purchasing their ten-thousand dollar machines.

The first key problem is that I find it inherently unlikely for someone who's sufficiently familiar with the keybindings of an application to take longer to remember that keybinding and then use the much faster (as we've seen in the previous sections) input method of the keyboard to enter it, than the person who has to visually find the location of the button, move their whole hand off the keyboard, move the mouse to the button, click, then put their hand back on the keyboard again. That's simply painful. Even someone that's not currently typing still has to move the mouse a lot farther, using their arm and shoulder, than they'd have to move their much faster and more dexterous fingers to reach a key, and they've still got to look and see the position of the button (and recall where to look for it) because there's no tactile feedback for GUI buttons the way there is for keyboard shortcuts. Memory is extremely fast, when you're familiar with the thing in question. Hell, in the case of a lot of keybindings there's exactly zero memory involved once you've been using an application long enough – it's pure muscle memory, it happens by reflex.

Which leads me to the core of the problem here: Tog is probably comparing someone who's unfamiliar with the specific keybindings of an application with someone who's equally unfamiliar with its GUI (which would make sense from a naive scientific perspective, and from the perspective that whatever software he actually had them use in the experiment was new to them, since GUI software was just very new in the world at the time and Macintoshes were too expensive for many people to have had them). If he'd actually shared the in-depth data of the study he did, instead of just high-handedly referencing it, of course, we could have checked, and perhaps this assumption would've turned out to be wrong, but given what I've just said I think it's a justified assumption. This means that he's measuring just the start of the skill curve of using an application, not where it will go over time, and generalizing that to everyone. That means what he's essentially measuring isn't a difference of inherent efficiency, but a difference in discoverability and learning curve. And that's absolutely fair – it's much easier to discover and remember the functionality of your average GUI application than it is to discover and remember the functionality of one that relies on largely invisible keyboard shortcuts.

The thing is, though, that this can be remedied. Consider, for instance, the humble Emacs help quick toggle menu:

emacs4.png

This transforms the need to remember an arbitrary key command into the need to visually find the key command, which puts it on an equal playing field with a GUI button, putting – in my opinion – keyboard shortcuts already on a mostly level playing field with button presses.

This isn't even close to the end of the toolkit we have at our disposal to make text-based interfaces even faster and more discoverable, either. We also have icomplete-vertical (and similar things) in Emacs:

emacs5.png

Which offers real time fuzzy searching and narrowing of generally intuitively named commands, instead of the cryptic mnemonics of keyboard shortcuts (which it can also show you in case they're faster). With things like orderless, you don't even have to recall the specific order a set of words or subwords appears in a command name – just throw in the first few letters of a couple keywords and you'll probably find it. This style of interface may require typing a few more characters than a key chord, but this interface makes it far easier to discover and remember a much wider variety of commands than the Emacs quick help, and doesn't require pressing complicated modifier key operations, which can be a real slowdown. It can also represent far more commands than a tool bar or action bar ever could, which means it's more directly comparable to point-and-click interfaces like menu bars, which take a massive amount of time to navigate because they're hierarchical, so you have to guess how things have been organized in categories, instead of being able to look for the thing you want directly (and search features for things named in text inherently rely on keyboarding).

And then there's things like the Casual Suite:

https://github.com/kickingvegas/casual/blob/main/docs/editkit.org

and Magit:

magit-help-popup.png

Transient interfaces can lend the discoverability of GUI applications to keyboard-focused user interfaces, while also maximizing the efficiency of keyboard-based interfaces by eschewing modifier keys in favor of a modal interface that requires on instant single key-presses.

Thus I think the idea that keyboard-based user interfaces are somehow inherently worse at discoverability or recall just comes from a failure of imagination.

1.5. Pointing

What about the "pointing" part of pointing-and-clicking. Surely, surely, mice must be better at this? Right?

Wrong.

This intuition is borne out of the fact that most keyboard-focused user interfaces don't provide good primitives for jumping to specific locations on the screen. They'll often provide the arrow keys, or something equivalent, perhaps a few more motions that move by some larger increments – but all of these options ultimately have one flaw: they require you to move linearly through whatever content or interface you're looking at to find what you want, just in larger or smaller jumps. Even search falls into this: if you've got more than one result on a page, you're going to find yourself moving linearly through a list of results trying to get to the one you actually want, even if you're making some possibly large jumps in the process. It's all O(N) operations, whereas the mouse, more or less, is an O(1) operation. It may take it some time to move somewhere, but it doesn't have to move linearly through a bunch of other content in the way text does. It's also much easier to move the mouse linearly a certain distance than it is to move a cursor that same distance via the arrow keys, because keyboards have a fixed repeat rate that's a lot slower than the refresh rate of the mouse.

However, there are better ways to jump quickly to something. Consider the avy approach, allowing you to say what you want to jump to (a character or string or window) and then instantly jump to it anywhere on the screen within O(log26(N)) keystrokes, then perform any action on whatever was at that location. This article has more details on advanced usage, but here's a simple demonstration of its capabilities:

This can be very advantageously used to navigate even interfaces as complex as browsers, just by attaching each interface element with a letter in a tree of letters the way avy does characters that match your search:

1.6. So what is the mouse good for then?

There is exactly one circumstance where the mouse's throughput is higher than the keyboard's: when you're dragging, not between two points, which can easily be expressed with a jump, but dragging or otherwise in an interface where the intermediate positions of the mouse matter. In that situation, you've got hundreds of 24 bit values being output each second, according to your mouse's refresh rate, and each one of them matters and makes a difference. Some examples of this kind of situation are:

  • playing FPS games
  • drawing
  • animating
  • rearranging your view in something like Blender

There are probably dozens more, too, that I'm just not thinking of at the moment.

The thing, though, is that these situations just… aren't that common. They're niche hobbies or professions, usually best served by a different input device than a mouse, like a 3D joystick, or a pen.

1.7. So why do I still use the mouse for things?

Sometimes context switching (going from content production to browsing), or picking my hand up from the keyboard, is just kind of nice. It resets my brain, lets my hands do something different for awhile. Given all the above you might think I'm advocating for an all-keyboard-all-the-time interface paradigm and I'm here to tell you that's not true at all. Efficiency is not the only thing that matters, there are other values. Some people can't type very fast, or can't touch type at all, so there's little difference for them. There may be some inherent discoverability benefits to GUIs I didn't think of, as well. And some people may just have a preference for an input method that's a little less efficient, sure, but that they like better – and honestly, that's an absolutely fair tradeoff; it's not like I don't make it rather frequently!

2. You need a split ergonomic mechanical keyboard

If your primary job, hobby, or both involves typing, you need an ergonomic keyboard. Period.

Traditional keyboards were not designed with humane ergonomics in mind. They were designed around the technical constraints of 19th century typewriters, and then that layout was ported forward and forward until we've now ended up with a miniature version of it on our damn smartphones. There are many inherent design flaws in the traditional keyboard, but here are a few:

  • keys are all arranged into one single central group and designed to be typed on in a vertical fashion, instead of the keyboard being split into two halves and rotated outward to meet the user's arms naturally, leading to typists' wrists being crammed together and oriented straight up and down, which causes ulnar deviation;
  • keys are also row-staggered, forcing your fingers to travel along strange diagonal paths alien to how your fingers naturally extend when curling and uncurling them, instead of keys being arranged in columns so that your fingers only need to move in straight lines, or even columns that naturally splay out from where your palms are, in keeping with the most relaxed angle of finger extension;
  • keys along the left and right edges are extended to make them slightly easier to reach, but otherwise the keyboard makes absolutely no accommodations for the natural variations in length and dexterity of human fingers, such as making keys at the top of the keyboard that may be hard to reach taller, or using an (entirely non-existent in traditional keyboards) columnar layout to stagger the columns according to relative finger length;
  • instead of using the thumb, which is the strongest finger on the human hand, and the one that is used to holding things down for long periods of time, for things like control, alt, and shift, that burden is instead placed on the weakest finger on the human hand, and the one that is most likely to cause nerve issues (due to its connection with the carpal tunnel), the pinky;
  • most modern keyboards require you to press keys all the way, slamming your fingers into the backboard over and over, instead of registering about halfway through the key's travel.

If you spend hours a day, almost every day, furiously using a device that was fundamentally not designed for ergonomic human interaction, with your most complex and fragile appendages, it is only a matter of when, not if, you will run into physical problems. A lot of us writers, programmers, and others that spend all their time in cyberspace or imaginary space all day tend to forget this, but we're physical human beings too (unfortunately). We have bodies and, even if we have it easy compared to, say, construction workers, those bodies are subject to physical wear and tear of our day to day jobs (or hobbies), just like everyone else. In this case, that wear and tear is predominantly centered around our human-computer interface system, broadly conceived: the mouse, keyboard, chair, desk, monitor. Desk and monitor ergonomics can do a lot for your back and neck, and mouse ergonomics can help a little with one wrist, but paying attention to all of that and completely ignoring one of your main human-computer interface devices, the keyboard, is like leaving a giant sinkhole in the middle of your otherwise sparkling-clean living room.

At first the problems you eventually do run into with your wrists and fingers as a result of keyboarding all day will seem minor – sure you've got a little pain, aching, numbness, or tingling but the pain quickly goes away and you can get back to work, right? But this doesn't last. Maybe it will for a year, five years, even ten, but don't you want to be able to do the work or hobbies you love much longer than that, maybe even your whole life? You can't get away with ignoring your body forever, and that damage, that strain, that wear and tear, those warning signs – they add up over time.

If you don't treat the root cause of the symptoms, the carpal tunnel and tendonitis will begin to become chronic, an ever tightening vicious cycle of irritation and pain that leads to more irritation and eventually outright damage, and eventually you'll be faced with full-on repetitive strain injury, which does not heal. Once you have RSI, short of getting a surgery that costs tens of thousands of dollars and isn't guaranteed to do anything for you at all, your body can't heal it. The damage is too minute and fine-grained for it to deal with. So you'll just have to accept that crippling pain and numbness and weakness for the rest of your life at that point.

This means that you really can't approach this problem with a cavalier "I'll cross that bridge when I come to it" attitude. Sure you might be one of the, say, 30% of people who are lucky, whose bodies are just somehow so resilient and flexible, or whose psychology just naturally makes it easy (or even effortless) to regularly take breaks, but once you've gotten to the bridge, it's far too late to actually deal with it then, so why take risks? Why not use a little prophylaxis?

Preserve your body now, so that you can enjoy having it in your old age.

How do you go about preserving your body, though? Breaks that are only long enough to treat the symptoms – stopping for a second to take a breather, stretching your wrists, cracking your knuckles, and so on – don't actually deal with the underlying wear and tear that your body is warning you about. The only way to actually deal with those issues properly is to consistently take pretty long breaks, something on the order of thirty minutes to an hour, regularly, and that's difficult to keep up with any consistency: obviously, it's easy to forget to do it, even in response to pain symptoms, or constantly give excuses to never do it, and timer based approaches to solving that won't work well for many jobs that involve a lot of keyboarding, such as programming or writing, which tend to also involve a flow state that's extremely important to maintain. Moreover it's well known at this point that willpower-based approaches to habits and routines and things you need to do simply don't work very well.

This is why, in my opinion, everyone that primarily works with a keyboard needs to spend some time picking out an ergonomic (preferably mechanical) keyboard that works for them. The properties you want to look for are:

  1. Split, rotated layout, so that your wrists can be straight in line with your arms;
  2. Column-staggered keys, preferably with splay;
  3. Tenting capabilities if possible;
  4. Mechanical keys, to avoid having to slam your fingers into the back of the keyboard.
  5. Key sizes that have been adjusted to account for finger length and key position.

3. Key arpeggios versus key chords

It is my strong opinion that arpeggiated key bindings – key bindings where you press multiple single, un-modified keys in a sequence, as you would in things like Emacs god-mode or Vim – are vastly superior, ergonomically, to key chords – like you would use in traditional GUI applications, or in vanilla Emacs. This is for a few reasons.

  1. Having to hold a key down for an extended period of time is inherently more stressful and straining than just hitting it once, just like having to stand holding a heavy box for a long period of time is much more difficult than only having to pick it up briefly.
  2. Having to hold a key down while hitting another key requires more effort even than holding down either by itself, since muscular strain is not additive but something like multiplicative.
  3. Having to hold a key down and then hit another key (or hit two keys at the same time, which also brings in a timing and coordination difficulty) invariably leads to you having to stretch and contort your fingers and wrists – and thus the tendons inside them – to varying degrees in order to reach both keys at once. This gets more difficult nonlinearly with the amount of modifier keys required, while key arpeggios require constant effort no matter how complex the grammar of modifications becomes.

One might be tempted to bring out the stenographer's keyboard as a counterexample to my statements, but that's not so. The stenographer's keyboard reaches its level of efficiency and ergonomics not primarily from using the human body in a more ergonomic way, but by simply allowing you to get more across with a single key chord, therefore becoming significantly more efficient. Moreover, a proper stenographic keyboard is also laid out in a completely different way (as a piano-like double row of elongated keys) that makes doing chords not really require holding down keys at all!

4. Low-key keyboards are a fad

When I realized that I needed a split ergonomic mechanical keyboard, I dove deep into the space, searching for something that could work for me. I quickly found the ZSA family of keyboards, but they were completely outside my budget. I also ran into the Kinesis Advantage and Advantage360, but not only were they also completely outside my budget, I also didn't like the straight up and down wrist angle of the Advantage, and the thick, tall design of the 360, nor the thumb cluster design that looked awkward to reach, and I didn't want to lock myself into proprietary firmware for programming the keyboard either, since I had wonderfully baroque ideas for what I wanted to do.

As my search deepened, I soon found myself immersed in the world of DIY ergonomic split keyboards. Generally, the ideas and design principles of this space were good, centered around rectifying very real and pertinent design flaws in traditional keyboards through such things as splitting, tenting, column-staggered key layouts, splayed key columns, low-profile housings, and mechanical key switches.

The space was not free from its share of blind trend-following and folk wisdom, however. One of the most baffling examples of this was the single-minded focus of the whole community at large on something which I can only call keyboard minimalism: the endless desire to seek the absolute minimum number of keys they could get away with on their keyboard designs, and the general dismissal of designs with more keys through the assumption that everyone, eventually, would ultimately move toward keyboards with a smaller number of keys over time, as those were just obviously superior.

You can see this thinking in the fact that nearly every relatively mainstream, well-known, often-recommended DIY split ergonomic keyboard design has very few keys. While a standard keyboard has anywhere from 90 to 104 keys, the average DIY split ergomech keyboard, like the popular accessible starter the Keebio Iris, or the even more popular and highly regarded Sofle design – which in turn was designed based on popular designs with similar key counts like the Lily58 and Helix – seems to have half that, around 58 keys, at a maximum. Many go even lower, too – the very popular and widely regarded as "endgame" (i.e. perfect, if you can adapt to it) Corne keyboard only has 42.

I even spent some time on Compare Split Keyboard looking for a design with enough keys for me – someone who prefers roughly the number of keys and keyboard size of a tenkeyless – and was shocked to find that the orthodox dogma in this community that fewer keys = better was so complete that, out of all of the many hundreds of varied split ergonomic mechanical keyboard designs that list documented, not a one had more than 80 keys. It seemed no one even thought to want this, let alone sit down and design it. Questions on related forums asking about keyboards with more than a mere handful of keys are met with usually one, maybe two, actual options, a suggestion or three to design your own keyboard, and several people simply telling the questioner that they're wrong for wanting more than about 60 keys or fewer.

Apparently it's become received wisdom in these niche circles that using keyboard layers – where you tap or hold a special modifier button that changes the meanings of some or all of the keys on your keyboard, to emulate having more keys – to make up for missing navigation clusters, symbol keys, function keys, modifier keys, and often even number keys, is superior to simply having enough keys on your keyboard for all the basic things you need to do. The argument for this tends to be simple: for the sake of efficiency and minimizing effort/strain, why reach an extra row or column or two for a key, when you could instead hold down a key that's readily available under one of your fingers (perhaps the thumb or index finger) and have the key you want appear under you?

There are several problems with this logic. First of all, there's the problem of how to activate your layers: do you want to toggle the layer on and off with a key tap, in which case you have to remember what layer you're on, since most keyboards don't have a screen or way to communicate with the computer to display what layer you're on, unlike modal editors? Or do you want to treat layers as an additional modifier key, in which case you run into the problem of key arpeggios versus key chords, that being that key chords are inherently difficult and unergonomic? (Doubly so with keys that need to be modified in some other way, such as with the control or shift key, while also being activated by a layer). Moreover, with every layer you add, you're introducing more complexity to keep in mind. Control, Meta, Shift, and Super all introduce their own layers, and now you want to introduce one or two (sometimes up to six) additional layers into the mix that you have to have memorized?

More than that, the number of layers you'll need to use is going to scale with the smallness of your keyboard, but as the number of layers you want to access increases, so too does the number of keys needed to actually access those layers, meaning that as the number of available keys on your keyboard gets more and more cramped, the number of keys that have to be occupied with layer-switching increases. You can try to mitigate this via having keys do different things when you tap on them versus when you hold them, so that they can do double-duty, but now that's just more that you have to remember, and, depending on what keys you choose, inconsistent semantics between keys that repeat when held and keys that activate a layer when held, which, combined with layers changing the meaning of possibly all the other keys on your keyboard, is a recipe for turning your keyboard into a fucking minesweeper game.

More problematic than any of this, though, is the fact that by using layers to regain missing number, symbol, and navigation keys, in addition to the letter keys on the base layer that you have just enough room for, you're essentially converting entering different types of input into entirely separate modes, like on a mobile keyboard, instead of things that you can fluidly move back and forth between. In order to enter something like $variable4, you've now got to switch to your symbol layer for a single symbol, then back to your base layer for the main word, then to your number layer, and then back again so you can type space after it, and good luck typing something like mathematics.

Can this be overcome? Sure, and clearly many people do. But the point I'm making here is that juggling layers isn't cost-free. There's a huge learning curve and a lot of inherent cognitive overhead that is unlikely to be something you can easily encode into muscle memory and not have to worry about anymore, and there are a lot of inherent points of friction even if you do manage to actually turn all this detail into muscle memory.

This has the knock-on effect that you're going to want to try to cram all of your most used keys and symbols onto your base layer, which is a recipe for endless tinkering and adjustment trying to find the optimal layout for your keyboard, tetrising everything into the most awkward and inconsistent positions in an attempt to shove it all in there.

And all for what? Is having to move your finger one less row or column really a big gain compared to having to press (or especially hold) one extra key and keep all the rest of this stuff in your head while you do? In extreme cases, this might be the case (imagine a keyboard with no shift key, just duplicated keys for everything), but in my opinion the advantages of layering only hold when the alternative is often-used keys being shoved out of easy reach of your fingers without having to move your hands. In a situation where all the keys in question are within reach of your fingers anyway, saving your fingers some distance of movement just to add an extra key to hit or extra chord to hold down doesn't seem like a clear win to me.

Just take it from my girlfriend, who initially dismissed my strongly voiced concerns with her purchase of a $160 Keyboardio Atreus (which has only 44 keys), but who – as I'm writing this – I just found out has completely given up on learning to use the keyboard for precisely the reasons above:

The longer I used it, and the more different things I used it for, the more unavoidable the fact was that the limited number of keys was hampering my productivity, primarily due to the necessity to switch back and forth between different layers. My primary beef was with the lack of accessible number keys, which made navigation in my window manager difficult, made inputs that were mixed difficult, and overall the necessity in a lot of the software I used to switch between typing and numbers and game style WASD input makes the limited key set an absolute pain to use. It was bad enough that I came to feel anxious when I was going to have to use the keyboard, and found respite in my T420 laptop keyboard instead. Furthermore, the small number of keys makes placing symbols in quickly memorable positions impossible. So you wind up having to learn a lot more.

Why not avoid bringing all this trouble down on your head by just using a keyboard that has enough keys to put all the letters, symbols, numbers, and navigation keys you need right at your fingertips? I suspect the real answer isn't actually the ergonomic benefits, but the allure of small size, minimalism, and trying to be different. I hope, in a few years, this trend dies down and we see more approaches like that of the Glove80.

5. TODO XBows review: the perfect programmer's keyboard?

The split ergonomic mechanical keyboard that I eventually settled on, after trying out the Keebio Iris and hating it,

Footnotes:

1

The numbers given in this paragraph were based on my own personal results on MonkeyType for typing (with the 50 words setting and English 10k) and this aiming test game set to fullscreen. They're by no means scientific, but they're meant to give you a ballpark estimate of the difference.

This work by Novatorine is licensed under CC BY-SA 4.0