Keyboard Builders' Digest /

END - my final keyboard layout

Peter wanted to find "the best" alphanumeric layout for English, German and more European languages – and ended up with anymak:END.

Peter Paul
Published March 5, 2025

After ditching a custom Colemak-like layout, Peter wanted to find "the best" alphanumeric layout for English, German and more European languages like Dutch and French. Based on AdNW's KOY variant he reached his destination with anymak:END.

Article structure

This article is structured in the following in three main sections. Feel free to jump to the section which is relevant or interesting for you.

• My way from Qwerty to Colemak to END tells my story why I was not satisfied with existing layouts and why for me a Colemak-like layout is not the sweet spot.
• Developing or customizing a layout with opt gives insight in the thought process and tools I used to develop / adapt my layout.
• What makes anymak:END special? shows the anymak:END layers, why and how they work and shows graphics and numerical evaluations for 13 European languages. Last not least a short comparison of anymak:END to Colemak and QWERTY is provided as well.
• A tiny bonus chapter lists some programs to complement your keyboard layout, which highly increase the efficiency of your keyboard / computer usage.

Intro

This last article in the series introduces the anymak:END keyboard layout. It has several unique benefits. First it completely avoids uncomfortable key positions. Second it can be used with the same fingering on both standard and columnar staggered ergonomic keyboards. And finally, it is a multi-language layout especially optimized for English, German and Dutch. It has also been tested to work great with related European languages such as French, Spanish or many Nordic languages. My example implementation in Kanata already includes diacritics for the three main languages, French and Spanish. For other languages those can easily be added as needed.

The Anymak layout concept can be seen as a series of possible steps you can take to improve typing comfort.

The steps are largely independent from each other, and you can choose which one you want to implement. But starting from the bottom up, you will get the most benefit from the least number of changes needed. See the first and second part of this series for more details. You can choose which of those steps you want to apply, add them one by one or implement them at once. In the following a quick overview and summary of the seven steps illustrated above.

The first two steps do require almost no adjustment to a standard layout but already deliver a huge gain in typing comfort and options. Using the SpaceFN concept is a no-brainer I think, and everybody should consider using it. Using the CapsLock-key position as a modifier key allows adding extra symbols or characters like umlauts or other local characters. The third step, using bottom-row mods to access the modifier keys Win (OS, Alt and Ctrl, is really convenient and for smaller ergo keyboards almost a necessity. In my experience this does not come with the timing problems you often might experience with home-row-mods, while being practically as useful. The fourth step is to move the shift-key to the easy to reach pinky position. This is a big win for comfort as well. This can be achieved by either doubling the key to function both for character output (tap) and Shift (held) — or even better by using Shift as a one-shot key, which does not need to be held. The fifth step is to use the key symmetrical to the CapsLock-key position as a layer switch as well. That is the '-key position on a QWERTY-keyboard or the ä-key position on a German QWERTZ keyboard. The latter will require the first notable change in moving the umlaut key to a new place. That could simply be to assign the umlauts on the newly created symbol layer, on the corresponding keys from the base layer (aeiou). Those 4 to 5 steps I call Spacemak. They do not require significant changes to the alphanumeric layout used.

Finally, to get the most comfortable typing experience, here you enter "Anymak-land", you will use one-shot layer keys for Shift and the symbol layer. This requires moving the characters you "lost" (/, ?, ' and " on a QWERTY layout) to a new position in the symbol layer. You will also need to move the character on the B-key position (QWERTY layout) to a new place, to assure you can use the same comfortable finger positions on standard and ergo keyboards. The need and benefit for this change is explained and nicely illustrated in the second article.

I derived an alphanumeric layout to satisfy these needs. Because it marks the final destination of my keyboard layout journey and also pinpointing to the three languages it was developed for, I call that layout END: E for English, N for Nederlands (Dutch) and D for Deutsch (German). END is also a viable choice when you write French, Spanish, Danish, Swedish, or similar languages. When you are using only English, or you use a combination of Eastern languages and English it might be worth to create a new layout. Also, when you are happy with your layout choice and want to continue using Colemak, Dvorak, Graphite, or any other layout this is possible (see also part 2). Below you will find tips on how you can optimize an existing layout to fit into the Anymak concept. But the same principles and tools can also be used when you have other needs or wishes you want to optimize a layout for.

1. My way from QWERTY to Colemak to END

For the most part of my live I have been using QWERTZ, the German variant of QWERTY. I was touch-typing at a speed of about 80 to 90 wpm for real world text. Around 2010 I got interested in alternative keyboard layouts but decided that switching is not worth it for me and implemented a symbol and navigation layer DeutschlandPlus. Over the years I kept coming back to the idea if it would be nice to use an optimized layout, after I had seen a comparison of someone typing with QWERTZ and Neo.

Developing a Colemak-like layout

Still, I was not willing to ditch my QWERTY skills completely. I thought it would be possible to exchange a few keys and still get most of the benefits of an optimized layout. Around 2022 I was looking at Minimak but found that changing 8 keys will improve the typing comfort a bit, but not by that much. My next step was to look at Colemak. I liked the design principles, but when taking a closer look, it was apparent that Colemak works reasonably well for English, but not for other languages. The Colemak layout is not robust in that sense, but very susceptible to variations in the languages (corpus) which is used. It also lacks a satisfactory solution to access German umlauts, or the diacritics needed for Dutch. Using AltGr is not a sensible option in my opinion (see the first two articles of this series).

So, I developed my own layout independently from Colemak. I arrived at a layout which looks similar to Colemak and had almost similar performance for English, when I checked it with this simple Layout Tester, while at the same time being much more robust to be used with other languages. My goal to find a layout which should work for me was reached.

Learning and ditching my custom layout

Then I started to learn my custom layout. For a few days I tried the Tarmak-approach to learn my new layout, which just changes a few keys at a time and then more keys in following steps. But I quickly realized that the need to re-learn a few keys several times in the process was too disturbing for me. Then I changed my practice routine. I continued to use QWERTZ for my daily tasks. In my free time I practiced my custom layout on keybr.com. That worked quite well and after about two months of daily practice of only 15 minutes on most days, my speed had reached between 40 to 50 wpm. I felt that was fast enough to allow me to switch to use my new layout for my daily tasks. The first week or two was a bit hard, but I got through. After around a month my speed and accuracy had improved. I was then reaching around 50 to 60 wpm. That was when I realized two things. Typing felt smoother and less cumbersome, because I did not need to have my hand and fingers jumping all over the keyboard. That was a success. But I also noticed that this was especially true for the left hand, which felt great. On the other side, the right hand was still quite busy, because many words still needed to be typed mainly with one hand. The difference between typing comfort for the left and right hand was significant. The right-hand side often felt cumbersome to use and not as comfortable as the left hand. Below I will show why Colemak or similar layouts suffer from that problem.

I was disappointed. Had I invested all the time to create a new layout and to learn it, just to be somewhat more comfortable? I needed to realize that my typing comfort had indeed increased, but that using a Colemak-like approach will not bring me into typing-comfort-heaven. I was bummed and decided not to stop here. Much later I found a great evaluation how many keys you will need to switch from QWERTY to gain more comfort. After 15 keys the improvements get fewer. But based on my personal experience I concluded that, at least for me, it makes sense to either stay with QWERTY / QWERTZ or not to restrict a keyboard layout optimization, because you will only get so far, when setting too many limitations for a potential new layout.

From AdNW over KOY to END

I already had searched for other alternative layouts in the past and knew that Neo is outdated and not worth learning. One offspring from the Neo project is AdNW, which literally stands for "coming from the Neo world". The two main forces behind AdNW and KOY, Andreas Wettstein and Ulf Bro, follow the design principles of Dvoraks patent. The general conclusion Dvorak has drawn still stand true today. Despite differences in preferences from different people, one can state keyboard layout design principles which everybody can agree on.

• Using alternating hands is good, because it gives the other hand time to get into position.
• It can be comfortable to type bigrams and trigrams on the same hand when you can "roll" your hand over the keyboard. Most find inward rolls preferable.
• Some fingers are stronger or more flexible than others — they should do more work than other fingers.
• Assign the most used characters and functions to the keys which are most comfortable and easy to reach.
• Bigrams which need to be typed with the same finger should be minimized, especially the need to jump from top to bottom or vice versa.
• A scissor where two adjacent fingers need to be used for a key sequence should be minimized. It matters which finger is up and which is down.

This list is not complete but shows some relevant points about what to consider when to search for an optimal layout. This and more are explained on the AdNW website, which unfortunately is only available in German. But you can read the Google translated version, which is quite usable, I think.

Andreas developed his program optimizer to search for the "best" layout, based on those design principles and additional requirements. It is important to note that no perfect layout can exist. You will always find words which are harder to type than others. The "best" layout very much depends on the text corpus which is used. And of course, the more variation the text has, the higher the chance that some words will be less comfortable to type. When creating a layout for multiple languages you will need to make a bit more compromises, therefore. But let us not forget that millions of people use QWERTY without real problems and an optimized layout will still be much better than that. Even when a layout can never be perfect, you will be able to come close to an optimum. Other optimized layouts which are similar close will exist, but they will have different trade-offs and likely not be significantly better. Therefore, it is a nice academic exercise to hunt for the perfect layout. But for practical use you can just pick one optimized layout and be happy.

Why did I not just use AdNW or some of the variants then? Quite simple. Not all alternative layouts are equally good. Also, an existing alternative layout may not fit your personal needs or wishes. This was the case for me. None of the existing suggestions took all the parameters into account which I deemed important:

• Most alternative layouts do not consider the shift key position at all, or not enough. Almost all optimization software options just shuffle around the alpha-keys, but do not question where the Shift or other layer switch-keys should be placed. This leaves a significant portion of the possible optimizations unused!
• I wanted a layout which can be used in exactly the same way on a standard and a split ergo keyboard (see also part 2 of this article series).
• Not a showstopper as such, but I prefer a slightly adjusted weighting of the keys than the weighting AdNW applies. For example, I find the E-key position (top row middle-finger in QWERTY notation) easier to reach than the G-key (index finger on the home row - finger stretched to the right). I prefer a key weighting closer to "Tastengewichtung" of the VOU-Layout.
• Finally, AdNW is developed for Englisch and German, but not for Dutch. So, some bigrams are not comfortable to type and the layout does not offer all the diacritics I needed.

2. Developing or customizing a layout with 'opt'

I took a look at several layout analyzers and decided to use 'opt' from Andreas Wettstein (Source code and documentation are available here: English, German). My choice was based on the fact that AdNW and its variants had proven to be great practical layouts for people needing a layout to work with German and English and they had been developed with 'opt'. Also, the analyzer 'opt' offers several features which I have not found elsewhere. Especially useful are:

• Extended documentation available in German and English
• Possibility to customize the optimization parameters. All critical parameters can be adjusted, such as: key arrangement, finger assignment of keys, dead keys.
• Possibility of searching for completely new layouts
• Possibility to restrict optimization to specific key positions and characters — this is highly useful when trying to optimize existing layouts
• Possibility to grade given layouts
• An extremely useful visual graphic representation of the layout, which illustrates which paths fingers need to travel and the frequency of those motions

Optimizing a multilingual layout

In the following I will give an overview of the general approach I took. In a comparable way you can fine-tune your own layout, when the anymak:END layout does not fit your personal needs. I will not give a step-by-step guide here but point out the key steps. For further information read the documentation of 'opt' or ask in the AdNW mailing list when you get stuck. In my Anymak Github repo you also find a brief description of the commands I used to compare 27 layouts for 13 languages for this article. I provide the evaluation results, along with the input files, which allow you to recreate my results or adapt the config files to your personal needs.

The comparisons have to be seen in the context of checking the general suitability of a layout for multi-language use. They do mostly ignore diacritics. The aim is to give an indication if a base layout might be suited to be adapted (by adding the needed diacritics) to be used with a specific language. For further and detailed evaluation of these layouts the inclusion of the diacritics is necessary of course. Then those complete layouts need to be evaluated with the help of an accordingly configured analyzer and / or by practical evaluation. In the context of developing anymak:END I just wanted to see how robust a given layout is to be used for different languages.

The following screenshot gives a first idea how different layouts compare for English.

The paths you see here are the finger movements on the left and right hand. Thicker and stronger paths are displayed for the ways the fingers have to travel more often. In general, when you see less color and less crowded lines the layout likely feels better. This overview already gives an idea why anymak:END feels comfortable to type.

General considerations

Before I outline the optimization steps a word of caution. Do not try to rely too much on the software. It is an immense help and you definitely should not try to optimize a layout without software assistance, because you will never be able to take all the relevant parameters into account . But on the other side do not get hung-up to focus too much on the numbers for same-finger-bigrams and other parameters. Without conducting psychophysical experiments to determine how a specific finger movement can be rated in numbers and how different parameters are related, one can make a first guess about how to possibly rate the different properties. But it would be ridiculous to rely on those solely. To my knowledge the psychophysical experiments needed have not been conducted yet. This would require a research project to be set up, where people with different keyboard experience would need to participate. Does it mean the software evaluation is now useless? No, not at all. Just be aware that there is a significant amount of uncertainty in the numbers any layout optimizer will report to you!

My suggestion is to start with a weighting scheme, so the analyzer has a first idea how to rate the efforts for different fingers. But when evaluating the number output, I suggest looking at the different metrics separately and not trying to combine them to one single number. It is perfectly possibly to objectively describe isolated parameters of a given layout and compare those. For example, a lower number of same-finger-bigrams is better, a higher amount of hand alteration is better, a high ratio of inward to outward rolls is preferable and so on. But when you optimize for one parameter others will get worse. At a given point you need to try layouts and see what feels best — as long there is no foundation in how to correlate different metrics, this step cannot be skipped and should weigh more than the numbers an analyzer gives. The graphical output of 'opt' can be helpful here also, because to some extent it allows you to see how a layout will feel.

Optimization steps

1. Define what key arrangement you want to use and which finger to use for each key. Also define the key weighting. These and the used characters need to be defined in a config file, which 'opt' will use. When you want to follow my approach I took for anymak:END you can use my 'opt' configuration file on Github as a starting point.

2. Compile the source code for the wanted number of keys. On Windows I was finally successful in using the MingW g++ compiler (I provide the binaries on Github).

Side note: needing to compile different versions for a different number of keys is a major downside of 'opt' in my opinion. It would be much easier if one executable would be provided and the number of keys could be configured in the config file as well. Maybe Andreas or someone else can provide that one day, which would make the program more accessible. :-)

3. Gather the text corpus to base your optimization on. That can be done with a key logger or you can use existing databases. From those you need to create frequency files (see the 'opt' documentation). I used the database from University Leipzig to create the Dutch and most language files and used the English and German files which are already provided with 'opt'. You can either optimize different languages individually or give a weighting to combine several. In my case I used an equal weighting of a third for English, German and Dutch.

In addition, I used the key logger output to manually optimize punctuation and had a look at the most used numbers as well. In the end I kept the number row and did not find it worth changing that.

Sometimes a quick look about character frequencies can be interesting, for example to quickly double check for extra languages, without wanting them to include in the optimization run. STT Media has a collection of character, bigram and trigram frequency tables for many languages and offers free software to create own tables as well.

4. Either let 'opt' search for a new layout for your text corpus or use an existing layout and restrict 'opt' to optimize only selected characters / key positions. I tried both approaches, but found the better approach for my specific goals to start with the KOY layout and adapting that according to my requirements. I did that by manually changing characters (mainly swapping the inner index finger ones), but also by using 'opt' to search for alternatives for the relevant selected keys and characters. I always double checked each output numerically. But as important, I also tried to write sample text with a new iterated layout suggestion.

5. When I decided on a specific layout variation, I started to use that but kept thinking and trying other variations over time. In the end it took maybe a year, where mostly smaller iterations were made. One major change in between was when I decided to move the Shift keys to a more comfortable position and skip the B-key position on the standard keyboard (see second article).

6. Note that you will need a different config file describing the key arrangement for keyboards with a different number of keys. In my case I have one config file for a standard keyboard layout. A second config file describes the key arrangement used for Anymak. This also takes the different Shift-key position into account. It is possible to create config-files for any type of key arrangement. So, one could also create one for a columnar staggered layout. Because of the close relationship between a standard keyboard and an ergo keyboard (see part 2 of the article) I did not find it worthwhile to create different config files, when Anymak is used on a standard or ergo keyboard. The differences would only be seen in small weighting (and therefore effort numbers), but do not change where a specific character will be placed. Hand alternation, rolls, single-finger bigrams and more all stay the same.

Side note — dealing with unsupported features of the optimizer

When creating a config file and defining the key arrangement you possibly will run into the situation that the optimizer does not allow to describe every single aspect of your layout, such as additional layers and more. You need to decide if that is a crucial feature you need to describe your layout accurate enough. Or maybe you can work around analyzer limitations in a sensible manner. In my case I was able to use the optimizer, even when not all the features I would want are available:

1. 'opt' does not consider layers besides the base and shift layer. So, I was not able to simulate the German and Dutch diacritics (umlauts and trema), which I realize on the symbol layer. I worked around that by using a diaresis key on the right hand at the place where the symbol layer key is ('-key position on QWERTY). In practice I access symbols and the umlauts with the symbol layer key on the left or right side. Depending on the surrounding text I use different sides to enter the symbol layer — similar like choosing which Shift key to press, depending on the surrounding text. So, the reported finger paths of 'opt' are sometimes not used, but a hand alteration is possible. That means the actual layout is a tad better than the simulation reports. The influence of the umlauts on the evaluation is not that large although, due to the relatively low frequency anyway. It was easy enough to manually optimize the three umlauts and ß-character, by checking in which bigrams they appear mostly.

2. The pretty low frequency of umlauts also allowed me to put umlauts on otherwise pure English layouts, like Colemak or Graphite. This was a quick fix which allowed me to simulate other common layouts also with German, without the optimizer tripping over missing keys. The small inaccuracy when keys like hyphen or / are remapped to put umlauts on for the simulation only is typically not relevant, when comparing the overall performance of different layouts. For the most accurate comparison you will use the exact layout of course. But that can require different config files to be set up.

3. 'opt' does not support one-shot shift, so the shift collisions (same finger presses shift and then a character key following) reported are less critical in practice. Again, the layout is a tad better than the numbers tell.

4. 'opt' does not support key-combos or tap-dance keys (like long-hold). Because anymak:END does not rely on those for critical functions (text input), this lack was not a problem for me.

5. When comparing existing layouts, I used the ortholinear or angle-mod version when available. All layouts were evaluated with that fingering. Because I was only interested in the broad comparison, I neglect the (mostly) small inaccuracy (bottom left hand), when a layout is optimized for the traditional fingering instead. But that allowed me to shove all layouts in one evaluation file.

Evaluating graphical and numerical output of 'opt'

The optimizer can output a numerical evaluation but can also generate a graphical output. The combination of both is very helpful to understand the strong and weak points of a layout.

The graphics not only show the movements of fingers on one hand but also gives numbers of the frequency of the used keys, row jumps and so on. A line bowed to the top means inward movement of fingers. A line bowed to the bottom represents outward movement. The color coding of the graphic is as follows:

• pink: same finger bigram
• purple: neighbor finger
• light blue: finger skip - inwards movement (line to the top, start finger position in lighter color)
• dark blue: finger skip - outwards movement (line to the bottom)

The graphical output can be extremely helpful when you take the time to understand all the details it shows. The AdNW website explains how to interpret the graphical and numerical evaluation output. The English and German documentation supplied with 'opt' also has some information on how to interpret the results. It is highly suggested to read the documentation on the AdNW website to get most of the evaluation results.

The numerical output of 'opt' can be labeled with German or English. Here an example with English labels:

To get English labels the program needs to be compiled with the relevant option (see the English documentation of 'opt').

Below is an overview of the English and German evaluation parameter names. I also list if lower or higher values mark a better layout, of course for that single parameter only ;-)

• Total effort = Gesamtaufwand ( lower is better)
• Positional effort = Lageaufwand (lower is better)
• same finger rp (bigram ~ SFB) = Kollisionen (lower is better)
• hand alternation = Handwechsel  (higher is better)
• Inward/outward ratio of rolls = Ein-/Auswärts (higher is better)
• adjacent (neighbor) = benachbart (lower is better)
• no hand alternation = kein Handwechsel  (lower is better)
• seesaw like motion = Wippe (lower is better)

3. What makes anymak:END special?

To my knowledge anymak:END is unique in that way, that it was developed to have easy to reach layer keys for a shift and a symbol layer, which work with exactly the same finger positions on a standard and ergo keyboard. See the previous article, where I explain the Anymak layer concept. Typing with such an optimized layout will require the hand to jump around much less. You get a good impression watching the video examples of QWERTZ vs AdNW at ~80 WPM and 142 WPM mit dem K.O,Y Layout.

anymak:END offers a good balance between different requirements for a good layout, such as high hand alternation, many inward rolls, very few scissors, not too many same finger bigrams and so on. Last not least anymak:END works very well with multiple languages.

anymak:END layers

Here is an overview of the three main layers I use. Additional layers like a mouse or number layer for example can be added as you like.

+

The anymak base layer houses the END character layout. Umlauts or other diacritics are not realized on the base layer. They are accessed on the symbol layer. Either with a dedicated key or via dead keys.

It took a lot of thought, analyzing and practical testing to arrive at this alphanumeric layout to work well for all three languages. When you are using English, German or Dutch you should not mess around with the layout. The only keys which you might consider to change is swapping m and w. The analyzers will tell you that you will get a little bit lower same-finger bigrams (SFBs) that way. I have chosen the m-key to be on the stronger middle finger and tested the relevant bigrams and mostly prefer this choice. But depending on the language used and personal preference you can swap those two keys. Also, P and B could be swapped btw. The apostrophe on the base layer is a nice addition, especially for English. That key could be used for a dedicated é-key or another local character, dead key, or symbol you need often. Maybe you want to put the hyphen in that position? I personally use the hyphen in the number row or on the symbol layer (it is available in two spots). Or you can use that key-position for a repeat-key (which I never tried myself btw). The other keys on the base layer should not be changed.

An important, and for most other layouts normally not seen choice, is putting Shift and the keys to access the symbol / diacritics layer on easy to reach positions in the main 3x6 key block. Both Shift and the symbol layer keys are available symmetrically on the left and right side. This is important to allow a high amount of hand alternations. I find Shift a little bit more comfortable to reach than the symbol layer key, which is good, because of the many capital words you have to type in German.

For convenience, one key is assigned to ESC. This allows one-handed operation when using the mouse with the right hand. Another candidate for that key could be to put Enter there. Or you could keep the default Tab-function. All three of these functions are also available on the navigation layer as well. Even when I have ESC on my base layer, I normally access the ESC key on the navigation layer, because it is more convenient (see below).

Modifier keys are realized as bottom-row mods, via holding down the relevant keys (see illustration above). This is described in detail in the previous article.

The Shift layer is straight forward what you expect. The number row leaves most symbols on the standard position of the US layout. Just the = and + are swapped. The dot and comma key from the base layer become : and ; — similar like on a German layout. That makes the most sense to me. Feel free to assign symbols on the Shift layer matching your needs. A few key locations are free for assignments. Personally, so far, I have not needed to use every available spot.

The symbol layer has all brackets, some math, and other symbols. But it also houses special characters for local languages and diacritics. The positions shown here work well for me, but you can and should feel free to adapt them to your needs and tailor the symbol layer as it makes sense for your personal most used symbols and foreign characters. In contrast to the base layer, which you likely should not change, the "best" symbol layer is very much depending on the (programming) languages you use. Do you prefer a number layer? Which extra languages do you need to cover? Those preferences and needs will determine what is the best symbol layer for you. Some positions on the symbol layer shown as an example above are free and can be used for your local characters or extra dead keys you might need.

For easier reference, the graphic above also shows the shift-layer on the number row, which has some symbols and dead keys. Most are placed in the standard position. + and = are swapped, to allow easier zoom-in and out function.

The symbol layer also includes diacritics needed for German and Dutch on optimized key positions. Note that most of the umlauts are not placed on the corresponding key from the base layout. Putting them in that position would not be optimal for the typing flow. Because you only need a few umlaut keys they are not hard to remember and you will learn the position quickly. The locations chosen to make sure that the keys are easy to access in the context they appear. Depending on the characters before an umlaut you might also choose to access the symbol layer via the left or right symbol layer key. For most words you will likely use the right symbol key, resulting in a nice hand alternation. But for some words it is easier to use the left-hand symbol key to enter the layer. For example, for a word like "für" it is easier to type the ü-character as an inward-roll on the left hand. For other words like "Küfer" it is easier to use the right layer switch and then press the index-finger-key (would be i on the base layer) to create the ü-character. The ë and i trema characters sometimes used in Dutch are also implemented as a dedicated key on the symbol layer, even when they are not separate characters like the umlauts. The accent aigu is relatively common (for example for é) and is easy to realize (o-key in QWERTY notation, c-key in END notation).

Additional accents needed for French and Spanish are available as well. But personally, neither French nor Spanish are my main languages. I need the related characters only very infrequently. Therefore they do not get a prime position. In case you want to mainly type English and one of those two languages you might benefit from re-arranging the related accent keys.  In the graphic above some keys are donated with a 'd'. That shows that this key acts as a dead key. Some characters are available as a dead key and as a character key. For example, ^ has two positions, one to use as the power symbol and in another location to be used as a dead key for characters such as â.

In the layout overview you see that a single key can have double duties. I sometimes use the layer keys for Shift and symbols as a character key on another layer. For example, the right symbol layer key (apostrophe '-key in QWERTY) acts as a character key, when you are already in the symbol layer. I have assigned the [*] symbol to it, to complement the math symbols on this layer. You can either use the left-hand layer switch and then type the key on the right side. That is what you normally should do. But technically it also works to press the right symbol layer key twice.

The first tap will enter the layer, the second tap will fire the [*] character.

The navigation layer is mostly self-explaining. I have been using that setup now for a long time and it has proven to be very useful and very easy to use. I have described the navigation layer already detailed in the previous article.

In addition, I want to point out that there are many nice details in this navigation layer you might not spot at first sight. For example when using Alt-Tab and letting go the Alt-tab-key, but still keeping the space key held (to stay on the nav layer), will allow you to press the Close-Tab-key to close a window from the window overview. You can also navigate in the window overview and so on.

Shift is available on the navigation layer as a held layer switch, so you can use keyboard shortcuts on the nav layer in combination with Shift. For example, for marking the previous word you will hold down the space-key to enter the nav-layer, then in addition keep the left Shift-key held down (which is easy to do at the same time) and then press the key for Ctrl-LeftArrow. No worries, it sounds more complicated than it is in real life with a little bit of practice. :-)

I am very happy with the navigation and shortcut layer. But feel free to set up the navigation layer according to your needs and wishes. For example, some prefer the arrow-cluster to be in inverted T-form, while others like me have grown to like the Vim-style position.

anymak:END performance comparison

In the following you find numerical and graphical evaluations of anymak:END for English, German and Dutch and more languages. For reference I compare the layout to Colemak, Graphite and QWERTY.

General remarks on the evaluation numbers and graphics

The evaluation graphics give a good idea how a layout will feel in practical use. They show the finger paths of all bigrams. If you skipped section 2 of this article, you might jump back and just read the last section, with a short introduction how to interpret the graphics and numerical evaluation.

Note that you can only directly compare layouts created for the same key arrangement. The anymak:END-layout uses a different key arrangement with less keys, compared to a standard keyboard layout. When you compare a standard key layout (Colemak, QWERTY and all the others) to the Anymak-layout you will find that anymak:END will sometimes have slightly worse performance for some parameters, especially single-finger-bigrams. This is to be expected due less keys being available. This does not mean the complete layout would be inferior. It is important not to fixate too much on a single performance parameter. Instead, a good, balanced layout will need to consider several parameters. It is my impression that single-finger-bigrams are often overrated when comparing alternative keyboard layouts.

An example. In the layouts I evaluated for an English corpus Canary had only 0.9 % SFBs. anymak:END on the other hand has 1.7 % SFBs. You could see that as a bad result, almost twice as many. Does it make sense to say almost twice as many SFBs? Or does it make more sense to compare to QWERTY (6.6 % SFBs)? And you would state that Canary has 14 % SFBs and anymak:END 26 % SFBs in comparison to QWERTY. That shows that both are already a significant improvement of it!

Let us look at seesaws now. On the other side Canary has 7.2 % seesaws, while anymak:END only has 2.6 %. Here Canary has almost three times as many. Now the question is what is more important, SFBs or seesaws? We just do not know. 

What we also do not see in those numbers is what type of seesaws and SFBs we get with each layout in which frequency. Some seesaws are worse than others for sure. Also, SFBs can be quite different in how annoying they are. A same-finger bigram on a less precise and weaker finger (maybe the pinky) will be much more disturbing than one on the index or middle finger. Regarding the potential typing speed there is also a difference in which direction an SFB occurs. anymak:END has often a little bit higher SFBs than other layouts, but most of those are what I consider to be a "good" SFB. That means finger movements which are not that disturbing and do not cost that much extra time either. Let me explain: When an SFB is from the top row to the home row, you will lose less time than the other way around, because the finger needs to make the move back to the home row anyway. An example is ED or RF (in QWERTY).

A parameter like hand alternation can be compared directly between different layouts, regardless of how many keys they use. More hand alternation is generally better.

What about the difference in how a layout feels, how easy a key is to reach? Those two are related, but not the same. On a standard keyboard the top left row will always feel a bit awkward, because of the stagger. Yet the distance is short and, in that sense, easy to reach. You can try to express these findings in the weightings for a given key. But what are the values which really reflect and correlate linear (in the best case) with our perception? Again, we do not know. So those values are just a guess. A helpful one, but nothing more. Because anymak:END completely avoids the most uncomfortable key positions the calculated effort is significantly lower than for the standard layouts. For English that is an effort of 314 in comparison to 500 for the best standard layouts in that aspect (Engram) up to 756 for QWERTY. My typing experience over the years with both QWERTZ and now anymak:END is that there is a real comfort gain with the new Anymak-concept. But how far do those numbers tell us that?

The graphical evaluation is a great additional tool to try to better and quicker grasp the perceived performance, in terms of comfort, of a layout. You can directly see when a graphic looks crowded, which bigrams are most frequent and spot immediately if there are ugly two-row jumps or scissors. You also see which rows are used heavily. Likely most people prefer to us the home row most, then the top row and the bottom row least. But there are layouts like Handsdown Neu which favor the home and bottom row. Maybe for your specific keyboard that is preferrable? The graphics help to quickly understand a layout better in this and other regards.

But taking all the above-mentioned points into account I think it should become clear that any evaluation results should and can only be seen as a guide to judge different parameters against each other. To finally decide which layout is better in daily use for your specific needs and preferences will require you to try the layouts in the end.

Numerical evaluations — anymak:END vs others

Nonetheless, with that disclaimer out of the way let us have a look at some parameters for some common layouts for a few languages. The formatting in green for good and red for bad is automatically adjusted to each column of the table. The color does not necessarily reflect the practical importance of a parameter but just serves as a relative reference point inside the comparison group. Still, it should give us an idea which layouts are "worthy" to consider for further evaluation and practical testing.

English

For English we see that anymak:END, AdNW, Hands Down neu and KOY are pretty balanced. Graphite is also quite good but has a bit lower number of inward rolls. As discussed before anymak:END has a significantly lower effort than all other layouts, but a little bit higher same-finger bigrams (SFBs). I find it interesting that Colemak seems not that balanced, even for English. Middlemak NH, which uses a similar design philosophy seems more interesting to me. Neo and Noted perform not good enough IMO, considering they claim to be developed for English and German. QWERTY just sucks basically but has the most inward rolls. So, if you are looking for a roll-friendly layout you might stay with it. ;-) Just kidding. That shows that looking solely at a single parameter will not be helpful in finding a layout which feels comfortable and good.

German

The German evaluation is not that much different from English overall. I would say overall the most balanced layout is anymak:END. Here, they also have relative low SFBs, but still higher than the winners in that category. Overall AdNW, Hands Down neu, KOY and Graphite are surely also very good for German. What we do not see here are the patterns you have to type. For example, let us look at the very frequent bigrams ei and ie in German. AdNW has e and i on the ring and middle finger. That results in many rolls, both inwards and outwards on those two fingers. Many do not find that particular finger movement that comfortable. That was one reason to develop the KOY variant. These finger patterns are easily seen in the graphical evaluation below. A nice example how numerical and graphical evaluation complement each other. Graphite has the same "problem" for German like AdNW.

I do not try to bash Colemak. But as you see here: Colemak is not robust to be used with different languages. It performs pretty bad for German. Middlemak NH is quite a bit better in that regard.

Noted and Neo perform better for German than for English. Neo is still not that great, compared to the other more modern options.

Dutch

In Dutch are many double vowels. Here I find it remarkable how low the SFBs are with AdNW. It seems it can be a great layout for Dutch. Indeed, it would work mostly well, but there are some ugly bigrams hidden, which are not super frequent, but common enough to want to look for nicer options, jn is such a bigram I would not like with AdNW. Looking at the other layouts, anymak:END again is pretty balanced, with not the lowest, but also not super high number of SFBs. KOY would also work mostly well and the other contenders mentioned before can also be worth a look. That is just from the numbers. When you look a bit closer you will find that bigrams such as ij are not your favorite ones in some of the layouts, for example Graphite.

Spanish

French

For French and Spanish, which I personally do not use, the base layouts do not show something remarkably different than for the other languages. When you want to explore if / which / how one of those layouts can work with these two languages, these tables should give you a good first idea. anymak:END seems especially good for Spanish. You will need to make sure the diacritics are easy enough to access for daily use although. Overall AdNW is one of the layouts which are also especially robust to work with several languages. And if you do not mind the ei-bigram it is one of the best layout contenders in my opinion still today. Which proves the point that you can create a layout which is so good that further fiddling with it will change it but not result in a significantly better one.

To close, let us have a look at some graphical evaluations.

anymak:END - English

The finger paths in the graphical evaluation show a calm and nice flow, largely on the same row — often as an inward movement. The bottom row is used much less. You will later see that QWERTY, but even Colemak looks much different.

The anymak:END layout was developed on basis of the KOY layout. Some changes I made were to swap G-D and U-I, because I prefer the top row position of the index finger instead the one on the inner home-row position. This swap has an additional benefit. You get a nice inward roll for ou, which is quite common in English and other languages. In Dutch two relative common bigrams are oe and ui. These two are what I would call a "good" SFB, one that is not really that bad at all.

Colemak-DH - English

You see that the left-hand side of Colemak is pretty good. Not perfect. I would want a little bit less usage on the left bottom row, but it is ok. On literally the other hand, we see a very busy finger pattern. Also, the super frequent path from H to E is less than optimal. The standard Colemak variant has H on the inwards index finger. I personally prefer the DH-variant, but overall, I consider Colemak as outdated and not worth learning. But when you love it, embrace it. It is indeed better than QWERTY. :-)

Graphite - English

Graphite looks relatively calm as well. What you notice right away is the super common h to e pattern, which is an outward roll from the index to the middle finger. Not bad, but for such a common bigram I would prefer an even more comfortable finger movement. Also, ou is an outward roll, which would be nicer as an inward roll. Swapping the right and left hand would fix that and in the same way also improve the st roll. Of course, then some keys would need to be re-arranged and you would basically create a new layout. But Graphite surely looks like a solid option for English.

QWERTY - English

No comment on the performance of QWERTY. We know it is far from good. :-) But shown as a baseline for comparison. What you can see clearly are the crowded finger patterns, all over the place. Especially ni and ce stand out as ugly two-row-skip bigrams.

anymak:END - German

The graphics show more or less a similar calm finger pattern like for English. No frequent ugly bigrams to see. Not so great bigrams are ka and ak. But they are not too frequent, so it is not that bad.

Colemak-DH - German

For German Colemak shows roughly the same finger pattern like for English. Some areas are a bit better (H-key), while others are a bit worse (C-key). The heavy usage of the right hand, with many words being typed only or mainly on the right hand, does not feel good. My own Colemak-like layout was overall better for German than Colemak. But it still suffered from the very same right-hand overuse problem. That was the trigger for me to develop another layout, without any restrictions regarding key positions.

Graphite - German

Much of the comments for English also apply to German. Graphite looks it should mostly work good for German. But the bigram sc is not optimal. Also, ei and ie are ok, but not in the prime position, you want to have for those super-frequent bigrams.

QWERTZ - German

Again, for reference, as a deterrent ;-) For German the QWERTY layout (or here the German QWERTZ variant) is even worse than for English. You see that mostly in the numbers. The finger patterns do not differ too much between English and German.

anymak:END - Dutch

For Dutch there are no frequent bigrams which stand out as really hard to type. One of the less nice ones is jn. I tested to swap F and J. But F is in general more common for English, German and Dutch, so it deserves the better position. To my surprise I also found that the jn bigram is also a little bit more comfortable to type when the J stays on the outside position. So, win-win in that case.

anymak:END for other Latin languages?

To see if anymak:END might be suited for other Latin languages I ran the analyzer to test for 13 languages in total: Czech, Danish, Dutch, English, French, German, Hungarian, Italian, Polish, Portuguese, Spanish, Swedish and Turkish. As a reference I also ran the same evaluation for 26 common layouts, such as AdNW, Colemak, Dvorak, Graphite, Neo and many more.

These evaluations do not include the diacritics. For practical use with those languages, they would need to be added of course (see also the remarks in section 2). The goal of this evaluation was to get a general idea if anymak:END could be an interesting base layout to be used for the language being tested. If yes, one will need to add the diacritics or special characters on the symbol layer. And potentially a layout might benefit from some rearrangements of the base layer as well.

The result of the comparisons is that the base layer of anymak:END in the current form works well for the Nordic languages and the Neo-Latin (Romance) languages, such as French and Spanish. It seems less suited for Eastern languages or Turkish — at least not without some tweaks.

Here one example of anymak:END for Spanish. There are no really bad bigrams visible. But eu is used very often. It is ok to type in the layout, but not super comfortable. Maybe that could be improved? Still for a second or third language besides English it looks like a very usable option.

The complete set of evaluations, alongside the relevant documentation, is available in the Anymak Github repo.

Is it worth learning anymak:END?

Should you learn an optimized layout in general? The answer to that question largely depends on your personal start situation and your goals. When you type faster than 70 wpm I think in general it is not worth learning an alternative layout, when your goal is to gain speed. To increase typing comfort, it can be worthwhile although. But be aware that you will need many hours and typing training to regain your old speed or even get faster. I did not practice that much after I switched to the new layout and estimate that it will take two or three years to be back at full speed with no or little dedicated practice. When you input the time of daily practice you can regain your old speed quicker for sure, but even than it will take possibly half a year. When you are confident with QWERTY it will take a long time, till you gain the same confidence in your new layout. After about 1 1/2 years I typed without real problems in the new layout, but still not as effortless as after decades of QWERTY practice.

What are the pros and cons of anymak:END?

I think by now you know what the pros of anymak:END are. I think it is a great option, for anybody who has similar wishes to what I had, when designing the layout. Such as not overusing the thumbs, trying to avoid uncomfortable key positions, using both a laptop and split columnar staggered keyboard regularly. Or typing in English and one or more additional languages like German, French or others. I do not think the layout has really significant downsides and I consider it to be well-rounded and balanced. It can be even interesting for English only speakers for that reason. But maybe you are looking just for something else. You might prefer to have umlauts directly on your base layer and do not mind the less comfortable finger movements that this will result in. Or you want to use a letter on a thumb key. Or you have other wishes not covered by the Anymak concept. All valid reasons not to choose it.

Of course, using any alternative layout has some downsides. You have to be aware of those as well. Do you use other people’s computers extensively? Do you use programs which rely heavily on keyboard shortcuts you cannot or do not want to remap?

But summing it up: I personally think the biggest downside of an alternative layout is the learning curve. It just takes practice! On the other side using the SpaceFN concept to access a navigation and shortcut layer has practically no negative aspects, I think. Also adding (at least a one-hand) symbol layer with a held CapsLock-key (QWERTY notation) will almost always be worth it. When you decide not to learn an alternative layout, try to use these two options for sure!

What about ergonomics?

A final word regarding ergonomics. I do not believe that either a different keyboard or layout will cure health problems you might have with your hands. It is possible to use a standard keyboard with QWERTY in an ergonomic way, which will not cause hand problems normally. Get your keyboard (very) close to the edge of the table, find a good hand position and type with floating hands. That is the key in my experience. Does that mean columnar stagger keyboards are not worth it? No, absolutely not. It is nicer to type on a symmetrical keyboard. Also using an optimized layout is nice. Totally worth it in my opinion, but neither are a requirement to use a keyboard in an ergonomic way!

Do I regret changing the switch?

I personally am happy with the switch. For one I love to be able to use the laptop keyboard and my Lily58 with exactly the same and comfortable finger movements. A second motivation for this project was as part of a self-experiment for me. I wanted to learn how I can improve my learning experience, which I can then apply when practicing other skills, such as a musical instrument. :-)

4. Bonus — programs to rocket your computer efficiency

I find some programs very valuable to complement anymak:END or any other keyboard layout. They allow to input seldom used characters of foreign not actively used languages and handle text snippets and clips. I list program examples for Windows.

• Clipboard manager - Clipangel
• Text clips, including time and date stamps and more (Win, Linux, macOS) - Espanso, for use in Windows with Kanata use this build
• Systemwide instant search - Everything Not text related, but I use it so often that it got a prime key on my navigation layer.

	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

Published on Wed 5th Mar 2025. Featured in KBD #188.

Related

Rain2's year of keyboard design

Rain2, a newcomer to the keyboard community, reflects on this year's achievements, sharing how an addiction to keyboard design has taken hold.

Anymak - the compatible ergonomic keyboard layout

In part two of his series about increasing typing comfort, Peter introduces Anymak, the next step in balancing layout compatibility and ergonomics.

Closing down Pikatea - A Farewell

Jack and Bethany discuss their company history as they close Pikatea, their 5+ year keyboard and macropad store.

Connected: A tale of obsession over cables

David discusses why he started Kool Keys, and what making high end cables entails: the costs, equipment, trials and tribulations of being obsessed with making the perfect cable.

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.