precondition

QMK Heatmap Generator

2021-02-19T00:00:00+00:00

Show key presses coming from:

Use another matrix

Upload keyboard picture

Upload key log csv

What it is

This is a web-based tool to generate a pretty heatmap of your typing habits. As opposed to all the other available keyboard heatmap generators, this doesn’t merely analyse a static piece of text and overlays the letter frequency of said piece of text over a picture of the most basic row-stagger keyboard. This generator has full support for unprintable keys like backspace, modifier keys, caps lock, F-keys, arrow keys etc. Additionally, advanced QMK features such as layers, modtaps, layertaps, home row mods, leader keys, autoshift, and even combos are also supported.

Since QMK keyboards come in all shapes and sizes, you’re invited to upload your own picture of your layout/keymap. It doesn’t matter whether you use a TKL, an Atreus or a Dactyl Manuform; if it’s available on the QMK configurator, it’s supported.

Gallery

Instructions

The QMK Heatmap Generator expects:

A picture of your layout
A text representation of the matrix positions of your keyboard
A link between each key in the matrix to the corresponding key in the provided picture
A keylog CSV file in keycode,row,col,layer format (keycode can be omitted)

If you don’t have a keylog.csv file yet, jump to the section on “How to collect the required data”. It is pointless to go through steps 1–3 if you don’t already have a keylog.csv file that contains at least 1000 entries.

1. A picture of your layout

The first thing you need to do is to upload a picture of your layout. It can be any image you want but for best effects, I recommend a 2D black and white picture with high contrast. Avoid blue, green, yellow, and red in your layout graphic as those are used to draw the heatmap. If you don’t already have a graphic representation of your keymap, you can use keyboard-layout-editor or take a screenshot from the QMK configurator.

Avoid uploading a picture which separates all your different layers like in this example. You only get to match as many keys as you have submitted in the text box for the ASCII representation of your board.

2. A text representation of the matrix positions of your keyboard

Next, you can see a text box prompting you to paste the text representation of the matrix layout produced by qmk info --matrix, or qmk info -m in short. If you wish to obtain the pseudo-graphic layout for another board than your main (as defined by qmk config), you can run qmk info -kb -m. For example, qmk info -kb handwired/dactyl -m produces the following output:

Keyboard Name: Dactyl
Manufacturer: Unknown
Website: 
Maintainer: QMK Community
Keyboard Folder: handwired/dactyl
Layouts: LAYOUT_dactyl
Size: 17 x 8
Processor: atmega32u4
Bootloader: halfkay
Matrix for "LAYOUT_dactyl":
┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐                    ┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐
│0A││0B││0C││0D││0E││0F│                    │0G││0H││0I││0J││0K││0L│
└──┘└──┘└──┘└──┘└──┘└──┘                    └──┘└──┘└──┘└──┘└──┘└──┘
┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐                    ┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐
│1A││1B││1C││1D││1E││1F│                    │1G││1H││1I││1J││1K││1L│
└──┘└──┘└──┘└──┘└──┘└──┘                    └──┘└──┘└──┘└──┘└──┘└──┘
┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐                    ┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐
│2A││2B││2C││2D││2E││2F│                    │2G││2H││2I││2J││2K││2L│
└──┘└──┘└──┘└──┘└──┘└──┘                    └──┘└──┘└──┘└──┘└──┘└──┘
┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐                    ┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐
│3A││3B││3C││3D││3E││3F│                    │3G││3H││3I││3J││3K││3L│
└──┘└──┘└──┘└──┘└──┘└──┘                    └──┘└──┘└──┘└──┘└──┘└──┘
┌──┐┌──┐┌──┐┌──┐┌──┐                            ┌──┐┌──┐┌──┐┌──┐┌──┐
│4A││4B││4C││4D││4E│                            │4H││4I││4J││4K││4L│
└──┘└──┘└──┘└──┘└──┘                            └──┘└──┘└──┘└──┘└──┘
                        ┌──┐┌──┐    ┌──┐┌──┐
                        │5F││5A│    │5L││5G│
                        └──┘└──┘    └──┘└──┘
                    ┌──┐┌──┐┌──┐    ┌──┐┌──┐┌──┐
                    │5D││5C││5E│    │5H││5J││5I│
                    │  ││  │└──┘    └──┘│  ││  │
                    │  ││  │┌──┐    ┌──┐│  ││  │
                    │  ││  ││5B│    │5K││  ││  │
                    └──┘└──┘└──┘    └──┘└──┘└──┘

Only copy-paste the lines after “Matrix for …”.

Note: for a handwired board, there is the possibility that the actual wiring of your board differs from that of the matrix qmk info -m spits out. Double check that if you notice a key you rarely press gets colored in bright colors.

3. A link between each key in the matrix to the corresponding key in the provided picture

After pasting the matrix into the text area, left click on the picture the spot that corresponds to each key in the text matrix starting from the top left corner and moving from left to right, top to bottom.

Watch out for columnar staggered boards like the Lily 58. The web-tool reads in the matrix line by line so the following matrix:

            ┌──┐                                  ┌──┐
        ┌──┐│0D│┌──┐┌──┐                  ┌──┐┌──┐│5C│┌──┐
┌──┐┌──┐│0C│└──┘│0E││0F│                  │5A││5B│└──┘│5D│┌──┐┌──┐
│0A││0B│└──┘┌──┐└──┘└──┘                  └──┘└──┘┌──┐└──┘│5E││5F│
└──┘└──┘┌──┐│1D│┌──┐┌──┐                  ┌──┐┌──┐│6C│┌──┐└──┘└──┘
┌──┐┌──┐│1C│└──┘│1E││1F│                  │6A││6B│└──┘│6D│┌──┐┌──┐
│1A││1B│└──┘┌──┐└──┘└──┘                  └──┘└──┘┌──┐└──┘│6E││6F│
└──┘└──┘┌──┐│2D│┌──┐┌──┐                  ┌──┐┌──┐│7C│┌──┐└──┘└──┘
┌──┐┌──┐│2C│└──┘│2E││2F│                  │7A││7B│└──┘│7D│┌──┐┌──┐
│2A││2B│└──┘┌──┐└──┘└──┘┌──┐          ┌──┐└──┘└──┘┌──┐└──┘│7E││7F│
└──┘└──┘┌──┐│3D│┌──┐┌──┐│4F│          │8A│┌──┐┌──┐│8D│┌──┐└──┘└──┘
┌──┐┌──┐│3C│└──┘│3E││3F│└──┘          └──┘│8B││8C│└──┘│8E│┌──┐┌──┐
│3A││3B│└──┘    └──┘└──┘                  └──┘└──┘    └──┘│8F││9F│
└──┘└──┘  ┌──┐┌──┐┌──┐  ┌──┐          ┌──┐  ┌──┐┌──┐┌──┐  └──┘└──┘
          │4B││4C││4D│  │4E│          │9B│  │9C││9D││9E│
          └──┘└──┘└──┘  │  │          │  │  └──┘└──┘└──┘
                        │  │          │  │
                        └──┘          └──┘

will read keys in the following order:

Is it annoying? Yes. I’m currently working on a desktop app that makes this process a lot more convenient. In the app, you’ll be able to select a bunch of circles at once, copy, drag and paste them wherever you want, undo and redo previous actions and more, so stay tuned!

If you misclicked or placed the dot a few millimeters away from the true center of the keycap and it’s driving you mad, you can Shift+Left Click anywhere on the canvas to undo the last operation.

Click a final time on the picture after having matched all matrix positions to points on the image to save the matching pairs and finally spawn the button that will let you upload your keylog.csv.

4. Generating a heatmap

After having collected enough data in the expected format, you can now submit your keylog.csv file (the exact name of the csv file isn’t important) to the above tool in order to generate a pretty heatmap of your typing habits.

A heatmap overlay will appear over the keys as soon as you upload the file.

NOTE: Make sure the keylog file is encoded in UTF-8! Windows may create a UTF-16 file if you pipe the output of hid_listen.

How to collect the required data

To accurately modelize your typing habits, you first need to collect enough real-word data. The more, the better.

To avoid skewing results, don’t play typing games such monkeytype or typingracer while logging your keystrokes. Typing random strings of words and movie quotes isn’t a good reflection of your actual keyboard usage — unless you’re into competitive typing.

To collect key strokes data in the expected format, there are two things you need to setup:

Keyboard firmware
A program that logs what the keyboard firmware sends into a csv file

(The following instructions primarily cater to users of a UNIX environment — sorry Windows users.)

Keyboard firmware setup

First off, you need to program your keyboard firmware to send your desired information to the host.

To do that, append the following line to rules.mk:

CONSOLE_ENABLE = yes

Next, open keymap.c and add these lines at the top of the file. This will import the uprintf function that we’ll later use, but only if CONSOLE_ENABLE is turned on.

#ifdef CONSOLE_ENABLE
#include "print.h"
#endif

After including print.h, head to the process_record_user function (More info about this function can be found here) and write the #ifdef code block just after the function signature but before the switch statement:

bool process_record_user(uint16_t keycode, keyrecord_t *record) {
    #ifdef CONSOLE_ENABLE
        const bool is_combo = record->event.type == COMBO_EVENT;
        uprintf("0x%04X,%u,%u,%u,%b,0x%02X,0x%02X,%u\n",
             keycode,
             is_combo ? 254 : record->event.key.row,
             is_combo ? 254 : record->event.key.col,
             get_highest_layer(layer_state),
             record->event.pressed,
             get_mods(),
             get_oneshot_mods(),
             record->tap.count
             );
    #endif
    switch (keycode) {
    //...
    }
    return true;
}

This will print the hexadecimal representation of every key you press as well as its row and its column. Make sure to not leave any space between the commas and to end the string with a newline \n.

Additional instructions for combos

A guide to home row mods

2020-12-12T00:00:00+00:00

If you’ve been browsing mechanical keyboard communities, and especially the niche that is ergonomic mechanical keyboards, you may have come across the term “home row mods” and wondered what could that mean. Well, wonder no more for I shall explain!

Skip table of contents

What are home row mods?
Why use home row mods?
How to use home row mods?
Tips & Tricks
Alternatives
Summary
TL;DR Table

What are home row mods?

Let’s first deconstruct the term. The “home row” refers to the middle row of alpha keys. On an English QWERTY keyboard this would be ASDFGHJKL;. This row is called the “home row” because if one were to follow touch typing technique, this is the row of keys on which your fingers are supposed to rest on. The bars or the dish found on F and J help to find back the home position without looking at the keyboard — this is especially important for relatively big keyboards which require you to move your hands to hit some of the keys like for example Backspace or the arrow keys on a classic TKL and thus throw you off home position.

Homing bars

Next is “mods”. What is meant by “mods”? In this case, “mods” refer to modifiers, that is to say ⇧ Shift, ⎈ Control, ⎇ Alt, and ◆ GUI. The last modifier in the list is also known as WinKey on Windows, Command on MacOS or Super/Meta¹ on Linux and BSD. Do not confuse the term with actual graphical user interfaces.

So this means that “home row mods” are about placing modifiers on the home row.

How can that be possible? Does this mean that the home row letters/symbols swap positions with the modifier keys? Most certainly not! You see, one of the untapped potential of modifiers that are active as long as you hold them is that they don’t do anything useful when they’re tapped (i.e. pressed and released) on their own — a notable exception is the Win/Super key which opens the start menu on Windows and Gnome as well as Alt which pops up the menu in graphical apps — but thanks to software like QMK, we can turn these momentary switch modifiers into dual-role keys which act as modifiers when held but act as other keys when tapped. This allows us to make more with less.

The name QMK gives to this functionality is “mod-tap”. Mod-taps are a subset of dual-role keys. Other software which also implement this functionality call it differently. Therefore, we really should say “home row mod-taps” but in common parlance, “home row mods” is what’s always used.

We now know what home row mods are; it is the practice of turning the home row keys into mod-taps. We have yet to figure out why use home row mods.

Why use home row mods?

The reason why would anyone choose to use home row mods are quite simple. A keyboard is no longer used exclusively for text input. It is also used to navigate and operate a computer, launch programs, format text, execute macros, zoom in and out, change input language and so much more which goes beyond simply typing letters. Modifiers play a big role in those functions.

Obviously, typewriters did not have any of those functions. They could only type. The modifier keys that we use so much now were added afterwards, kind of as an afterthought, over the classic typewriter layout which plagues us to this day. It was decided to reduce the width of the spacebar in order to make space for the modifier keys that were needed for the computer age.

On some typewriters, the spacebar was ｒｉｄｉｃｕｌｏｕｓｌｙｗｉｄｅ.

As a consequence, you need to do all sorts of finger gymnastics in order to trigger keyboard shortcuts. Not only are you playing Twister with your fingers, you’re straining the weakest finger the most in order to hold the necessary modifiers.

This approach to keyboard shortcuts presents some biomechanical issues. These chords may require hyper-extending, hyper-flexing, or splaying the fingers, and may necessitate uncomfortable static muscular loads on top of awkward hand position, especially wrist deviation. All of which can lead to cumulative trauma disorders, as explained by Vern Putz-Anderson in his book titled “Cumulative trauma disorders: A manual for musculoskeletal diseases of the upper limbs”, published in 1988.

It is in your best interest to find a solution at the risk of maybe getting RSI and Emacs pinky one day. This is especially important for programmers as most of their keyboard usage isn’t actually typing symbols but triggering commands with a plethora of different keyboard shortcuts. Though any power user of any application, not just programmers in their text editor, uses keyboard shortcuts extensively.

Home row mods are about the best solution to this modifier problem. The fact that there are four modifiers, each coming with a left and a right version perfectly matches the eight fingers resting on the home row. We can put a modifier under each finger and mirror it on both hands.

Isn’t it great to have ALL the modifiers at our finger tips? No motion, stretching or strain required. This rapid access to modifier chords is very comfortable and allows to blend the execution of keyboard shortcuts in the typing flow, whereas it previously required a context switch to stop composing text, move the hands to the corner(s) of the keyboard, trigger the desired keyboard shortcut and then find back the homing position to continue touch typing text.

The other benefit of having all the modifiers lined up in a row and each dedicated a specific finger is that you can trigger ANY keyboard shortcut with ease. Ctrl+Shift+GUI+Alt, also sometimes called Hyper, is an insanity on a standard keyboard but with home row mods, it is trivial: just hold down the four fingers of your hand on the keys you’re already resting on. Dedicating a specific finger for each of the four modifier also greatly reduces the amount of repetitive motions your pinky has to execute for all the keyboard shortcuts. Home row mods are also advantageous for the thumbs, for it frees them up for something else like layer switches or even letters. In fact, home row mods and layer thumb keys are a perfect fit. It makes it very easy to chord layers and modifiers together without forcing finger contortions or same finger utilization.

Finally, home row mods (or variations of the concept which we’ll talk about later in the article) is (a part of) the secret sauce to making all those tiny keyboards without outer pinky columns that you’ve always deemed to be too small to be usable,… actually usable.

Are you convinced? If so, let’s now look at the how.

How to use home row mods?

Before we can talk about the technical implementation details, let’s briefly talk about the order of home row mods.

Home row mods order

How should you lay out the modifiers on the home row? You have multiple options.

To make this easier to understand, let’s agree on common terminology first.

Full Modifier Name	Abbreviation	Symbol
Shift	S	⇧
Control	C	⎈
Alt/Option	A	⎇
GUI/Win/Command	G	◆
No modifier/mod-tap	_	_

This means that the home row mods setup shown in the cover picture of this blog post can be written as ◆⎇⇧⎈__⎈⇧⎇◆ when using the symbols or as GASC__CSAG when using the 1-letter abbreviations. However, since the mod-taps on the right hand are symmetric to the mod-taps on the left hand, the right-hand can be omitted. Trailing underscores can also be omitted to finally produce the following notation: GASC/◆⎇⇧⎈.

Now that the semantics are clear, let’s talk about some interesting orders of the home row mods to give you some ideas for your own.

SCGA/⇧⎈◆⎇

If one were to transpose the standardized modifiers layout into a 1D line, this would be it. It might look familiar and thus potentially easier to learn but keep in mind that, aside from the Shift modifiers, all the modifiers now use a different finger than what you’re used to.

Highlighted modifier keys on a standard row-staggered TKL keyboard. When reading the left corner of modifiers from top to botton, left to right, we get SCGA.

Moreover, this is a poor allocation of the mods in regard to their frequency of usage. Assuming that you do not use Caps Lock or Shift Lock,² Shift is by far the most used modifier. It is generally unwise to let the pinky take on all this load. Although letting the pinky fingers deal with Shift is the option that will necessitate the least hand swaps when typing a string of capital letters. This order also positions Alt and GUI in an undeservingly good place. The index and middle fingers are the strongest of the four non-thumb fingers but Alt and GUI aren’t the most frequently used modifiers for Windows, Linux and BSD users.

GASC/◆⎇⇧⎈

This is the layout found in the cover pic of this article and what’s used in most of the examples. Compared to the SCGA order, this is much more reasonable in terms of using the strongest fingers for the most common modifiers in operating systems that are not MacOS.

Indeed, if you sort the four modifiers by their frequency in Windows and/or Linux, you will find: GUI < Alt < Control < Shift.³ The observant among you will have noticed that this does not stick with GASC/◆⎇⇧⎈. Why are Control and Shift swapped? There are multiple reasons that can justify this choice:

The index finger is the finger that is responsible for the biggest amount of alpha keys so if you use the index finger to hold Shift, you’ll have to swap hands if you want to type any of the six keys — or seven keys if you’re on a row-stagger board and you type C with your left index — that the index finger is responsible for. If you’re someone who would rather not have to swap hands too much when typing capital letters, this can be interesting for you. However, do keep letter frequency in mind. In most alternative layouts, the inner index columns are populated with infrequent keys while the home row middle finger keys are assigned very common letters such as “E”.
Putting Shift between Control and Alt is pretty nifty. It allows for easy chording of Ctrl+Shift and Alt+Shift (the most common combination of modifiers) by using adjacent fingers. That cannot be done with Shift placed on the index finger. Holding two modifiers that are one or two keys apart is not ideal.
Concurrently to a Shift mod-tap on the home row, one may also have other Shift-like keys which are used in lieu of the home row mod to capitalize letters like for example Caps Lock or a Shift thumb key. By doing so, the Shift home row mod-tap is generally only used in combination with other modifiers, most frequently Control and Alt. Consequently, in light of bullet point 2, its best place is in the middle finger column.
The position of GUI next to Alt allows for easy GUI+Alt+Arrows, a keyboard shortcut used in some DEs for switching between virtual desktops/workspaces. GUI gets put on the pinky as that’s generally the least used modifier (unless you use a tiling window manager which requires a lot of GUI keyboard shortcuts).
The index fingers already have to deal with all the mouse clicking and dragging on top of all those extra inner keys it has to reach for, so you may be tempted to give it a little bit of break by sparing it from holding down a key for all your Shift needs.

This works out great on ortholinear and vertically staggered keyboards but if you use a row-staggered keyboard, you may find that you’re suddenly unable to copy and paste one-handedly.

GACS/◆⎇⎈⇧

GACS is the order you come up with when you want to assign the most frequently used modifiers to the strongest and most agile fingers and the least frequently used modifiers to the weakest fingers. GACS is for those who reply to GASC’s bullet point 1 by saying that enabling a greater range of one-handed Ctrl+Letter keyboard shortcuts is more important than a greater range of one-handed capital letters you can type.

GACS is also, notably, the order used by the most famous QMK ergo layout involving home row mods: Miryoku.

A non-obvious advantage of having Shift on the index column is that it can help to minimize accidental capital letters when rolling keys. You can’t have accidental capital letters on inwards rolls if the last key you roll is pressed with the index finger. Obviously, that does not apply to outwards rolls but those are generally slower and it beats having Shift in the middle and risking it in both ways.

If you’re undecided, pick GACS/◆⎇⎈⇧, it is a solid choice.

CAGS/⎈⎇◆⇧

What if you use MacOS instead? The GUI < Alt < Control < Shift ranking is not representative of modifier usage in MacOS. It does not even use the right terms! A more appropriate ranking of modifiers by their usage in MacOS would be Ctrl < Option < Command < Shift. A home row mods order conceived with this ranking in mind would thus be CAGS/⎈⎇◆⇧. CAGS is to MacOS as GACS is to Windows/Linux/BSD.

Hopefully, these four examples give you a better idea of what goes behind the conception of an order in the way the different mod-taps are laid out on the home row. You have to account for modifier frequency, finger strength and agility but also the interplay between different modifiers and the impact of temporarily losing access to a column of keys when holding down a home row mod.

Naturally, this is not an exhaustive list of all possible permutations of modifiers along the eight home keys. In fact, changing the order isn’t the only thing you can do. You can lay out the mod-taps differently too. See the section on alternative home row mods layouts.

Even so, despite having written much about the different home row mods orders, in the end, it truly isn’t that important. Just pick one you like and roll with it. If you’re already used to a certain order, don’t let the above points convince you to change. When you’re starting out, the pragmatic question of how to lay out the modifiers on the home row might seem important but that impression is misplaced.

Implementation

For the best home row mods experience, I heartily recommend a QMK-powered mechanical keyboard. At the time of writing, QMK supports over 2935 keyboards! The greater part of which are DIY keyboards.

The following section will be about implementing home row mods in a QMK-powered keyboard with all the necessary settings to make it work well.

For those of you who do not have a QMK-powered board (or those who miss their home row mods when typing on laptop or on any other non-QMK keyboard), you will find a guide for implementing home row mods using KMonad just after this section on QMK.

Using home row mods with QMK

As previously said, the way to create a dual-role key is to use what’s known as a “mod-tap” in QMK. The mod-tap key, MT(mod, kc), acts like a modifier when held, and a regular keycode when tapped. In other words, this is what allows us to have a key that sends “a” when you tap it, but function as a Shift or Control key when you hold it down. Note that the fact that we’ve turned A into a mod-tap does not make it impossible to use keyboard shortcuts involving the letter “A”. You can still do Shift+A or Alt+A just fine. Although, depending on what modifier you decided to assign to A, you’ll need to use the opposite hand to combine that modifier with A.

Let me explain with an example. Let’s take the home row mod setup illustrated in the cover image of this blog post.

This setup, translated into code would look something like this:

MT(MOD_LGUI, KC_A), MT(MOD_LALT, KC_S), MT(MOD_LSFT, KC_D), MT(MOD_LCTL, KC_F),

MT(MOD_RCTL, KC_J), MT(MOD_RSFT, KC_K), MT(MOD_LALT, KC_L), MT(MOD_RGUI, KC_SCLN)

Or if one were to use the shortcuts documented here:

LGUI_T(KC_A), LALT_T(KC_S), LSFT_T(KC_D), LCTL_T(KC_F),

RCTL_T(KC_J), RSFT_T(KC_K), LALT_T(KC_L), RGUI_T(KC_SCLN)

As you can see in this example, A is a LGUI mod-tap. This means that tapping the key will produce “a” and holding it will activate the left GUI modifier. If that was the only GUI mod-tap in your keymap, this would make it impossible to trigger the GUI+A keyboard shortcut. This is where mirroring all the modifiers on the other hand comes in handy. If you want to do GUI+A, you’ll have to hold MT(MOD_RGUI, KC_SCLN), i.e. the semicolon key in our example, and tap MT(MOD_LGUI, KC_A), i.e. our A key.

In case you’re curious why LALT is used in place of RALT for the modifier of the L mod-tap key in this example, click here to jump down to the section on modifier handedness and possible gotchas with the Right Alt mod.

Tap Hold configuration settings

Configuring tap hold options is a strongly recommended step for using home row mods without pulling your hair. As such, a local QMK development environment is required since the online configurator currently does not support configuration settings. If you haven’t set up a QMK build environment yet, follow the steps outlined in this guide.

With that out of the way, here comes the most difficult part: understanding the different tap hold configuration settings.

I strongly advise you to attentively read through the official QMK documentation page on tap hold configuration settings.

Once you’re done reading through this link, come back here for a more detailed explanation of each tap hold configuration setting and their relation to home row mods.

Ignore Mod-Tap Interrupt

Default

Since QMK can’t read your mind, nor predict the future, it can’t decide between tap or hold in the moment when you first initially press down the physical key. Taps and holds both involve a key down event of the mod-tap key, so an additional event is needed to resolve the tap-or-hold decision.

In the case of default settings, the additional event is the release of the mod-tap key or the end of the tapping term, whichever happens first.

You can think of it like this: Been holding the mod-tap for more than the time defined in the tapping term? Activate the modifier. Pressed the key and then released it before the tapping term expired? That’s the QMK definition of a “tap”, send the letter!

As long as your fingers don’t linger on the keys for longer than the tapping term, you won’t get accidental mod activations.

The default settings are the recommended mode for home row mods.

If you read old posts about home row mods, you might come across comments urging you to enable IGNORE_MOD_TAP_INTERRUPT to use home row mods comfortably because the old default behavior of mod-taps was akin to “hold on other key press” but since QMK version 0.21, released in 2023 May 28, the default behavior has been changed and the now obsolete IGNORE_MOD_TAP_INTERRUPT option removed.

Tapping Term

The tapping term is an important concept to grasp for home row mods. As we’ve just seen in the previous section, the tapping term is what helps to tell tap and hold apart.

The tapping term, in and of itself, is a very basic thing to understand. It is simply a period of time expressed in milliseconds that the user has defined. A timer starts on every key press and constantly checks whether the tapping term for that key has expired yet or not. The timer stops when the key is released. It is good to note that each pressed key is tracked by a specific, different timer, so to speak. When you press A, a timer starts but pressing another key like O does not bump up the timer that got started when you press A.⁴

Since a tap is defined as the act of pressing and releasing a key within tapping term, the tapping term can be seen as the time window in which you need to release the key in order to register a tap. On the flip side, it can also be seen as the minimum amount of time a key must be held down to register a hold.

As such, a good tapping term that fits you is one that prevents accidental mod activations and keeps the intended mod activations snappy. It is a delicate balance.

The tapping term can be configured globally and per key to fit you. In general, people choose something between 150ms and 220ms, with the default QMK setting for the tapping term set at 200ms. Don’t be scared to increase or decrease your tapping term as you see fit.

For tips on configuring your tapping term and finding the sweet spot for you, click here.

That concludes it for the essential tap hold configuration settings for home row mods. Don’t try to use home row mods with an insane TAPPING_TERM. You’ll have a bad time if you do and will come out of it thinking that “home row mods are not for me”.

Apart from these options, you may have noticed that QMK offers more tap hold configuration settings if you’ve read the documentation linked at the beginning of this section — please read through those links if you haven’t yet. While non-essential, they can still be very useful and a better understanding of them can help you enable the settings that will prove beneficial to you.

Tapping Force Hold

Quick Tap Term

The first in the list and an important tap hold setting for home row mods is QUICK_TAP_TERM, or as I prefer to call it DOUBLE_PRESS_AUTO_REPEAT_TERM.

Over the course of normal computer usage, you will switch back and forth between typing and triggering keyboard shortcuts. When the modifiers are on the home row, sooner or later, you will feel the need to press a home row key to type a letter and then pressing that same key in order to activate a modifier. However, the default behavior for a quick tap followed by a hold is to auto-repeat the tapping function of the mod-tap.

This means that if you use LSFT_T(KC_L) for example and you want to type “camelCase”, you will end up with “camelllllllllllllllllcase” instead. The reason is that you’re tapping LSFT_T(KC_L) to get “l” and then immediately after, you’re holding that same LSFT_T(KC_L) key to activate Shift in order to type the capital “C” of “camelCase”.

This problem occurs because the second press of the mod-tap key happens before the QUICK_TAP_TERM initiated by the first tap of the mod-tap key elapses. As you can see, the name of the option is misleading because the option is not actually about quick taps but about double presses of the same key.

To avoid this problem, you should thus reduce the QUICK_TAP_TERM from its default value of TAPPING_TERM into a much smaller value, or even 0 to disable the auto-repeat feature entirely. This will have the effect of letting you activate the hold function instead, when holding a dual-role key after having tapped it. No more accidental repeats of the mod-tap letters when typing quickly!

Permissive Hold

Second in the list is “permissive hold”. It is an option that adds another way to trigger the hold function of dual-role keys.

Permissive hold activates the modifier when another key is pressed and released while the mod-tap is held, regardless of the tapping term. It means that this option allows the user to trigger a keyboard shortcut with a mod-tap key before the end of the tapping term.

Consider the following case:

Key	Status
`RCTL_T(N)`	Down/Press
`RGUI_T(O)`	Down/Press
`RGUI_T(O)`	Up/Release
`RCTL_T(N)`	Up/Release

In English, this is a situation where you’re tapping O while holding down N. It can also be called a “nested tap”. If all of this happens before the end of the tapping term, the output, assuming mod-tap interrupts are ignored, would be “no”. Contrast this to the scenario when permissive hold is enabled where the output would instead be Ctrl+O.

As you can see, the assumption here is that if the user taps another key while holding down one or more mod-tap keys, he isn’t doing typing rolls and as such desires to trigger a keyboard shortcut instead. The tapping term is irrelevant here.

Consequently, this option allows the use of home row mods with a tapping term that’s much greater than 200ms. Though, people with a high tapping term aren’t the only ones who can benefit from this option. Fast typists who are used to swift taps and rolls can enable this option for snappier mod activations and thus bypass the need to wait out the tapping term for the modifiers to take effect. It is particularly useful for Shift.

Owing to the fact that permissive hold is… more permissive in what counts as a hold, it makes it easier to trigger mods so unintended mod activations can happen if the aforementioned case is something you frequently do when typing normally. Depending on your typing style, permissive hold might do more harm than good.

As with many other tap hold settings, there exists a global PERMISSIVE_HOLD setting and a per-key option, aptly named PERMISSIVE_HOLD_PER_KEY. Consult the documentation to figure out how to enable and configure this setting.

Hold on Other Key Press

The underlying logic of “hold on other key press” is quite simple. Did another key get pressed while the user was holding down the mod-tap key? If that’s the case, this is a keyboard shortcut; apply the modifier on that pressed key. What if, instead, no key got pressed while the user was holding down the mod-tap? Well, if the user presses and releases a key by itself, without pressing any other key in between, it must mean the user wanted the tapping function of the mod-tap since there is no use to tapping a modifier key all by itself.⁵ Simple enough right? If you want to activate the holding function, just press on another key while holding the mod-tap key.

Here comes the problem with that approach if one were to use home row mods. We like to imagine typing as tapping a sequence of keys all on their own, in order. However, there’s quite some overlap between the press and release of each key. Especially so when typing at high speeds. When typing the word “no” for example, we rarely press and fully release N before pressing O. Try it! If you’re not a hunt’n’pecker, this is how you’re most likely going to type “no”:

Key	Status
`N`	Down/Press
`O`	Down/Press
`N`	Up/Release
`O`	Up/Release

Now imagine if N and O were both mod-taps — it would be the case if you use home row mods on Colemak like in the animation above. With HOLD_ON_OTHER_KEY_PRESS settings, this is bad news. Indeed, typing involves a lot of such rolls, where you press the next letter before having fully released the previous one.

For that reason, HOLD_ON_OTHER_KEY_PRESS is strongly discouraged for home row mods.

Retro Tapping

Remember how I said that there isn’t much use in pressing and releasing a modifier all by itself? Mod-taps (ab)use this property, but as it turns out mod-taps have the exact same property themselves. If you hold down a mod-tap for longer than the tapping term and then release it without having pressed any other key in between, your QMK keyboard is going to send a press and release event of the modifier to your computer; not too different from tapping a basic modifier key. If that seems wasteful for you, then let me introduce you to retro tapping.

When a mod-tap is held for a long time and released on its own, retro tap will activate the tapping function, after having released the modifier of the mod-tap.

To give an example, if you press and hold LGUI_T(KC_A) for longer than the tapping term and then release it by itself, the host computer that your QMK keyboard is connected to first sees KC_LGUI being pressed when you hold down the mod-tap for longer than the tapping term and then the host computer gets notified that KC_LGUI is released when you take your finger off LGUI_T(KC_A) on your keyboard. This is the default behavior for mod-taps held and released by themselves. What retro tap does is sending KC_A once KC_LGUI is released/inactive.

Retro Tap thus gives another way to trigger the tapping function of mod-taps. With this option, you can get away with a very short tapping term.

However, this particular example highlights a potential problem with retro tap. In many popular desktop environments, the start menu is brought up by tapping the GUI key. A user of this kind of desktop environment who would like to send “a” by retro-tapping LGUI_T(KC_A) would accidentally open up the start menu and type “a” in its search bar.

What if you use another way to bring up the start menu? You’ll still have a problem with the Alt key which is used for navigating through menus of graphical applications. You can avoid accidental pop-ups of the menu when retro-tapping the alt mod-taps by disabling the functionality in the apps settings. For example in Firefox, it can be done by going in about:config and turning ui.key.menuAccessKeyFocuses to false. Apps rarely offer the possibility of disabling Alt’s tapping behavior though.

The Alt and GUI modifiers aren’t the only problem, think of the mouse too. The firmware that’s running on your keyboard cannot tell that you have clicked or scrolled the mouse wheel while holding down a mod-tap key. All it sees is that you’ve been holding down a mod-tap for more than the tapping term and released it without pressing any other key in between. As we now know, this is the cue for the firmware to activate the tapping function of the mod-tap in question if retro tap is enabled. Ctrl+Left-Click to open a link in a new tab or Shift+Scrollwheel to scroll sideways would thus be accompanied with unintended letters.

To counteract this, QMK lets you define a DUMMY_MOD_NEUTRALIZER_KEYCODE in config.h that will get sent in between the register and unregister events of a held mod-tap key. That way, the programs on your computer will no longer interpret the mod suppression induced by retro-tapping as a lone tap of a modifier key and will thus not falsely trigger the undesired action.

Naturally, for this technique to be effective, you must choose a DUMMY_MOD_NEUTRALIZER_KEYCODE for which no keyboard shortcuts are bound to. Recommended values are: KC_RIGHT_CTRL or KC_F18. Please note that DUMMY_MOD_NEUTRALIZER_KEYCODE must be a basic, unmodified, HID keycode so values like KC_NO, KC_TRANSPARENT or KC_PIPE aka S(KC_BACKSLASH) are not permitted.

By default, only left Alt and left GUI are neutralized. If you want to change the list of applicable modifier masks, use the following in your config.h:

#define MODS_TO_NEUTRALIZE { , , ... }

Examples:

#define DUMMY_MOD_NEUTRALIZER_KEYCODE KC_RIGHT_CTRL

// Neutralize left alt and left GUI (Default value)
#define MODS_TO_NEUTRALIZE { MOD_BIT(KC_LEFT_ALT), MOD_BIT(KC_LEFT_GUI) }

// Neutralize left alt, left GUI, right GUI and left Control+Shift
#define MODS_TO_NEUTRALIZE { MOD_BIT(KC_LEFT_ALT), MOD_BIT(KC_LEFT_GUI), MOD_BIT(KC_RIGHT_GUI), MOD_BIT(KC_LEFT_CTRL)|MOD_BIT(KC_LEFT_SHIFT) }

Retro Shift

Retro Shift builds upon the functionality of Retro Tap in order to marry Auto Shift with mod-taps.

Retro Shift lets you get the shifted state of a mod-tap by releasing the mod-tap key past the end of the tapping term, in a similar fashion to Auto Shift which emits the shifted state of a basic key if it’s been held down for longer than the AUTO_SHIFT_TIMEOUT.

With Auto Shift and Retro Shift, you can confidently eradicate all Shift keys from your keymap.⁶

In case you’re worried for the flaws that plague Retro Tap to be present in Retro Shift too, don’t be. As the docs say, “if RETRO_SHIFT is defined to a value, hold times greater than that value will not produce a tap on release. This enables modifiers to be held for combining with mouse clicks without generating taps on release.”

That is it for all the available QMK tap hold configuration settings. In summary, there is only one essential tap hold setting: TAPPING_TERM. Even then, chances are that you won’t even need to tweak it since the default value will suit most users.

Aside from that, there exists another very commonly recommended setting: QUICK_TAP_TERM. Don’t be misled by the name, it is not about quick taps but about the behavior of the key if you double-press it within a certain time window. It is recommended to set it to 0 or another very low value.

PERMISSIVE_HOLD can be useful if you have a very high tapping term. If you have a lower tapping term, PERMISSIVE_HOLD generally produces many misfires unless you’re very consistent in your typing style so it is not recommended.

Though, it is nothing in comparison to the amount of misfires you’ll get with HOLD_ON_OTHER_KEY_PRESS. Home row mods are pretty much unusable with that option.

As for RETRO_TAPPING, it might appear appealing at first glance but it has its load of problems which make it unsuitable for home row mods.

Getting started with home row mods on QMK

Armed with all this knowledge, we can now add home row mods to our keymap and flash it onto our board.

Let’s start with tap hold configuration settings. Copy and paste those lines in your config.h file (create the file in your personal keymap folder if it’s not already present):

// Configure the global tapping term (default: 200ms)
#define TAPPING_TERM 200

// Enable rapid switch from tap to hold, disables double tap hold auto-repeat.
#define QUICK_TAP_TERM 0

Once that’s done, open up keymap.c, and convert all the home row keys into mod-tap keys. You have multiple options for doing so. In any case, it is best to use aliases as the convention is to keep all keycode names strictly under 8 characters long in order to keep a tidy, aligned and readable layout in the keymap.c file. This is not possible if you use something like MT(mod, kc) or LMOD_T(kc). For example, potential aliases for US QWERTY with GASC/◆⎇⇧⎈ order could be:

// Left-hand home row mods
#define HOME_A LGUI_T(KC_A)
#define HOME_S LALT_T(KC_S)
#define HOME_D LSFT_T(KC_D)
#define HOME_F LCTL_T(KC_F)

// Right-hand home row mods
#define HOME_J RCTL_T(KC_J)
#define HOME_K RSFT_T(KC_K)
#define HOME_L LALT_T(KC_L)
#define HOME_SCLN RGUI_T(KC_SCLN)

If you feel like HOME_letter is too vague, nothing prevents you from doing something like this:

// Left-hand home row mods
#define GUI_A LGUI_T(KC_A)
#define ALT_S LALT_T(KC_S)
#define SFT_D LSFT_T(KC_D)
#define CTL_F LCTL_T(KC_F)

// Right-hand home row mods
#define CTL_J RCTL_T(KC_J)
#define SFT_K RSFT_T(KC_K)
#define ALT_L LALT_T(KC_L)
#define GUI_SCLN RGUI_T(KC_SCLN)

Note: Do not redefine SFT_T because you have a Shift/T mod-tap. SFT_T is already in use in the core QMK code as an alias for LSFT_T(kc) and redefining it in your keymap will produce compile errors. You’re advised to use #define SHFT_T LSFT_T(KC_T) instead.

Afterwards, it’s just a matter of replacing all the basic KC_letter situated on the home row in the LAYOUT of your keymap.c with the mod-taps aliases you’ve defined.

Home row mods code generator

For your convenience, below you can find a form that you can fill in with your options in order to generate mod-tap aliases and the home row.

Additional information

Pressing E with the thumb‽

2020-08-06T00:00:00+00:00

Did you know that the letter “E” is the most common letter of the English language by a fair margin? It’s second only to space. Such an observation can also be made for the majority of European languages.

Source of the diagram. Click on the picture to enlarge it.

Now, consider the fact that from the dawn of typewriters to our days, both thumbs have been historically assigned a single key, the most important key: the spacebar. While, it’s certainly a sensible choice to let the strongest finger(s) deal with the most commonly pressed key on the keyboard, chances are that you mostly only use one of your thumbs to press the spacebar. A wide spacebar has the benefit to give the users a choice on which thumb to use. Some people always use the same thumb while some others alternate between the thumbs, using the left while gaming and using the right while typing. Meanwhile, you can also find people doing away with the thumb altogether and using the index for space instead. In any case, past some time, your spacebar is most likely going to look like this:

You can sense what I’m getting at. This is wasteful, why not let the second thumb press the second most commonly pressed character? That would certainly balance the load between your strongest digits.

Moreover, this is not the only advantage of putting E on the thumb. Naturally, as the most frequent letter, “E” is present in most common n-grams. This makes it hard to place “E” on the keyboard without increasing same finger utilization. A common strategy used by most alternative layouts is to isolate “E” (and other vowels in general, as vowels may be followed by any consonant whereas groups of consonants are rare) by putting punctuation and/or rare consonants around it. What better way to isolate “E” than to put it on the thumb?

Balanced load and greatly reduced SFU is not all! The use of thumb keys extends the amount of home keys, the keys that each of your fingers rest on, in idle state. By placing “E” on a thumb key, you gain one free home row position and any touch typist knows that the home row is prime real estate. By extension, this also widens the range of easily reachable keys on the base layer. This is great for other languages whose alphabet is extended with accented letters. For example, in French, the letter “é”, e acute, is more frequent than “v”, “h”, “g”, “f”, “b”, “q”, “j”, “x”, “z”, “y”, “k”, and “w”¹ and yet is never put into the main alpha block as opposed to all the aforementioned letters (one notable exception is the Bépo layout and all its derivatives). Aside from accented characters, one can also put punctuation, additional frequently used symbols or even a macro like a dedicated “th” key if you really want to be fancy — the digraph “th” is the descendant of what used to be a standalone letter in the English alphabet, the “thorn” (Þ, þ), after all!

Obviously, this requires to do away with big, long spacebars but these have been around for the longest time and are most likely going to stay that way into the future despite the historic trend towards smaller and smaller spacebars.

This is probably why, despite the long history of typing machines, the idea of putting E on the thumb is quite novel and rather alienating to most typists.

It wasn’t until 19 May 1977, when the Maltron Mark II layout, pictured below, first appeared, that a keyboard layout was designed to use thumbs to input letters.

If you’re interested, you can read the introductory paper of the Maltron layout here.

However, there are, in fact, plenty of keyboards featuring E on their thumb keys which predate the Maltron Ergonomic Keyboard but it requires stretching the definition of typing. Typing consists in hitting individual keys to express individual letters but there exists other forms of text input such as machine stenography. Stenography has long been used to write at over 200 words per minute, faster than most people speak, with the use of chords on special stenotype machines with extremely light actuation force. Most stenographic theories put E alongside other vowels on the thumb keys. You can learn more about stenography here.

The stenotype machines pictured below were all made between 1889 and 1963, much earlier than the Maltron.

Outside of steno though, the adoption of letter thumb keys is nearly null. That can mostly be explained by path dependence and hardware limitations.

We all know that QWERTY is here to stay and that most people can’t be bothered to learn a new keyboard layout and those who do quickly face hardware limitations which prevent them from giving exotic keyboard layouts a spin. We’re thankfully past the days when Kinesis and Maltron were the only available choices for keyboards with a thumb cluster but despite the rise of DIY ergonomic mechanical keyboards, getting your hands on an ergonomic keyboard is still cost-prohibitive.

Consequently, since the (potential) user base is so small — “small” is an understatement —, there aren’t a whole lot of Malt-like alternatives (for the sake of argument, “Malt-like” merely means any layout which puts a letter on a thumb key). Despite the odds, there are Malt-like layouts out there, all very recent.

Logical layouts/keymaps which add E on the thumb:

RSTHD
Malt ++ (link in German)
ZenTron
Opuiany
FR-Godox (link in French)
ANISHTRO
TRIA

Logical layouts/keymaps which add another letter (circled) on the thumb:

BEAKL Zi I
BEAKL P_RN P R N
BEAKL QIEA H
X6.2h H (and all the other funky layouts made by Ian Douglas of the ergolinear X family)
Einbinder Orthogonal
Einbinder 1975
BEAKRAK T (link in Japanese)
ENNe 9640PM T
Marsan C G (link in French) (this one is absolutely awful. there is no space key, you have to move that little stick under àÀ from right to left with your left thumb for space, everything is wrong with this “ergonomic” keyboard but I had to include it for completeness sake)

This short list will be exhaustive — leave a comment if there’s a Malt-like layout I’ve missed! — if we add in my mod to Colemak-DHm which moves E on the right thumb key like TRIA, as opposed to all those other layouts which put the letter on the left. I’ve always pressed space with my left thumb and I’m not going to change that habit any time soon. Additionally, E was on the right hand to begin with so it makes sense to keep it on the right hand.

I had recently learned and become fluid in Colemak-DHm and, while I was curious to try out E on thumb after @frogmouth brought up the topic of RSTHD on the splitkb.com Discord server, I wasn’t too fond of the idea of learning a totally new layout right after having gotten comfortable with Colemak. Later maybe, but not now. Despite these qualms, I still like experimenting with keymaps.

Thus, I went ahead and replaced the classic E position with merely shift (since I am using home row mods, the topic of a future blog post). At first, I wanted to keep backspace on the right home thumb position so I put E on the key to the left of it but I very quickly understood that this was a bad idea. The thumb key in question isn’t the most comfortable thumb key to hit and required lateral movement plus a repositioning of the thumb on its home position. For some reasons, my thumbs aren’t as good as my other fingers to find the home/resting position again so that E position was problematic. The solution would thus be to put E on my home right thumb key but I didn’t want to let go of backspace so I came up with another bad idea, magnitudes worse than the previous one. What if I turned the right thumb key into a dual-function key which yields “E” on tap and backspace on hold? Needless to say, it was impossible not to overshoot backspace like that.

Finally, I let go of my attachment to backspace’s position and let E take its place, pushing backspace to the left key, the previous position of delete. At this point, the right thumb cluster looked like this:

Now, it was time to figure out how long it would take me to get back to ~80WPM using only the thumb for “E”.

After merely a few minutes of practicing E on thumb using the terminal application “wpm”, I had already reached 57WPM for some sentences.

It didn’t take long to break through the 65WPM mark.

Then, I figured that I do not need to practice sentences with punctuations and capitalisations so much as I need to practice words containing “e” so I moved to monkey-type.com. Only 32 minutes had passed since I flashed my keyboard with E on thumb and I am already getting real close to my goal of 80WPM.

At that point, I took a break and after a full day spent without any keyboard (or computer for that matter), I went back to my typing tests. This is when I reached my goal.

In fact, I even surpassed my goal.

Despite all that, I still wasn’t fully used to E on thumb yet. More often than not, I was still hitting the previous position of E. The screenshots I’ve shared here are the results of successful sprints, they do not really reflect the casual typing speed. Disclaimers aside, this still goes to show that it’s actually not so hard to get used to E on thumb, it has only taken me a few hours to get to an acceptable speed.

However, I still was not wholly convinced by the E thumb. It’s certainly nice to have a balanced load between the two thumbs but the rolls don’t feel as satisfying. Colemak wasn’t designed to take advantage of thumb keys.

Take for example the sentence “The enter key”, here’s a side by side example of writing that sentence using the two keymaps. Tapped keys are highlighted in yellow and held modifier keys in orange.

I am no carpalx scientist but the classic DHm layout fares better in my opinion.

The way I adapted Colemak to use E on thumb is only one way, there are many other potentially better ways to implement it. Colemak mods probably can’t beat keymap layouts designed around this peculiar arrangement though.

In the end, I gave up on the E thumb. If it weren’t for the fact that it didn’t feel right in conjunction with Colemak and that I’ve since moved to using the Backspace key extensively in combos for my hybrid steno setup (more on that topic in another upcoming article), I would have certainly kept on using it as I find the idea very sound.

The most important is that the people who have gone off the beaten path and dared to learn this exotic, ergonomic design are happy about it:

I’ve tried e on thumb with RSTHD and I think it’s the way to go. It will take me time to get used to it, though so I’ve put that particular learning curve on hiatus for the near future as I’ve been a bit busy. Things I like about it:

Remove all conflicts in bigrams with e for free

Reduce the size of the rolls for less fatigue

Gain one free homerow position

Gain one free of the next priority position etc. until where you put your backspace

It feels like a lot of gain. — @pierrec about RSTHD

I like it. But I haven’t spent any time learning other layouts. It does lead to a different feel on both hands, although I’m not sure that’s any different from any other layout.

I’ve tweaked mine so the left hand fingers are used slightly more than the right, and when the whole hand is taken into account the right is used more. I think this is good, some other (ergo) layouts like modDH are all on the right. It also can give you very low SFU. However it’s not just a matter of moving something to the thumb, everything interacts, just moving a letter can lead to other issues.

The downside of course is that you have used a thumb key that might otherwise have been available for a mod or layer shift. When you look at what happens in the analyzer this can mean more thumb movement if you’re not careful, which penalizes the layout. Some of this is guesswork as the analyzers (that I’ve seen) don’t have great support for layers, the patorjk one and derivatives have a start at it with AltGr so might be a good starting point for adding more.

I was going to say that if someone wanted to try it, the best thing would be to just put either RSTHD or Malt in your keymap and give it a go to get the feel of it. However it’s not as straightforward as trying other layouts because whatever is on the left thumb key home has to move somewhere else. Also, you do need space on right thumb home and enter next to it (or possibly, shifted, I haven’t tried that yet) — @frogmouth about RSTHD

Qwerty 30+ years to Dvorak about 5 years ago. Then moved from a staggered to a premade ortho about 3 years ago. Coffee spill killed that, so back to the old staggered while waiting for the Kyria to arrive. This is all to let you know my fingers have been confused for a while now.

My thumbs are not my smartest fingers but thumb E, in use is fantastic. It’s used so often but dedicated to its own thumb. Really a great follow through.

The efficiency change from Qwerty to Dvorak was noticeable. I already feel that same sort of improvement in moving from Dvorak to RSTHD. I have no idea if I will ever change again, I don’t really see enough room left to make another leap this size in efficiency. In general, RSTHD feels much more efficient, and my RSI pain issues are reduced too.

Time will tell if I can see a speed increase too. >60WPM is fast enough for my cares, though, so speed is not a driving factor for alternate arrangements.

If you are currently using Qwerty, it is in your best interest to find a better option. — @BiggerCryptoRoi about RSTHD

RSTHD is good, and I highly recommend it. I’m on day 5 and have broken 60 wpm after 2 hrs of 1 minute typing tests. It’s very comfortable, and it feels like the workload is spread evenly between your hands. E on the homerow takes some getting used to, and the punctuation sitting in and amongst the letters is kind of unusual, but it doesn’t get in the way at all.

Seems that Colemak can type 827 words with the homerow, about 0.37% of all English words, whereas RSTHD can do 1323, which is around 0.6%. I guess that’s because you have the E on the thumb, which I’m counting as part of the homerow too

Anyway yeah, long story short, typing requires very little effort because you barely need to move your hands. — Anonymous about RSTHD

Using thumb for a common letter vastly improves finger balance across the board; it helps with other languages too, in contrast with Colemak that sometimes has, for example, underutilized ‘wrx’ column or overloaded right index finger.

The main point around Colemak (and similar layouts) is the so-called rolling, i.e., using adjacent fingers of the same hand in sequences. Well, Maltron is the original layout based on this idea; but it also relies on the keyboard’s columnar physical layout: offset columns as an adjustment for shorter/longer fingers, especially little fingers. “Ortholinear” layouts lack this feature, though. That’s why I recommend at least Atreus, or better something like Dactyl-Manuform. — /u/Schemik about Maltron

Have you ever used such layouts? Would you be willing to try it out, or is that too weird for you? Share your thoughts!

Updates Log