Programmer’s Keyboard

This summer Jeff Atwood (@codinghorror) has designed and helped to release a new mechanical keyboard aimed at programmers. It was intended to be a modern replacement for the venerable, yet beloved Model-M. If you haven’t heard a Model M keyboard, it’s probably because you haven’t been in the same building as one of them – otherwise you would be intimately familiar with the thunderous clickety-clack noise these devices make. People seem to love them, and there is a big market for loud keyboards with hard to press keys so I wasn’t at all surprised at his announcement. I wasn’t all that interested in it either because I don’t really care about mechanical keyboards one way or the other.

Atwood’s CODE keyboard. It lights up! Also, still has Caps Lock key.

I’m pretty happy with my ergonomic space-alien keyboard (as my friends call it) and so I mostly ignored Atwood’s design. I was cleaning out my RSS reader the other day and stumbled on an old post in which David Bryant Copeland made fun of the design. His post isn’t as much as a critique of the keyboard as an interesting commentary on the lack of innovation on the programmer-keyboard market.

Most keyboards produced and sold in US use QWERTY layouts patterned after the 104-key ANSI standard or the 105-key ISO standard (that’s the one with the funky reverse-L shaped enter key). Standardized layouts are of course a good thing, but they are getting a little long in the tooth. The sizing and placement of the non-alphanumeric keys has very little to do with the frequency of their use. I could take a few paragraphs to point out everything that is wrong with these designs, but I don’t have to because David made a very succinct and to the point list of all their idiosyncrasies:

• Hitting “space” is the most important thing you could ever do.
• Caps Lock and Enter are pretty important and of equal importance – they are the second easiest keys to hit outside of the home
  keys.
• Letters are more important than numbers, as numbers are farther away from the home position.
• Control, Alt, “Meta”/Windows, and Shift are all more important than numbers (they are an equal distance away, but have much larger keys).
• Alt is the most important modifier – it’s right where your thumbs are, making it easy to hold down while typing other things.
• Tab and Backslash are of equal importance, and are more important than most keys.
• Print Screen, Scroll Lock, Pause, Home, End, Page Up, Page Down, Insert, Delete and the arrow keys are all of equal importance,
  but lesser than the alphanumerics and modifiers as they are set off to the right.
• Analphabetics like “!”, “%”, and “{” are least important, because they require the shift key to enter. “+” and “~” are probably
  the least relevant of these, because they are the most difficult to type: you must use Shift and your pinky, and you have to stretch for them.

Personally, I have never used the Caps Lock key in my life, and the only time I ever touch the left Alt key is to alt-tab out of video games (well, ones that support it)… I won’t even mention the “windows” key, aka “instant death button” (whenever you press it by accident in a video game, you are almost guaranteed to be dead by the time you get back in). In fact, we had a whole thread about useless keyboard keys not so long ago.

The standard ANSI and ISO layouts are not optimal designs. They don’t work all that well for writing prose, but they are especially horrible for programmers. The useless keys are up in your face, whereas common programming symbols are inaccessible without modifiers. David’s post got me thinking about how one would go about designing something more suited for day to day coding.

There haven’t been a ton of innovations in the world of text entry over the years (at least not for writing prose or code – it’s all been focused on text message). There’s a smattering of “ergonomic” keyboards some of which provide more “thumb keys”, but in general, this is the same keyboard that’s existed for the majority of our lives. Even alternate layouts like Dvorak keep most things they same – they just shuffle around the letters.

How would you design a better keyboard? Lets use a standard ANSI keyboard as our starting point:

Standard ANSI Layout

I actually prefer ANSI over ISO one because Enter and Caps Lock are approximately the same size. Being a Vim user I typically re-map the latter to Esc which gives the keyboard a nice symmetrical feeling. In vim the you hit the Escape key about as frequently as the Enter key so this works out very well. Similarly the \ key being disproportionately large is not necessarily a bad thing because it is your default “leader” key. It works as a magic button you use to preface user defined command sequences. If you are a moderate to advanced user you will probably be hitting that key all the time.

I took the liberty of vimifying the very basic ANSI setup above without making any other drastic changes and it already is a big improvement. I made the command keys yellow, HJKL block green and made Esc, \ and : keys stand out because of their importance:

Basic Vim Layout

This is something you could do to just about any basic keyboard using nothing but custom key-caps and some re-mapping tools. But let’s take this a little bit further.

The leader key is easy to hit because of it’s size, but most vim users find that extending your pinking all the way to the right is not optimal. When you look through the hundreds of .vimrc files on Github you will notice that remapping leader key to , is a very common practice. That’s because the comma is just off the home row, and thus much more accessible. What if we could move the leader key under your thumb?

The Alt key has some uses in vim, but it is a far less common modifier than Control or Shift. The Windows/Meta key has no uses whatsoever, so why not push the entire block to the left. Control stays on the outside, then Alt and our new leader key lands in the super-privileged position right next to the space bar. Does that make sense? What would you put in that spot.

Since we moved the leader we are still left with a fairly large key under the backspace. What should we do with it? I’m not entirely sure. I’d be tempted to split it into two if possible. But if not, how about we keep it as the pipe | key. I frequently program in ruby, so this makes perfect sense to me. Ruby blocks are enclosed in double bars and for some reason I’m always kinda annoyed I need to hit Shift to type them.

Speaking of shift, do people actually use right one? And by that I mean the one on the right side of the keyboard. I know how they are supposed to work, but for some reason in my mind shifting is exclusively a left-hand task. This might actually be a deep flaw in my touch typing technique, but whatever. I don’t feel particularly attached to the right shift key, and it is super huge. It is big enough to be replaced by two keys. Like ( and ) for example.

Most programming languages use parenthesis everywhere: scoping, function declarations, order of operations, etc.. Why not give them dedicated keys? We can still have them as modified alternate values on 9 and 0 but it seems like they should be first class citizens on a programmer-centric keyboard.

Maybe my hands are weird, but when my fingers are on the home row, there seems to be no good way to hit anything beyond the right Alt without executing some sort of weird finger contortion. The keys there are of the absolutely useless variety, but replacing them with anything seems pointless. So you know what? Fuck those keys. They are gone.

Finally, while Backspace has some utility in inser mode, it is not nearly as important in vim. It certainly does it need to be the same size as Enter. Personally I think it should be the size of a regular, average key. it’s position on the extreme upper right edge of the keyboard already makes it an easy target. So that gives us an extra key we could squeeze in after the =. What should go there?

I figured that macros are a big part of vim usage, but running them is always a pain. The @ is both out of the way, and requires you to hold shift to access it. Why not give it a dedicated key to the left of backspace.

The updated layout would look something like this:

Crazier Vim Based Layout

Most of these changes are very superficial, and in a large part vim-centric. While I moved a number of keys around the overall shape is still very much classic ANSI with just a few additions and removals. Could we do better than this?

Let’s forget about vim for a minute and design something generic. What button do you non-vimers press as frequently as I press Esc? It’s hard to say, but I would venture a guess that it is Ctrl. That’s where most editors hide all the special functions and macros, isn’t it? So let’s put it where Caps Lock used to be. This way it is just off the home row, and under your left pinky at all times.

I mentioned it before, but since the space bar is pretty much the focal point of the keyboard, the spots immediately to the left and right of it are prime real estate that is completely wasted on the underused Alt key. Apple knows this quite well, which is why they put their Cmd key in that very spot. What should a programmer keyboard have in that spot?

Why not shift? Shift keys are already in pretty good locations but that’s mostly due to their size. If we put them underneath your thumbs, we can shrink them down to regular-key size, without making them harder to hit. This gives us two to three additional keys on each side of the keyboard. Also since we moved Ctrl and we don’t want Windows/Meta we can easily fit another two keys on the bottom left.

That gives us 6-7 spare keys. What could we do with all of those? Let’s think about symbols programmers type very frequently?

• I already mentioned parenthesis. They should have keys of their own.
• Curly braces are another good candidate. Most programing languages use them for scoping, and yet they have to be shifted. Strangely enough square braces are typically only used for arrays/collections. This seems backwards. Perhaps we should just switch these around.
• The + symbol is used all the time for math, and most languages overload it for other things like string concatenation. And yet it is one of the most difficult keys to type. Not only is it far from the home row, but also needs a shift modifier.
• Many languages standardize on snake_case for variable and function names, but the underscore is just as hard to type as the plus sign.
• If you happen to work with HTML a lot, shifting to type < and > can be super tedious.
• PHP, Perl, Powershell (and probably bunch of other programming languages that start with P) like to preface variable names with $ symbol which is both far away from the home row, and requires a shift.
• The @ is also a common symbol (Perl uses it for array, Python for decorators and etc..)

Let’s try to arrange it on our mock keyboard:

A generic keyboard layout for programmers.

You have your angle brackets on the left, and parenthesis on the right. The + sign and the underscore are on the extreme bottom left. The curly and square braces were flipped so that you don’t have to use the shift key to create scope. I also added the $ and @ keys above and below enter for easy access.

Note that while this layout is no longer ANSI compliant, it still more or less follows the standard. You can sit at it and start touch typing from memory without making any adjustments and you should be fine. Other than flipping curly braces upside down, I haven’t really changed placement of any keys. I merely added new/redundant ways to enter them.

In his post David suggests a few even more drastic, though probably beneficial alterations:

The symbols most-frequently needed are the exclamation mark, dash, and parenthesis. They are all ill-placed in this layout, being far away from the home keys, while more convenient locations are taken up by the rarely-needed caret, ampersand, and asterisk. I’d bump the parenthesis over one, putting the asterisk on the “0”, swap the exclamation mark with the ampersand, and finally, exchange the carat for the dash.

Let’s add these to our mock-up:

Even more radical approach.

How is that for a coding keyboard? Better? Worse? Absolutely terrible?

How would you re-organize your keyboard of optimal coding layout? Note that this is not necessarily about what you are used to, but what could potentially improve your productivity as a programmer.