Variable, infrequent, label-heavy functions favor on-screen controls

What it is

Firmware version, UI language, whether a peripheral is plugged in: all change which commands exist. A calibration used once a year, an export that must be read as a warning first, should not occupy a permanent cap. On-screen controls means: when the function set churns, calls are rare, or safe use depends on wording, draw them on a rewriteable surface instead of tooling them into the panel. That is not “screens are more advanced.” Those functions consume variability and readable prose, not an eyes-free landmark.

Why it happens

A screen treats legend, visibility, and layout as refreshable state: a new language, a new accessory, a new legal warning can appear next frame without a new mold. Infrequent functions never graduate into a motor program; a dedicated key for them goes stale on the cap and steals space from frequent keys. Content that must be read (the object of an irreversible act, a permission scope) only fits in settable type, not in engraving. The right channel for these functions is therefore: eyes already on the device, read, then tap. Minting them as permanent physical keys leaves dummy keys, wrong keys, or one key bound to several unrelated jobs when the function set moves.

Studying it

Track how fast the function set changes across versions, languages, and peripherals, and the real interval between calls.

Independent variables: whether a function appears or vanishes with configuration, interval between calls, legend length (one word / a sentence of warning), control on screen versus on a key. Dependent measures: errors from stale legends, time to find a function, number of blank or wrong-meaning keys on the panel.

For products that hard-tooled infrequent functions, measure mis-hits across a revision: the key remains, the semantics moved. A usability test that only covers first-run setup overweights the cost of a screen path and underweights a physical key’s wrong meaning in year three.

Where it stops holding

An infrequent function that must still run eyes-free (an emergency lamp in the dark, mute in a pocket) may need to be physical even if used a few times a year—consequence outweighs frequency. Devices with no usable display (a dumb remote, some industrial grips) can only keep legends short and swappable. Bright light, frost, and wet hands that make on-screen legends unreadable shut off the “favor the screen” bias and need a fallback. Legally frozen copy that almost never changes may be more stable engraved than on a screen.

Applying it

• Default functions that appear with configuration, that are used a few times a year, or that need more than one word before a press, onto a screen or a refreshable menu.
• Do not tool a permanent key for a plug-in that happens to exist in this version.
• On the screen path, spell out object and consequence; that is the reason for choosing a screen.
• Verify: list functions added, removed, or renamed across the last two versions, and see how many are still printed on caps. Those still printed with moved semantics belong on screen. Check real logs for call interval: monthly-scale functions should yield their physical slot to frequent ones. Confirm on-screen legends remain readable in target light and wet hands; otherwise add a fallback.

Related

• Same group: C10.07.1 Frequent, eyes-free, and safety-critical functions favor physical controls · C10.07.3 The cost of a physical control is that it cannot be reconfigured
• Adjacent: C10.14 Labels and Illumination of Physical Controls · C10.13 Mode Problems in Multifunction Physical Controls
• Search: soft keys · on-screen control · variable function set