I’m grateful to Reddit user Alexadar who wrote this article for publishing on AllThingsErgo. He describes an approach to resolve some of the keyboard ergonomic issues related to the keyboard layout, and outlines the ideas he used to achieve his ultimate keyboard layout. Thanks for reading!
Ergonomic v. “Regular” Keyboards
As “regular” I consider all the usual keyboards with straight rows and staggered columns. That includes the desktop and laptop keyboards, be it a full 101-key or a ten-key-less or even smaller 60% and 40% percent varieties.
A primary sign of an “ergonomic” keyboard for me is the separation of the hands placing them in a more natural position, be it a complete separation in Let’s Split (see guide) or a slight curve of Microsoft Natural Ergonomic 4000.
This segregation is rather loose, so the slightly curved keyboards (like Logitech K350) can be placed in either category. In fact, this separation is not that important since most of the regular and ergonomic keyboards share the same issue with the keys layout discussed here.
“Less Important Keys” Issue
The “ergonomic” keyboards address one of the biggest issues the “regular” have: the angle the hands are positioned. They solve that issue to some degree; the keyboard may be tilted and tented in a different direction, in some cases for each hand individually.
The problem is all those improvements are applied to the main alpha-numeric block of the keyboard mostly. All the additional keys, the cursor control keys, F-keys, regular modifiers like Shift, Control and Delete, they all are largely ignored or placed as an afterthought.
I understand that the designers and manufacturers try to keep the layout as close to “standard” as possible, not to overload the keys with functions. That is quite understandable, the regular users have trouble to memorize the QWERTY layout, not even thinking to learn touch-typing. So in most cases the key function is limited to two different actions maximum. It makes all those additional keys necessary even in the “ergonomic” keyboards. Unfortunately, there is not much space existing for them.
Keyboard Usage Patterns
Computer keyboard is used differently, here are a few scenarios
- Web-browsing is limited to a few keystrokes and then scrolling through the page. That scenario’s requirements for the keyboard are pretty low. Practically anything will work, yet it still can be improved.
- Data Entry limited to numbers – it is a special case in which I have a limited experience way back in the past, so I will ignore it whatsoever.
- Plain Text typing if limited to typing without much editing mostly relies on the alpha-numeric keys, so again, pretty much any keyboard could be comfortable. Yet it is a rather fictitious usage scenario since most of the text composition requires editing, i.e. cursor control. Blessed are the vim users who can rely on the main key block, unfortunately, they are few and between.
- Coding and Text Composition. That is my primary usage scenario. Lots of typing including numbers, dates, special characters. The text is modified many times, the cursor moves back and forth, blocks of text and code copied, cut and pasted, key combinations are hit to perform various actions. In this scenario most of the keyboards have issues.
Cursor Control Issues
What most of the keyboards have a problem with is text manipulation. Look at the cursor movement block, the Up/Down/ Left/Right keys, Page Up, Page Down, Home, End, Delete. For over a decade I swore by IBM/Lenovo ThinkPad laptop keyboards. I used both built-in and separate versions of those keyboards, carrying them with me wherever I went.
I consider the layout of those keyboards as one of the best thought through. The location of the arrow block, the shape of the keys, even the additional navigation keys in the top-right corner, everything seems to be very logical and convenient. Well, it was for about twelve years, and then my fingers and hands started to ache.
In order to move the cursor around ThinkPads have two options: the touch stick and the cursor key block. The touch stick is located in a perfect spot, but its usage is not as comfortable as a mouse. That is it is ok for quick cursor re-positioning, and even for diagram creation. For the text editing, text selection it lacks precision, actually it is traded for the speed in my case. That leaves me with the cursor control and the page navigation blocks. Those blocks in ThinkPad keyboards are quite easy to use, much easier than in the full-size and TKL boards, that probably was the main reason for my hands to last that long.
The problem with those cursor control keys is they are separate from the main key block, the right hand to be moved quite far laterally to reach them. Yes, I managed to use the right middle and ring finger and pinkie and it was comfortable for quite a while. In the end it was getting sore earlier in the day, so I had to do something with that.
The solution was the Space-FN layout.
I found it here. The idea is pretty simple – space bar inserts a space if pressed shorty, and acts as a modifier when held. The cursor keys can be mapped as WASD or IJKL, all other keys can be moved closer to the home position as well. The large space button is fairly easy to press, all the usual QWERTY keys remain in place, it required very little time to learn.
I used AHK then switched to TouchCursor, solely due to the issues AHK had had with MS Remote Desktop, functionally AHK provides much more options. Those are tools for Windows; there is Karabiner for Macs and some tools for Linux with similar or more advanced options.
I defined that layer as following: cursor on IJKL and ESDF, other navigation keys around, the F keys over the number row, made Tab to work as Enter, Backspace as Delete.
That proved to be very comfortable, so I installed it on all the machines I worked with. The biggest drawback was the inability to have it everywhere, on the computers I have to rights to run external programs, other machines I used occasionally. That issue was resolved with the fully programmable keyboards.
ErgoDox is a split columnar keyboard with a thumb cluster. From the ergonomics perspective the keys placement is a great improvement from any single-piece staggered keyboard, even the mechanical ones.
The fingers are moved mostly up and down, very few lateral motions.
The default layout has the navigation keys split between the hands and fingers, thumbs are involved a lot, the fingers have to be spread pretty wide. Additional inner columns seemed to be handy in the beginning, later they became a nuisance.
Here is the default layout as of the current version, it is still pretty close to the regular QWERTY with practically all usual keys jammed into the available keys:
Luckily the layout is very easy to adjust – ErgoDox EZ site offers a great visual layout configurator.
I applied the same logic as I used in Space-FN.
With this layout the QWERTY layer served for the alpha-numeric keys. The navigation and even the basic editing could be done with one hand only, thanks for the protruding Shift and Control keys which I learned to press with the palm or the pinkies.
I found that I primarily use the right side for cursor move while left thumb was holding down the layer switch and left fingers used for Cut/Copy/Paste, Select- all and Undo operations, as well as hitting Tab that played role of Enter. That discovery was used later.
The mouse key placement was rather an afterthought, later I found a better way. The FN keys are also on the same row as it was in my Space-FN configuration. It was actually one line too far from the home row.
I tried to use all the available keys on the Dox, yet now is seems better to simply abandon that top row completely. The reason is the table being too high for the hands to hang above the keys, i.e. the elbows are lying on the table. In that position any time I reached for that top row the hand would change the position and would have to be re-positioned again, pretty annoying. Still I had created about two dozen versions of the layouts, moving the modifiers around mostly.
The thumb cluster is was a novelty for me, I tried to put the modifiers there in different ways. I moved the key caps trying to place the top surface at the different level, so I could recognize them with the fingertips, and still reach all of them. It turned out to be pretty hard, so the three inner ones were left unused. I placed the least used modifiers in there and barely touched them.
While Dox’s visual configurator is great, it does not allow two keys to be used to switch between four layers. For that one need to use QMK, which I was not ready to do at the moment.
QMK project is used in many keyboards’ firmware. There a dozens of the keyboards built with, and they have from a couple to a few dozen of layout versions. That variety leads to the problem which of them to choose after the default one. I ended up with making my own layout based on the default one and the experience with Space-FN and ErgoDox.
I started with a quite simple split version of Planck keyboard, a 48-key 12×4 matrix.
I followed this manual. It is a regular Planck manually wired in 3D-printed halves, which are connected by a non-removable cable made of a broken HDMI cable. The keyboard is driven by a single ProMicro piece with Planck firmware.
What is most important is the programmability of that keyboard. Planck uses QMK firmware with fully adjustable layout. The configuration even has options to fix errors in the physical matrix configurations – diode direction, the IC contacts used for specific rows and columns. That keyboard was my first sandbox to play with QMK.
Later there was a plate-based Let’s Split, another two 6×2 blocks. It is a very simple build, no wires to mess with. It also uses QMK; the layout markup slightly differs from Planck’s but was quite easy to port.
Finally there was Dactyl-ManuHand blend of Dactyl and ManuHand. For these boards I chose to use ErgoDox EZ QMK firmware. It turned out to be a bit harder to configure because I did not follow the wiring guide, so my keys were connected differently than in the Dox. Anyway the same ideas were applied; the changes mostly due to the thumb cluster used instead of the bottom row in Planck and Let’s Split.
While tinkering with those keyboards I built a list of the requirements to the layout.
Keyboard Layout considerations
The list is rather long, but it covers pretty much everything I applied to my layout:
- As few hand movements from the home position as possible
- I.e. the fingers to stay in the home row/home position most of the time.
- The reduced number of rows and columns in Planck, Let’s Split and Dactyl-Manuform enforce it naturally.
- No awkward finger placement in multi-key combinations. That is the fingers should be not reaching in different directions, e.g. Win+E pressed by left ring and middle fingers going respectively down and up. For that a repeated key to be on the other side.
- As close to QWERTY as possible – I do not want to re-learn the touch-typing again.
- As close to the standard numbers, FN locations as possible.
- The modifiers remain in the usual places or at least in the same order (mind I used Thinkpad keyboards for 15+ years, so I biased to the way they were laid out.)
- Space to be in the usual location and be wide enough, i.e. not restricted to a single key.
- No permanent layer switching except for the Plover and Numpad, instead the idea of Raise and Lower layers is used.
- Keep the rightmost side of the standard keyboard available in a closer form. (That is needed primarily for the Russian layout as defined for the standard QWERTY keyboard; all those extra symbols are put on the brackets, slash, and other non-alphanumerical keys. I do not want to re learn the touch-typing in that language either.)
- The navigation controls should be easy to use for the text/code editing since I do that for a few hours a day.
- The navigation with cursor to be done with one hand, either of them.
- Being able to edit text with one hand is nice but not actually required.
- The special keys/combinations to be easily reached – Ctrl+Break; ~ and backstroke signs; Shift+, Ctrl+ and Alt+ numbers and FNs; combinations of Shift, Ctrl and Alt and any other key(s). Need that for FAR Manager and some IDEs.
- Ctrl to be pressed with the palm edge (just a habit I got with the split Planck and ErgoDox)
- Enter to be present on both halves, with a modifier on the left side. Put it on Tab in the cursor key layers.
- Keep the nature of the key similar in all layers. I.e. Backspace becomes Del but not Escape or Enter.
- Avoid using the alphanumeric key as modifiers. While it seemed promising in Ergodox I noticed a significant lag and misfiring on those keys, just plainly annoying, do not want to bother with that anymore.
- Thumb modifiers can be used as space bar when hit shortly, thus stretching it over a usual length.
- Mouse to be controlled with the keyboard as comfortable as possible. From one hand a Touch Stick could be added, but from other hand it was a bit too much for me to work on now, may be in a later version I will add one.
- Cut/Copy/Paste/Undo operations to be performed also with modifiers other than Ctrl.
That is the Ctrl keys are placed much closer to ZXCV on the left, have to twist my wrist a lot more compared to the same movements with Thinkpad’s board, or to use the right-hand or the one under thumbs.
- Thumb cluster keys to be immutable, thumbs are quite hard to re-train.
- The same logic is to place Shift and Alt in the inner lower corners in most of the layers other than QWERTY.
All those ideas led me to the following seven-layer configuration.
- Basic QWERTY and modifiers. Modifiers are projected into other layers.
- Cursor keys on the right (IJKL), Mouse on the left (ESDF). Home/End/PgUp/PgDn on the right, Cut-Copy-Paste and Mouse buttons on the left. Turned momentarily on by a key pressed by the right thumb.
- Cursor keys on the left (ESDF), Mouse on the right (IJKL), Home/End/PgUp/PgDn on the left, Cut-Copy-Paste and Mouse buttons on the right. Turned momentarily on by a key pressed by the left thumb
- Numbers, FN layer turned on by pressing two keys by the left and right thumbs. Numbers on the top row, FNs on the second, FN11 and FN12 in the left bottom corner.
- Extended right side, i.e. those non-alphanumeric keys from the right side of ANSI keyboards. shifted to the left into the existing keys. Turned on momentarily by holding Tab.
- NumPad layer with the numbers on the right side as in a numeric keypad, plus the top row is the numbers. This layer can be turned on permanently by a combination similar to NumLock.
- Plover layer, also can be turned on permanently by another combination,
it turned off back into QWERTY.
Most of the time I use layers 1-5. Numpad layer #6 I thought would be used a lot, but in reality, I turned it on a few times by accident only. Plover layout #7 I only started to learn, so it also is barely used compared to ##s 1-5.
A note on the layer order: ExtraRight layer is on top of the others (namely the number layer) intentionally. This way I can be in the numbers layer (with both thumbs holding Lower/Raise keys) and hit the parenthesis or brackets, dashes, single quotes and other symbols from that right side part which is momentarily turned on with left pinky. It sounds hard but quite easy to perform. I use it a lot to enter the dates in queries.
All momentarily switched layers got additional Alt and Shift keys under the index fingers, thus simplifying the combos in those layers.
In Planck and Let’s Split I used the bottom innermost keys as layer switchers for #2 and #3.
Next ones were for Alt. In Dactyl-ManuForm it is a bit different, also it has only 3 rows in the outermost columns, so Shift was moved to the thumb cluster.
Now the thumbs rest on the layer #2 and #3 switchers, arc inside for Shift, and outside for Ctrl.
Alts are under middle fingers in the bottom row, also there is another pair of Alts in the thumb cluster.
The left ring finger gets Win key in the bottom row and the right one used for the system menu. This way the thumbs move in an arc over the top inner corner of the thumb clusters, rarely reaching for other keys.
This layout proved to be quite comfortable, I used it for the last four-five months already.
In the layers below the empty cells represent transparent keys. XXXs and ‘…’s are the blocked keys, not passing the key press to the lower layer. Need them to avoid unexpected symbols to appear or actions to be invoked. Lower rows of the thumb clusters are not shown when they are transparent, just to have them compact enough to fit in a page. In the actual keymap files they are still pictured and have to be fully defined.
Plover layout is not shown here.
The described layer layout along with the columnar key placement has improved my typing comfort greatly. The wrist pain was forgotten so well so I had been very unpleasantly surprised to get it back after a day with my ThinkPad’s built-in keyboard. The very same ThinkPad I used for almost five years is now hurting me.
I understand it requires some heavy push like RSI to start using such keyboards, so I have no hope such a configuration would be ever adopted in mass-production. On the other hand I still hope these ideas could be used in other projects.
You can reach chat with the author over on Reddit.