Keyboard Builders' Digest /
A (r)evolutionary approach to improve on the standard keyboard layout
Since the year 2000, Peter has been on a quest to improve his typing comfort. In this three-part article series, you will discover three distinct solutions that balance layout compatibility with ergonomics.
Published January 6, 2025

Intro
I am Peter and do not care too much about what others think about myself. I try to think and come up with something which I can stand behind, regardless if that is different from how things are mostly seen or done. And as my peers and relatives can tell, I defend my ideas with passion. But I realize that my priorities or what I consider best (for myself) must not be shared by everybody. Still I think that many might benefit from my ideas and experiences. So if you are crazy enough to question the why and how of keyboard input I hope you get something from the coming articles.
All ideas can be either implemented via a programmable keyboard (QMK, ZMK, UHK…) or via software. I provide software examples you can directly test or use as a start for your custom adaptation. The software examples are realized with Autohotkey (Windows only) or Kanata (Windows, macOS and Linux).
Article overview
Part 1: Improve standard keyboard layouts, staying 100% compatible (this article)
This article series is mostly useful for someone touch-typing or planning to do so in the future. We will look for a systematic approach in finding an easy and logic way how to interact with the computer via the keyboard. In this first article you can follow along my first experiences and solutions for common problems a touch typist stumbles over. For example how to easily access some symbols on a German Qwertz layout. Do not stop reading if you are using Qwerty, Colemak or another layout. The general thoughts and ideas can be applied to any alphanumeric or language layout.
After analyzing how we use a keyboard and what is wrong with the current standard layouts I will suggest 4 different solutions of increasing typing comfort, at the expense of a bit of compatibility to standard layouts. The first suggestion is covered in this article and already has the benefit of easily accessible common symbols and allows comfortable and quick navigation and editing from the home-row position, but still keeps full compatibility with your current layout.
Part 2: Anymak, a largely compatible "layer-less" keyboard concept
In the second article the concept is heavily extended and improved. Building on the observations made in the first article a new keyboard concept is suggested. That concept can be seen as evolutionary, because it uses solutions which have been used before. On the other hand you could also consider it as revolutionary, because it combines several approaches, which to my knowledge have not been combined before. And last not least it makes a small, but important change from the standard layouts, by slightly updating the position of the Shift-key. I call this keyboard concept Anymak.
While my first suggestion does only add new options to any given layout, in this new step some compatibility to the standard layout is given up. The win is an even improved typing comfort. It is still compatible to be used on standard keyboards and can be used or adapted to any language or alphanumeric layout. In case you have not tried a columnar staggered layout I want to encourage you to do so. Anymak is developed to be used with exactly the same fingering on a standard row stagger or a columnar staggered keyboard. So you can use a programmable keyboard at the desk, but use your laptop keyboard (with Kanata software) on the go – with no significant adjustment of the fingering needed!
For those wanting or needing the highest compatibility with standard layouts a light version of Anymak, called Spacemak is presented as an alternative as well. Using one of those two concepts is possibly the sweet spot for most people who do not want to learn a new alphanumeric layout and where you get most bang for your buck. Read: little invested time and no or not too major changes from your chosen standard alphanumeric character layout.
Part 3: END — A fully optimized layout for English and European languages
For those looking for the last few percent of typing comfort the third article introduces a custom layout I developed. That after ditching a custom Colemak-like layout I had developed earlier. You will hopefully get some ideas what to consider when choosing or creating a custom layout. My final layout is based on AdNW's KOY layout. I use that on top of the Anymak layer concept. The layout is optimized for English, German, Dutch and other European languages and is called anymak:END. In the realm of keyboards I am now close to what I consider a well-rounded solution and which likely will not warrant major changes. It can be extended with mouse, number or program specific layers if wanted.
Key-press? Analyzing how we interact with a keyboard!
Like thousands had to discover painfully the standard keyboard layout is not created from an ergonomic standpoint and often gets in the way when one wants to type comfortably. This is especially true for non-English languages where additional characters and symbols were added as an afterthought.
The main problems I see is that neither key arrangement (where a key is located on a keyboard) nor key assignment (that means which function or functions a key holds) do take ergonomics and consistency enough into account. Let us try to take a systematic look.
Single keys can have the following functions:
Output an alphanumeric character, for example:
- alpha-keys like a, b, c……
- symbols like !, ?, $ ……
- space-key: space symbol
- enter: newline (char)
Modify the output of the following key, for example:
- Shift: capitals and some symbols
- AltGr: additional characters or symbols
- dead-key: diacritic version of the following character
Trigger an action, for example:
- F-keys (F1: help, F3: search……)
- ESC: stopping an action, closing windows (some programs), changing modes (Vim)……
- arrow keys, home, end….: navigation, movement
- Backspace, Delete: erase and edit existing output
- PrintScreen: display screenshot
- hardware-keys: display backlight, volume……
On top of that we use multiple keys:
Key-combos with modifier keys, for example:
- Alt-Tab: switch between applications
- Ctrl-c: copy
- Ctrl-Backspace: delete previous word
Key sequences, for example:
- compose key followed by char-keys (on Linux or with extra software on Windows and macOS)
- dead-key followed by Shift- and char-key: for capital accented characters
- and typing words of course :-)
What can we learn from that overview?
First, we use the keyboard for different tasks. One is of course to input text or information. For most that is at least one main usage of a keyboard! But we also control programs with keys. It makes sense to differentiate between these two and more tasks or "usage modes". I will come back to that in the following article in more detail.
Second, sometimes we need to hold down keys for alphanumeric input (Shift, AltGr) and sometimes we do not (dead-keys, compose-key sequence, words). Does that make any sense to have different mechanisms to achieve the same function? No, absolutely not. In contrast, it is a very bad idea to require holding down a key to output characters. The problem is that it slows us down and increases the chances to make errors. Most of us got so accustomed to holding down the Shift-key, that it is almost a paradigm. But the only reason it exists is because of the history of typewriters, where the drum (or carriage) was literally shifted to access the capital letters. I even want to question the current concept of "layers" and think we should instead mostly think in terms of key sequences! The following article will also go deeper into that.
Interestingly, technically a key-combo (for example Ctrl-c) is the same like using the Shift or Alt-Gr layer, because a key-combo does need to be executed in a specific order as well. The only difference is that a key-combo triggers an action instead of a character output. For text I consider a combo a no-go in any well-designed keyboard layout. But I think the concept of using the key-combos to trigger actions is not a problem. The reason is that when you type text you want to "spit out" characters quickly with a speed of 60 wpm or higher. But when you trigger computer actions or edit text you are mentally in a different state and will not need that high of a speed. So the somewhat cumbersome key-combos are much less likely impact speed, precision and comfort. But using them allows to control the computer with the same set of keys, just adding the modifier-key into the mix. Keeping key-combos for actions therefore makes sense. Do you agree?
Third, using a standard ANSI or ISO layout or common keyboards, like laptop keyboards, we also notice that many keys can not be (comfortably) reached from the home-row position, bright green in the graphic below, indicating the base position of the left and right hand. That is surely true for the complete number (orange) and navigation section (blue) of a full size keyboard:
Escape (pink), AltGr (red), Enter (yellow) and Backspace (black) and the F-keys (purple) are pretty far from the home row position as well. :-(
Finally the AltGr-key (red) is not really easy to access from the home-row position. You have to tuck the thumb pretty far under your hand to reach AltGr. To make things even worse the position of AltGr is not always the same on different keyboards. That are two important reasons why I am strongly against the AltGr-layer. In addition AltGr is just a shortcut for Alt-Ctrl and does not always behave nicely with some programs. Especially when one uses a non-US operating system. Another important downside of AltGr is that it is only existing on the right side of the keyboard. But to improve ergonomics and speed it is much preferable to be able to use keys like Shift or AltGr on the opposing hand to the following character-key.
Fourth, we find that with standard keyboards we normally do not use the following possible ways to interact with the keys:
- timed key-pattern, aka tap-dance (double-tap, double-tap hold, single key hold…)
- key-chords, where several keys must be pressed (roughly, but not exactly) at the same time — like on a piano. The order of the key-presses is not leading to different output or actions. In this article I use the naming key-chord to differentiate from key-combos (as defined above), where the order of key-presses is relevant.
Summary and conclusions
The following table lists all possibly key-interactions of a standard keyboard (layout).
We can broadly divide the usage of a keyboard to either text input or triggering computer actions. For text input we generally want to have no dependency on the timing. This to assure that a person can use the computer as slow as he wants, but on the other side also to speed up as fast as possible. Only the order in which keys are pressed is relevant. This is fine for single key presses. For quick text input it is very unfortunate to require holding down a layer-key (Shift, AltGr), because those are cumbersome to use and potentially error-prone and slowing the user down. It also makes it harder to favor hand alterations and to give the other hand time to get into the position for the coming key press. The solution are one-shot keys, which will be introduced in part 2, because those are not fully compatible with the standard layouts.
To trigger actions, speed is less relevant, it can be a viable option to realize many functions with the restricted number of keys available. So I consider combos to be o.k. Still they should be easy to reach and do not require hand-contortions. There is room for improvement as well, which we will also address in part 2.
We also note that standard keyboard layouts do not make use of any time-dependent input methods. That makes sense for a general purpose keyboard layout, because it needs to be usable for slow and fast typists. We will later see that tap-dance or chords can be interesting to be used on a custom (personal) basis although. Mainly to trigger actions, toggle to a layer, but potentially also to output text snippets or rarely used characters.
Lastly we have seen that some keys can not be reached from the home-position and that AltGr to access extra symbols has serious downsides. Let us fix that now.
Two main problems — one easy fix
Assuming we want to fully stay compatible to a standard layout there are not too many ways how that can be achieved. Luckily there is one key in all standard keyboard layouts, which is hardly used or even can get in the way. That is the CapsLock-key (turquoise-blue in the graphic above). Some assign Esc or Ctrl to the CapsLock key. That is surely an interesting option. But I think the key position is too good that it deserves an even more prominent role. What when we use the CapsLock-key to be an additional (held) modifier key? Then we have the complete right hand free to use for symbols which are hard to reach otherwise (AltGr) or are not available at all. Last but not least it also allows us to get the most important keys from the navigation block to the home-row position, such as the arrow keys, PageUp / PageDown and more. I have been using this concept from 2007 to 2022 with great success. You can either use such an extended standard layout which somebody already has created. Or you can come up with your own solution from ground up. In any case it likely pays off to look for your personal keyboard pain areas and address those. :-) So, which symbols do you need in your programming languages often, which should be easier to access. Do you make screenshots regularly for your work and would benefit from a key in accessible from the home-row and so on…
DeutschlandPlus — an example implementation
As a German I have the problem that \[]{}@ and other symbols are hard to reach, via the AltGr layer. So I wanted to make those available in a good position. I am a Vim user and already was accustomed to the HJKL arrow positions. So I assigned those as well. Also I wanted to have Backspace and Escape easier to reach and added them to the new layer. Here is a screenshot of the assignments I made. The new layer options are printed in the lower right corner of each key:
This concept has proven to be very useful. As a special treat the new layer includes one key (Any), which will open the website AmpWhat to search for characters one will not use daily, but might need on occasion, very handy.
In my Github repo you can download a documented Autohotkey v1 script, both as an editable script and a Windows executable, which you can use right away (for Qwertz) or use as a starting point for your own custom layer. Alternatively Kanata is a great option and works on all major operating systems.
I call my solution DeutschlandPlus, because it only adds to the German standard Qwertz layout and does not change or take away anything. There are only additions with new functions. I was working in a lab for many years and had my Autohotkey script running on all lab computers, without the other users being impacted by that. They did not even notice the superpower the keyboard had. ;-) As a side note. In case you want to still use CapsLock-key with the standard function, this is possible as well, because CapsLock is only used as a tap-key and neither repeated nor held. Also assigning Esc to the tapped key and activating the new additional layer, when the key is held would be possible. I personally decided to only use the CapsLock key as a layer key, so that I do not accidentally activate it. You can then put Esc and CapsLock in your new layer when you want to.
If you want to explore the ideas behind DeutschlandPlus in more detail, read my (German) article on Hashnode. For English speakers use the Google translated website, which is very usable. The article also discusses alternatives like using Neo or EurKey. I personally think that using another approach instead of Neo or EurKey is better for most people. This is where Anymak and additional software comes into play. When you are curious, read on in part 2 published shortly here. :-)
Peter Paul | |
Handle | rpnfan |
Location | as a German living in the Netherlands between Gouda and Rotterdam |
Description | somehow I became a "keyboard freak" over the years, probably spending too much time on finding the perfect keyboard configuration ;-) |
Joined (the hobby) | around 2000, developing my alphanumeric layouts since 2022 |
Niche | keyboard tricks for me and possibly you? |
Fav. switch | Kailh Deep Sea Silent Pro Box: Tactile Whale (alpha-keys) and Linear Islet (mod and shift-keys) |
Fav. keycap profile | OEM / Cherry, but searching for the perfect sculpted profile (current contenders I would like to try: CLP, DES…) |
Other hobbies | music, DIY-loudspeakers, riding bicycle and a bit of woodworking |
Links | github.com/rpnfan, youtube, keyboard.hashnode.dev |
Author keyboard history
- 1982 learning touch typing - German Qwertz, with traditional fingering, using electric and even sometimes still mechanical typewriters
- ~ mid 90s starting to use the Vim editor
- ~ 2000 first split computer keyboard - FUJITSU KBPC E
- ~ 2000 running a small website with keyboard software tips
- 2007 created an add-on layer-concept for Qwertz "DeutschlandPlus" — implemented as AHK script, used that till 2023
- 2010 looking into alternative layouts like Neo and Nordtast, but staying with Qwertz. Being a bit active in the Neo mailing list and to my knowledge being one of the first suggesting to test new layouts by translating them to a known layout.
- 2015 moving to the Netherlands, needing additional characters/ diacritics (trema)
- ~ 2018 thinking about buying the original UHK, but staying with the Fuji keyboard (being on the 2nd one in the meantime)
- 2022 buying Keyboardio Model 100 - not using it, because of being not "compatible" enough and palm rest being in the way and being disturbed by software bugs and limitations. The sculpted keycaps of the model 100 are an important step IMO into the right direction. We need more and better sculpted keycaps — available commercially!
- 2022 developing qwertz-like layout (like Colemak, but better for non-english languages, with almost no impact on the English performance) and learning the layout in a month, but ditching it after another month when I had about 50 wpm, because it was too busy on the right hand (same problem which Colemak has, as I found out then).
- 2022 developed first iteration of a fully optimized layout, based on AdNW's KOY/ XOY variant. Suited for English, German and Dutch and other European languages. Making heavy use of the opt Analyzer software, which is not known well enough and one of the best IMO
- 2023 finetuned my alphanumeric layout with the opt analyzer and by practical testing over a year. I gave my layout the name END (which stands for being my final layout and also points to the three languages it is optimized for).
- changed my layer concept from using the CapsLock key to using the SpaceFN concept and fully integrated Enter, Backspace and the complete navigation block in the 3x6 layout
- changed the Shift key to easier to reach positions and using one-shot keys
- 2023 buying UHK v2 - enjoying the experience very much, great configuration software, but using the trackpoint module less than I expected (being on the thumb and not on the index finger)
- 2024 buying ZSA Voyager, not liking it due software limitations and main thumb key in bad position for me
- 2024 added bottom row mods to finalize my layer concept - which is now named Anymak and complements the character layout END → anymak:END
- 2024 switching to a Franken-Lily58, with a 1.75u wide main thumb key. I feel that I have found "my" keyboard or at least being super close to the optimum
Published on Mon 6th Jan 2025. Featured in KBD #183.