C10.07.1physical controls for frequent eyes-free safetydesignresearch

Frequent, eyes-free, and safety-critical functions favor physical controls

Aliases: dedicated control · hard key · safety-critical button · eyes-free control

What it is

Brake, shutter, wheel volume, a bipolar footswitch in surgery: pressed often, pressed while the eyes are elsewhere, costly if wrong. Dedicated physical controls means those functions earn a device that does not move, can be felt, and has definite travel. This is not about how legends are printed, or how many modes share a key, or a claim that screens never work. It is which functions should not live only in a hit region that reskins.

Why it happens

Frequency turns locate-and-confirm into a motor program, and a program needs a stable spatial landmark—a raised rim, a fixed spine. Eyes-free strips vision, leaving that landmark. Safety-critical adds a third demand: actuation must be a definite mechanical event, not a finger-up that a swipe might swallow. Screen hit regions are unstable on all three: position moves with the UI, the surface is uniform, confirmation is visual or a late buzz. Putting those functions on glass dismantles the motor program each time and imports aiming error when gaze leaves the primary task. Footprint and tooling cost buy one thing: this press is the same key as last time.

Studying it

Score candidate functions on frequency, visual occupancy, and error cost, then compare a physical key and a screen hit region under dual task.

Independent variables: control type, primary-task load, whether errors are reversible, frequency (amount of practice). Dependent measures: primary-task interruption (glances off), false triggers, missed triggers, whether time keeps dropping after long use.

Single-task lab tapping makes the screen look fast enough. Driving, viewfinding, or holding an instrument is where the split appears. Frequency should come from real logs, not from “we think this is used a lot.”

Where it stops holding

A function can be critical and still need a confirmation dialog every time (a transfer, dropping a database); the eyes-free advantage of a hard key is unused, and explicit on-screen wording may be safer. Very frequent work that already stares at the screen (cuts on a timeline) can stay on glass. Extremely thin shells (a pen, an implanted remote) cannot host travel and must fall back to haptic simulation, accepting worse eyes-free use. Functions that regulation says must be confirmed twice may make an immediate physical key non-compliant. Gloves, ice, and mud, which kill touch, further bias toward physical keys for environmental reasons, not only task properties.

Applying it

  • List functions that are frequent, done with eyes off the device, or irreversible if wrong, and default them to a dedicated physical control.
  • Do not treat “it’s also in Settings” as a substitute for that key; Settings is the infrequent path.
  • If both physical and screen versions exist, they must mean the same thing, and the physical must be complete eyes-free.
  • Verify: rank functions by real frequency, take the top few into an eyes-covered or driving dual task, and compare glances and false triggers for physical versus screen-only. If the screen version is clearly worse eyes-free, do not ship that function screen-only. Confirm the physical still actuates in the target gloves and wet-hand conditions.

Related

  • Same group: C10.07.2 Variable, infrequent, label-heavy functions favor on-screen controls · C10.07.3 The cost of a physical control is that it cannot be reconfigured
  • Adjacent: C10.01 Tactile Localization of Physical Keys · C10.13 Mode Problems in Multifunction Physical Controls
  • Search: dedicated control · eyes-free · safety-critical input

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/C10.07.1