Category: Input Devices

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!¹

And in fact, that's being too charitable – in the vast majority of point-and-click interfaces, each individual pixel that you can theoretically denote with a mouse is not actually a usefully separate piece of information, because clicking pixels is just much too precise of a movement for the mouse. Instead, pixels are grouped into click areas, such as buttons – usually, many hundreds of pixels at a time. So if we were to be more accurate about this, we'd have to divide that 4K total resolution of the average desktop point and click interface into, say, 28px by 100px (which seems reasonable, and is correct according to the Windows Vista guidelines), meaning that there are actually only about 6,000 unique locations that can be denoted in a graphical user interface (and again, this is being very generous with screen sizes). That's only 12 bits of information per click, meaning we get only around 20 bits of information per second with a point and click user interface. That's a tiny fraction – one fourth – of the throughput of a keyboard!

Why?

It'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.

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.

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."

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.

(For another more in depth takedown of Tog's statement here, which goes about it in a more experimental way, check out this.)

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:

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:

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:

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.

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(log₂₆(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:

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, and each individual pixel you're pointing at, or thereabouts, is a unique piece of information. 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.

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!

I did pick up my XBows Knight on eBay for $75, instead of its full ~$300 MSRP, so that may be biasing my opinions with regard to whether it's worth it, but I really don't think so – while many of the XBows's features aren't particularly unique in themselves, they're extremely unique in this combination, and especially with so much thought put in them. Furthermore, I've recommended they keyboard to other friends who've spent the full price, and they have absolutely zero regrets.

The size

As someone with large hands, I find the cramped design of most keyboards – especially keyboards in the DIY split ergonomic mechanical keyboard space, which tend to trend even smaller in the name of "economy of motion" or space savings – actively painful, since I tend to have to scrunch my hands up in ways that are far from relaxed and natural in order to place my fingers on the keys and generally have my motions fit the keyboard. This was especially true in my experience with the Iris. Meanwhile, thanks to design features that I'll talk about in a moment, the XBows feels like a comfortable, luxurious, expansive experience. I can let my hands rest and dance languidly around the keyboard without having to tense and scrunch up at all, it feels like going from a twin size bed to a queen size bed.

The per-column splay

Column-splay – the rotating of key columns, on column-staggered keyboards, out from each other in a sort of fanning arrangement out from where your palms will rest – is rare to see even in the most niche DIY ergonomic split mechanical keyboard. This is deeply unfortunate, in my opinion, because when I close my fists and then spread my fingers out in the most comfortable and natural-feeling way, that doesn't result in my fingers making a perfect up-and-down motion from my palm, but in them splaying out from my palm at a natural angle. And this makes sense – if you look at how the fingers extend into the palm in a human skeleton, you'll see that they're naturally splayed, and keeping your fingers only going straight up and down would actually be keeping them bent in the middle. A per-column splay mirrors this, meaning the motions of my fingers can be more natural.

The column-staggered keys

Columnar key layouts with different offsets for each column, to account for different finger lengths, are pretty standard on ergonomic keyboards these days, but that doesn't mean that this isn't a great aspect of the XBows. I used to use all sorts of improper fingering on traditional keyboards, reassigning keys between my fingers so that they could travel in straighter lines, because the row-staggered layout requiring my fingers to move along lines diagonal to my actual hands was deeply uncomfortable, but this was never a complete solution, as it either resulted in some fingers having V travel or being left with some diagonal motions, and in general was just a bit of a mess. The XBows resolves this completely. Now almost all finger motions I perform, except to reach certain symbol keys with my pinkies and the inner rows with my index fingers (which are pretty much unavoidable issues without fundamentally redesigning the keyboard or going low-key) are straight in and out from my palms in a natural way, just like opening and closing my fingers, and the top keys of each column are equally easy to reach for each finger!

The adjusted key sizes

One of the other really great things the XBows does that I see zero other ergonomic mechanical split keyboards doing is adjusting key sizes to increase accessibility. For instance, thumb keys that are under the palms, where the thumb isn't particularly dexterous, are huuuge, which is very helpful, and the keys at the top of the pinky rows are all extra tall, making them much easier to reach.

The split

This, of course, is probably one of the most striking aspects of the XBows. A unibody split design for a keyboard is not new or particularly revolutionary in itself, but it's still a complete game-changer for my experiences with a keyboard. Being able to keep my wrists and forearms in a nice, completely straight and natural line with each other, straight down from my shoulders, instead of having to rely on awkward, inconsistent, and generally unworkable when you want to type fast hacks to finger and hand positioning on traditional keyboards like I was used to doing, is just so great. It's essentially completely eliminated my recurring carpal tunnel symptoms, to the point where I can now type for 8 hours a day for weeks on end and really not notice a thing. It's just excellent.

Some might raise concerns with the fact that it's a "fixed split" – i.e., the two halves of the keys are separated and rotated at a fixed angle from each other on the same single board – but in my opinion this is not a serious problem. The blessed thing about triangles is that even if you fix the angle of one corner, you can adjust the angles of the other two (and thus the angle of your wrists from your forearms) by adjusting the length of the two sides coming out from the fixed angle (the length of your arms reaching from your shoulders to the keyboard, controlled by your distance from the keyboard). I think very few people have such narrow or wide shoulders that simply adjusting their distance from the keyboard won't fix 99% of whatever issue with the fixed angle they're having. Moreover, the fixed angle comes with a lot of benefits for me – it was really annoying trying to use the Iris and constantly having things knock it around out of wack, having a wire stretching between the two halves – Bluetooth is too unreliable for such a crucial HCI for me – blocking putting things between them, and then there's just the inherent fiddliness of trying to find the right position for the halves all the time, and always being tempted to meddle with it, not to mention the difficulties in travelling or using them with a laptop.

The fused thumb cluster

The idea of a thumb cluster isn't new to the world of split ergonomic mechanical keyboards either. The idea is simple: for keys that you're going to be holding down a lot, like Ctrl, Meta, Shift, Super, etc, you want to put them under the strongest finger on your hand, the one that's most suited to performing such a task without undue strain, not the weakest one. Thus, we put all those things, in addition to the spacebar, under your thumbs, instead of under your pinky fingers like on a typical keyboard. This also has the delightful effect that key chords become gripping motions that are quite natural to humans as creatures with opposable thumbs. If I didn't already have pre-existing RSI, this might even make key-chording Emacs usable!

The XBows has some fun twists on this idea, too. For one thing, it uses the adjusted key sizes idea to great effect for thumb cluster keys, to make them a lot easier to reach and use than many thumb clusters. For another thing, thanks to its "fixed split" design, they keys in the middle of the cluster (Backspace, Enter, Ctrl, and Shift) can serve double duty, since either thumb/index finger can reach them easily enough, which is not something that can be said for fully split keyboards, which either have to do without duplicating available keys between thumbs – which has significant ergonomic drawbacks, since different thumbs will be easier to use for modifier keys given different combinations of other keys pressed, this is why even traditional keyboards usually duplicate all the modifiers – or have to use up their precious key space duplicating them at the cost of other options. By means of the fixed split idea, the XBows functionally has a 12-14 key thumb cluster, when the vast majority of fully split ergonomic keyboards can only afford 8 thumb keys at most!

Plentiful keys

This is one of the key reasons why I chose the XBows over competing ergonomic split keyboard options. The XBows comes with a healthy compliment of 86 keys, full enough for all the symbol, number, letter, modifier, function, and navigation cluster, and arrow keys on one layer, including duplicates of all of the modifier keys, without any need to sweat out some kind of highly-optimized, crammed-in layout or deal with 36 invisible layers. The best part about this is that if you find you don't need some of these keys, you can just remap them to other things, and if you find that you prefer the layer approach to the plentiful keys approach, you can of course emulate that too.

Layout designed for easy transitioning

Another great aspect of the XBows is that it's layout is explicitly designed to make it easy to transition back and forth from traditional keyboards with as little a loss in productivity as possible. This is primarily achieved by ensuring that all modifier keys, and keys like backspace, are in their typical positions as well as their more ergonomic positions on the thumb cluster. Thus, if you accidentally forget and try to use them, they'll be where you expect them. Eventually, if you decide you don't need them anymore, you can remap them to something useful (like maybe keyboard macros?), but this is a great onboarding device, and if you frequently have to use other keyboards, it can continue to be helpful for a long time as well.

QMK firmware

I've mentioned layering and mapping keys and so on several times now, so I think it's time to cover this. The XBows allows you to flash it with the fully open source and extremely versatile and powerful QMK firmware, so that you can write arbitrary C code – with a very good framework around it – to design the behavior of your keyboard, lighting, and so on. It's great! I wish it wasn't so annoying in some ways (for instance, the build tools broke on my recently), but it allows you to do some really incredible things personalizing your Ono-Sendai. And if that isn't your speed, there's also an official version of the XBows firmware that supports Vial/Via, so that you can use a graphical user interface to customize your keyboard layout, layers, keyboard and lighting behavior, etc. Albeit in a less flexible way.

Hot-swappable key switches

Continuing with this theme of the XBows being shockingly hackable, it has hot-swappable Cherry MX (or Gateron Optical) switch sockets, meaning that you can buy whatever switches you want from anywhere on the market (or even kitbash your own custom switches, as I do, with my TX 75g springs in my Halo Trues) and use those, instead of just the selection they offer.

Unibody aluminum design

This thing is built to last. You can still relatively easily open it up for repairs if you need to, it's just two normal screws on one end, but you probably won't need to repair it anytime soon, because the hide protecting the delicate circuitry inside is four pounds of aluminum machined from a single block. You could bash in a person's skull with this thing and then sit back down to type again.

Modular

There are magnetized mounting rails and 8 data pins on either side of this keyboard for attaching extra modules. The company only officially provides a numpad that you can use with these mounting points – which, as a result, you can put on either side! – but combine these data pins with the fact that you can flash arbitrary firmware and they use a known and fairly common processor chip inside this keyboard, and there's a lot of potential here for additional hackability.

No Bluetooth

No connection issues. No delays. No battery to run out and eventually expand and die and need to be replaced. 'Nuff said.

Detachable cable

This is just a nice little extra detail, but it's good to call out.

Tenting

From an ergonomic perspective, the biggest thing missing from this keyboard is tenting. Tenting would address the final axis of wrist ergonomics and really make this keyboard perfect. Of course, arbitrary tenting angles aren't possible with a fixed split keyboard, but a well-designed fixed tenting angle, like those found on the Kenesis Advantage and even Microsoft ergonomic keyboards, wouldn't go amiss – even a small tenting angle could go a long way. Honestly, I don't know why they haven't done this already, considering the apparent attention to detail in every other aspect.

Innermost column splay

One of the really nice touches on this keyboard is that the pinky finger column on both sides is actually splayed inward toward the rest of the hand just a tiny, tiny amount, instead of being splayed outward. This conforms nicely to the natural angle and movement of the pinky, and is a beautifully considerate move. I wish they would've done something similar for the innermost column of keys by removing the splay entirely, aligning that column completely with the other index finger column, since the index finger does double duty both managing the column it naturally lands on if you're following proper typing form, and those innermost keys, so that column doesn't need its own splay, since it doesn't get its own finger, and in fact it getting its own splay only makes the index finger reach more.

Distance to some symbols

Due to how much space the combination of splay, split, and central thumb cluster takes up compared to the letter/number keys of a traditional keyboard, the peripheral keys on the keyboard need to be pushed out substantially to make room. This means that the bracket keys are a little bit further than they'd ordinarily be, and the backslash/pipe key is waaaaay further – like, truly out there. It's honestly difficult to reach it with any kind of reasonable accuracy.

In all, while this keyboard does ultimately make some tradeoffs to achieve its goals, and as a result is certainly not perfect, or for everyone, I do find it to be the perfect hacker's keyboard, at least for me:

1. The completely programmable, totally free and open source, flashable firmware, hot swappable switches, and modularity mean there's a massive amount of potential for hacking the keyboard itself, almost on par with most DIY keyboards – once they're built, at least – although it loses points in that department for its design not being open source, of course.
2. It's also ergonomic, which is important to hackers, who spend long periods of time typing, and its approach to those ergonomics is generally extremely thoughtful and makes really insightful tradeoffs,
3. It values your time and productivity by trying to provide an easy stepping stone between traditional keyboards and full use of the XBows, meaning you don't have to experience as long and difficult of a trough in your productivity to use it, and makes it easier to remain able to lean over someone's shoulder and type on their keyboard (an important tradition of the original hackers at the MIT AI Lab)
4. It has all of the symbols (important for programmers, especially polyglots), letters, numbers, function keys (useful for Emacs Keyboard Macros) easily accessible without annoying and obstructive context switches to use them.
5. It's sturdy in a way DIY ergonomic mechanical keyboards aren't: it will last an extremely long time and take a shit-ton of punishment, so you can feel free to throw it in your laptop back and take it everywhere you go, pull it out in any situation to interface with any Hosaka, which is exactly what you want out of the highest throughput means by which you communicate with cyberspace.