TUP — adaptive thumbwheel text input

The person

The design target was Bob’s cousin, who has Multiple Sclerosis. By the early 2000s the cousin’s hand control was deteriorating but not yet at the point where a switch-scanning system was necessary; he could still use a touch device, but with two specific input failures. Bob’s mother, who has arthritis, also informed the work: she found typing on mobile devices painful, and the design target became reducing finger motion and making each contact tolerant of imprecision.

The constraint

The two specific input failures named above:

• The woodpecker effect— hand tremor producing repeated brief contacts that the touch surface registered as a sequence of rapid presses, when only one was intended.
• Sliding from numbness— reduced cutaneous sensitivity meaning the user pressed without knowing how hard, and the finger could be pushed slightly during the press, landing somewhere other than the original contact point.

The era was the original Apple iPod. The original TUP — Transparent User-guided Prediction, by Proschowsky, Schultz, and Jacobsen at CHI 2006 — was published with characters at fixed positions on the touch wheel and a prediction algorithm that adjusted which character got highlighted based on where the finger landed. Their accessibility nod was a single throwaway sentence: “the method might also be useful for disabled persons. By placing an angle detector on a joint, the person will be able to highlight a character.” Fast for typical users; nothing about tremor, sliding, or low-vision constraints.

The insight

Don’t make the user reach for the predicted character. Adapt the wheel so the predicted character is already under the finger.

In Bob’s reimagining, the letter A was fixed at the top of the wheel as a reference; the rest of the alphabet was variable. As the user moved their finger around the wheel, a dot on a circle indicated the current position, and the currently-selected letter was shown on screen at large size, rather than tiny text on the wheel itself. The TUP prediction algorithm put the predicted letter directly under the user’s finger initially; the user moved only if the prediction was wrong, and even then by a small amount.

The artefact

A C-language reimplementation of TUP running on iPodLinux — “yes, Linux ran on iPODs despite Apple’s best efforts to stop it” — with two pieces of original engineering on top of the inverted-wheel concept:

1. A finite state machine modelling user input, designed specifically to handle the woodpecker effect (multiple brief contacts treated as one intentional press) and the sliding-from-numbness problem (a press that drifts is interpreted as the original landing point, not the drift).
2. The adaptive wheel display with the large on-screen letter, designed for low-vision users (also relevant to MS, which can affect optic-nerve function).

The teaching

Predictive systems should reduce motion, not just suggest letters.

The standard predictive-text framing — we’ll guess what you want and you confirm— assumes confirmation is cheap. For users with MS or arthritis, every motion has cost. The right design question is therefore not how can we suggest the right letter? but how can we put the right letter where the user already is? Different question, different solutions, different metrics.

“If I say so myself, quite clever for its day.”

The longer arc

TUP turned out to be a prototype of the formal capability model that came later. The Capability Set vocabulary in the doctoral framework lists haptic properties — landingZone, guardZone, multiFingerTouch, interTouchGap, minTouchTime, typicalButtonPressRate, constantTouching, touchAStaticPoint, touchAMovingPoint— that are precisely what TUP’s woodpecker-and-sliding-touch FSM was modelling at the engineering level years before the framework existed. The ad-hoc engineering of TUP became the formal haptic capability template; the persona who appears in the framework as a 45-year-old British male with progressive MS, hand tremors, no kinaesthetic sensing, fatigue-driven voice degradation, a measured 30×40 pixel landing zone and 80×80 pixel guard zone on a bad day, is TUP’s design problem written down in the framework’s vocabulary.

The same person who motivated the engineering moved, over the years that followed, from thumbwheel input to a scanner-and-jelly-bean switch system for menu selection of household tasks — open door, close curtains, TV on, TV off. The design problem evolved with the user; the framework that grew out of the engineering was shaped by years of tracking that evolution.

The coda

A working tool, used. Not productised; not academically published as a separate paper; the work fed into the broader doctoral framework. Significant as an early data point in a longer pattern: an underspecified accessibility footnote in someone else’s HCI paper, taken seriously and turned into the actual research question.