Shift Typing

This article introduces shift-tutor, a Linux program that filters shift key events to improve or verify touch typing skills.

Rationale¶

Most keyboards contain two shift keys, i.e. one located on the left bottom and the other on the opposite side:

Source: Mliu92, ANSI US QWERTY (Windows, split + rotated), CC BY-SA 4.0

The purpose of these arguably redundant keys is to simplify shifting while touch typing. For example, when typing an upper case 'A' the left hand should press the 'A' key with the little finger, i.e. which doesn't leave the home row, while the right hand is free and thus its little finger can easily leave the home row and press and hold the right shift key, before.

A typist unskilled in touch typing may be tempted to enter upper case characters with one hand, like a short cut that involves a singular meta key. In our example, this may lead to upper case 'A' being entered by pressing left shift with the left little finger together with 'A' being pressed by the left ring finger.

The Problem¶

When touch typing, underutilizing both available shift keys may lead to the following problems:

1. suboptimal touch typing performance in terms of speed and effective use of muscle memory
2. health issues such as repetitive strain injury

A Solution¶

When attending an on-site course in a touch typing school, a good teacher may be able to observe suboptimal usage combinations of the shift keys and give immediate feedback such that this bad habit is eliminated.

This is similar to a presentation coach who watches out for filler words, perhaps rings a bell when a filler is uttered and/or counts them such that the student can pay into a filler word piggy bank.

In other words, in these cases, a teacher supervises a student and gives immediate feedback to reinforce optimal behaviour in order to improve the learning outcome.

Shift-Tutor¶

Shift-tutor is a technical aid that can be used while learning touch typing or for verifying touch typing skills. It simply grabs all events of a keyboard device on Linux and filters (i.e. discards) key presses whenever the wrong shift key is pressed. All other events are simply forwarded.

In that way, the typist gets immediate feedback on shift key usage, i.e. since something like left_shift + a is discarded, the better usage of right_shift + a is reinforced.

Shift-tutor is written in Python, doesn't require much code and is arguably easy to extend. Thus, triggering some annoying bell whenever a suboptimal key combination is pressed (in addition to discarding it), like in a positive punishment operant conditioning scheme is left as an exercise to the reader.

What about Latency?¶

Since keyboard events are filtered in user-space, such filtering as implemented by shift-tutor increases input latency somewhat. That means in the best case shift-tutor requires 2 kernel-/user-space transitions and a few cycles in user space which adds a few microseconds or so.

Depending on the load and available cores, waking up shift-tutor might even require a more expensive rescheduling or context-switching that would increase the latency more.

However, over the years local input-to-display latency increased to the three digit millisecond range with modern computers and modern keyboards being in the two digit millisecond range already (see also R. Wimmer, A. Schmid, and F. Bockes: On the Latency of USB-Connected Input Devices. ACM CHI 2019 and S. Liu, and M. Claypool: EvLag - A tool for Monitoring and Lagging Linux Input Devices. ACM MMSys 2021).
Meaning, when measuring end-to-end input-to-display latency under active shift-tutor, the added latency would likely be indistinguishable from measurement noise, as with - say - tmux.
Not speaking of additional relatively high network latency when working remotely via ssh, without local echo, which nevertheless usually still allows for a quite fine touch typing experience.