Typing with four buttons

Most small e-readers have a few buttons and no touch screen, so typing on them means stepping through a grid one key at a time. We built a predictive keyboard for four buttons and a slow e-paper screen that writes real sentences in about two presses per letter, less than half what a QWERTY grid needs.

10 October 2026

Typing a sentence on an XTEINK X3. Every frame is drawn by the keyboard's own firmware code, at the panel's real speed.

The problem

Button-only e-readers are everywhere: pocket readers like the XTEINK X3 and X4, older Kindles and Kobos, and a wave of open-source firmware for them. They're built for reading, and the moment they ask for words (a Wi-Fi password, a search, a note in a margin, a message) typing becomes a chore. We hit this building letters for Deckle, a firmware for the X3 and X4, and decided to solve it properly for any device with a handful of buttons.

Two limits shape everything:

  • Four buttons. No touch screen and no chords: the buttons share one wire, so the device can only tell which one is down, never two at once.
  • A slow screen. Every press redraws the panel, and a quick redraw takes 478 ms on the X3 (we measured it) and about 1.5 s on the X4. Drawing the frame takes 13 ms and predicting words 35–60 ms; the glass is the whole cost.

So the measure that matters is not taps or selections but total button presses to say a thought. A word that takes one selection after twelve moves is worse than three selections after four.

What didn't work

Before drawing anything, we built a test bench: 124 real messages (bottles, replies, notes) with a fifth held back for testing, and a simulated typist that finds the fewest presses any design allows. Then we tried the obvious keyboards first.

DesignPresses per character
An alphabet ribbon: scroll one row of a to z10.80
Our own first sketch: tabs of common words, endings, letters and more7.02
Word predictions over a ribbon5.14
A grid: pick a row, then a letter4.73
Lanes, the design we shipped1.85

The lesson from the losers: 79–91% of their presses were just moving around. Picking is cheap; travelling is what costs. Good predictions only help if they sit where your thumb already is.

How it works

The keyboard is a stack of five lanes, shown as tabs, and only the open one is on screen:

TabWhat's in it
FINISHThe likeliest next letters of a word you're spelling ("bh" after "Sio"). It only appears mid-word.
WORDSSpace and . , ? first, then phrases and the six likeliest next words.
A-M and N-ZThe alphabet in two rows of thirteen, with a shift key at each end, column over column.
MARKSPunctuation, digits, a new line, delete word.

The keys do the same thing everywhere:

  • < and > move along the open lane, wrapping round.
  • SELECT adds the key in focus. A word brings its own space; a full stop brings the capital after it.
  • BACK undoes the last thing you added, a whole word at a time.
  • Hold SELECT to go down a lane, hold BACK to go up. Devices with side buttons use those instead.
  • Done sits at the foot of every lane, one press left of the first key.

After every word, the focus lands on the likeliest next word, so the most common case costs zero moves: you just press SELECT. When you're answering a message, the lanes also offer names and phrases from it ("Dear Maria,", "you adopted").

Measuring it

Every idea went through the same bench, and every design had to earn a 9 out of 10 from four reviewers: a text-entry specialist, an e-ink firmware engineer, a writing-focused product reviewer, and a usability tester who typed ten real messages and reported every annoyance. It took three rounds; lanes was the only design all four scored 9.

  • Expert pace: 1.85 presses per character on messages the design never saw while being tuned.
  • First-time pace: about 2.3, from a simulated typist who looks before pressing and sometimes picks the wrong word.
  • A real sentence: the one in the video, "I was thinking about you today. The leaves are turning gold here.", takes 127 presses for 65 characters, a slip and its fix included.
  • The words: prediction runs on the device from about 2 MB of word statistics built from openly licensed sources: Tatoeba's everyday sentences (CC BY 2.0 FR), GeoNames places (CC BY 4.0), given names from Wikidata and the US Census, and older books from Project Gutenberg, turned down so the keyboard doesn't talk like 1890.

The firmware's C++ and the bench's JavaScript are the same design twice. A test replays over 11,000 presses through both and checks that they agree on every single one.

Against a QWERTY grid

The best-known keyboard on these devices is in CrossPoint, the open-source reader firmware: a phone-style QWERTY grid with a number row, moved through with the side buttons. We rebuilt it on our bench from its source and typed the same held-out messages on both.

LanesCrossPoint's grid
Buttons used46
Presses per character1.854.16
Presses for an average message304684
Words per minute, screen time included8.84.4
Presses to fix a typo37

That isn't the whole story. CrossPoint's keyboard was built for Wi-Fi passwords, web addresses and search, and it's better at those: every key is always where you expect, it types symbols, accents and other alphabets, and you can move the cursor back into the text. Ours is built for writing a few sentences and couldn't type a password. They're tools for different jobs.

The small things

The numbers got us to a design. Typing on the real device made it feel right, and most of these came from an afternoon of pressing buttons and saying what bothered us:

  • Fast hands lost presses. A press made while the screen was still redrawing was thrown away as a safety rule, so a quick > > SELECT dropped the SELECT. Now presses run in the order you made them; only a press made after the words themselves changed is ignored, because you couldn't have seen them yet.
  • Keys that look like keys. Every key got a rounded border, so your message and the keyboard never blur together. The message got its own box.
  • One lane at a time. Showing all five lanes at once was a wall of choices. Now only the open one shows, under folder tabs that name the rest.
  • One word for SELECT. The select key used to name whatever it would add. It now always says SELECT; what it will add is already underlined in your message.
  • Done, always there. Done went from the end of one lane to a big button under every lane.
  • No dead tabs. FINISH only appears once you're spelling a word, because a tab you can't open looks broken.

What it could do next

  • More languages. The engine knows nothing about English except its word statistics. A new language is a new statistics file built by the same packer, and the alphabet lanes take any letters the screen's font can draw.
  • Fixing earlier words. Today you can only undo from the end. Picking an earlier word and swapping it is designed, not built.
  • Fewer buttons. Lanes already work without side buttons by holding SELECT and BACK. The same ideas apply to two-switch scanning keyboards used for accessibility, though we haven't tested it with people who rely on them.
  • Other devices. Anything with a few buttons and a slow screen: other e-readers, e-paper badges, handheld gadgets.

The keyboard's engine has no ties to our hardware, and we're considering releasing it with its test bench so other e-reader and gadget projects can use it, and add the languages we can't. Tell us if you'd use it.