Show your hands honor for the power they bring you

Show your hands honor for the strange power they bring you

Comments

Marcin Wichary
18 June 2026 / 7,700 words / 38 playgrounds

On designing finger-friendly interactions

A hundred or so years ago, there was a problem. People were simply typing too fast.

I know what you’re thinking: they were typing too fast for the primitive typewriters of that era. But contrary to popular belief, typewriters were never that primitive. You could type really fast on even the first popular typewriter, and the QWERTY layout was actually designed to allow you to do just that.

No, people were typing too fast for what we thought our bodies were capable of. With our understanding of neurons travelling inside our brains, processing of the senses, and physical capabilities of the fingers, typists should have maxed out at just above 40 words per minute. They routinely did 70 words per minute or more.

It turns out, fingers are time travellers. At any given moment, each one is living in a slightly different time – as one finger is moving down to press a key, another is already travelling to the next one, and your brain is thinking of a few keys in advance, visualizing your hands moving to the right place. None of this requires touch typing. What we eventually called overlapping happens even if you reside at the awkward intersection of “hunt” and “peck.”

Overlapping is a small miracle happening in front of your eyes, and it happens pretty much to everyone. Also, it’s far from the only miracle. Our hands are amazing, our fingers are amazing, and our brains are amazing, too. Altogether they are capable of feats that not so long ago made absolutely no scientific sense – and sometimes still don’t today. Artists and performers have known that intuitively for centuries.

Today, a lot of creativity and productivity happen onscreen, but our interfaces do not often respect the fingers the same way older instruments did. I want to tell you more about it, and about your responsibility, as a designer, to make sure they do.

The early lessons in optimism

This is an interactive essay. You can turn off the sound, keep track of your tasks, or navigate using the menu at the top of the screen. Your progress will be saved between sessions.

When computers were refrigerator-sized machines hiding in rooms humming with the best of 1960s air conditioning technology, any interaction with them was appropriately cold: the only contact they allowed was remotely, via a terminal. A terminal was a desk computer with the expensive parts taken out. It had a bad CPU, little memory, and scant logic. Early on, it had no screen either, and used a printer or even a typewriter as its human-facing interface.

Given these limitations, the simplest way to build keyboard operation was this: each keystroke had to travel all the way to the big computer via a slow modem, and only its echo was printed when it came back to you, after The Machine confirmed its arrival. That roundtrip created a delay. That delay made typing extremely unpleasant:

• Typing with a slow echo – Click into the input field and type your full name

It was sometimes even more unpleasant than what you experience here: an ear-piercing beep or, on top of that, the terminal physically locking the keyboard. (Do you know that feeling when you are walking downstairs and you slam your foot on the ground, because you thought one more step was still coming? Imagine that happening to your fingers, all the time, throughout the day.)

The first solution to this problem was to create a buffer, so you didn’t have to wait to type the next keystroke. The locking or the beeping now happened only when you typed so fast you filled up the entire buffer:

• Typing with buffers – Click into the input field and type your full name
• Explore latency and buffers to see how they feel

The delay was still there. But as long as the keys themselves aren’t dirty or sticky, it shouldn’t matter, right? After all, fingers are so good that they don’t need confirmation from your eyes. Fingers are so good that they sometimes press Backspace for you, without you looking, without you even realizing, just because they can sense on their own that the previous key press was misplaced.

But by the 1960s typing evolved from just retyping memos to creative writing, programming, and other less rigid forms of using the keyboards. Arrow keys arrived first; displays entered the picture soon afterwards, and then full screen menus entered that picture. If you’re not looking at the keyboard, where else will you be looking at other than the screen, continuously and hopelessly delayed?

So, the next invention was something called “local echo.” Local echo was a white lie. Your keystroke was now shown on the screen immediately and optimistically, assuming it makes it to the computer undisturbed. It seems like the most obvious solution, but it does add complexity over what came before: now your terminal can’t truly be dumb, and you have to deal with configuring both sides of the system so that only one echo is present, instead of zero… or two:

• Typing with a local echo – Click into the input field and type your full name
• Play with latency and echo options

In this way, we traded some of the newfound computing power to recreate something we already had fifty years before: typing operating at the speed of fingers. This will be a theme of this essay.

“Fifty years before” was 1910s – the first era we started analyzing and understanding typing. But the early mass-produced typewriters arrived another half a century earlier than that, and piano keyboards were even older. This means our deeper understanding of fingers and typing arrived mostly alongside the typewriter, not ahead of it.

Best example? The rise of touch typing. The first popular QWERTY typewriter was designed to be fast – one of the first use cases was writing down Morse code signals in real time, and those casually reached 50 words per minute. That speed, miraculously enough, was available with what today we’d call hunting and pecking. The arrival of the keyboard made people dream of more, including the vaunted notion of transcribing someone talking in real time. In search for that dream, multiple people chipped away at “touch typing” – nine fingers on the keyboard, eyes off of it. The effort took decades to develop, many saw it as a fad, and no one fully agreed on what “proper” meant for some years more.

By the 1910s, touch typing was properly established and rather popular, and stayed with typewriters until the end of their time. But the early and awkward computers (and terminals) of the 1940s, 1950s, and 1960s came with clunky “laboratory” keyboards that were often worse than even early typewriters. It made sense – why would you care about touch typing if remote echo and the absence of buffers rendered it impossible?

The front-end brain and the back-end brain

But ergonomic progress can be uneven. Only a decade later, in the 1970s, things would change dramatically. As computers became smaller and faster and increasingly less remote, and equipped with echos and buffers, their keyboards needed to get better, too. They started stealing many lessons from the best typewriters before them and, unencumbered by mechanical typebars, became a lot more ergonomic than typewriters ever could – which, in turn, allowed for the fingers of the operators to move really, really fast.

And the mechanical advantage was joined by a geographic one. If your computer is now just a few inches away from your keyboard – or literally hiding inside it – local echo and buffers become historical curiosity, right? Not quite, as smaller computers were also much slower than the large ones. Moreover, now it wasn’t just keys and typing that needed to feel fast.

Keys on the keyboard are nothing more than buttons. In the 1970s and 1980s, computer screens became equipped with buttons, too – first operated by keyboards with newly-invented arrow keys, then by mouse. The old concepts became relevant again. Try pressing these buttons that do not react “in finger time,” and see how unpleasant it feels:

• Slow magnet poetry – Press buttons to create magnet poetry

Learning from the past, we can imagine adding buffering here. This is useful, but only to a point. The actions might be buffered and processed as fast as possible, but the mouse events will also have to wait in line. So even a computer that’s plenty fast to draw a different button state instantly when your mouse is on top of it or when you press it, won’t be allowed to do so until the buffer is exhausted:

• Buffered magnet poetry – Press buttons to create magnet poetry. Try to press them as quickly as you can!

This still feels awful. A dirty, sticky button in real life would already feel unpleasant. Here, a button feels dirty and sticky in a profoundly alien way, without real-life’s haptic signals that allow your brain to understand what’s going on. Physically locking keys in the typewriters of yore felt bad. But so is suspending the interface even momentarily whenever the computer is not ready to deal with it. In jargon, this is often called UI blocking. (If your designer doesn’t hate UI blocking with passion, you need a new designer.)

One cheap answer is debouncing – slightly delaying responses to any heavy action to allow the interface to catch up with simple things before the computer takes on a heavier thing. It’s nothing less than a distant echo of the local echo concept.

But the best answer is splitting the computer’s attention into two tracks. The “back-end brain” can deal with heavy actions and buffer them as necessary, while the “front-end brain,” working in parallel, processes interface events in real time, with absolutely zero chance of blocking the user interface:

• Parallel UI thread – Press buttons to create magnet poetry. Try to press them as quickly as you can!

But even this method still has caveats. Once you put something in a buffer, the buffer needs to exhaust itself. We’ve all been there: we held an arrow key to move an object, realized that the computer was slower than we thought, started holding the arrow in the opposite direction, overshot, and got in a weird and frustrating oscillating game:

• Exhausting a buffer – Hold the → key to move the window to the shown position
• Adjust both sliders and learn the relationship between them

This problem has no easy solution. The Emergency Stop button above is kind of a joke, but one could imagine a special shortcut like Esc or ⌘. that clears the buffer immediately. The user has to know about it, though, and that shortcut itself by definition cannot be put in a buffer, which might be problematic.

You can also distinguish between holding a button and pressing it many times and try to account for that. Both are implemented below:

• Smarter buffer – Hold the → key to move the window to the shown position. Notice how holding it doesn’t create buffer problems, but on the other hand, the system still remembers (buffers) all your quick individual presses.

But the best answer is, as always, to make the interactions as fast as possible, for the delays not to happen, and for the buffer to rarely be necessary: to do everything in your power to show the feedback to the user at the speed of the fingers.

The (actual) need for (perceived) speed

The tricky part, of course, is that computers are not necessarily faster today than they were in the 1990s. I know, technically they are, but often the Moore’s Law advances are spent on new things we ask computers to do, or new abstraction layers in between. If your computer happens to be struggling under load, many of the above trivial examples solved by the 1980s can still become too slow for your fingers today.

And, what we expect of computers is no longer trivial. There might be no better example to this than as-you-type search, showing you results at the moment of typing. The sheer computing power to make this feel great was available in the 1990s, if not the decade prior. But then, the internet reintroduced some of the remote woes of the 1960s, the new intermediary of the internet browser (and later, JavaScript libraries) ate away a lot of the speed benefits, and echoes and buffers carefully implemented in operating systems didn’t magically become available to websites.

Today, a lot of badly put together searches are still UI blocking, making you wait after each keystroke. Others don’t handle well the common situation of a user changing the search as the results are already flying in:

• Bad search-as-you-type – Search for “AT&T” or “Fujitsu” in this bad implementation of search-as-you-type, and accept with Enter. Notice your keystrokes are blocked, and the results arrive haphazardly.

We take for granted searches that handle all of this well and always feel snappy regardless of weather – Google’s Autocomplete, or Raycast. Their secret? They, too, know it’s okay to lie.

People will tell you that the job of loading states – progress bars, rotators, “skeletons” of things to come, and cute animations – is to tell users precisely what’s loading, and how long will it take to arrive. But if there’s one thing I learned about loading states is that that’s not exactly true. The one and only one purpose of loading states is to make software feel as fast as possible, by all means necessary.

A road to a slow interface is paved with fast intentions. The first building block is choosing the right loading state for the job. One that’s too heavy can make the interface feel slower, and make the user intuitively slow down in response:

• Basic loading states – Double click on the icons to explore various loading states

Above, all of the loading states are functionally correct, but you can get a sense that a lot of them are heavy and/or overkill, drawing more attention to the fact of loading than necessary. And so, the second building block is then knowing when not to show up, sometimes just holding t