One physical control doing different jobs in different modes is a mode effect in hardware form

What it is

The same knob tunes stations in radio and pinches to zoom in navigation; the same key plays on a short press and becomes push-to-talk on a long press. The shell did not change; the meaning did. A mode effect in physical form is a motor program still pressing the previous job while the system executes this one. It is not “physical keys should not exist.” It is a frozen geometry being put on shift work. An on-screen hit region that changes meaning can at least change its icon; a cap often cannot.

Why it happens

A mode splits “control → function” from one-to-one into one-to-many; the current function lives in hidden state the operator must remember. A physical control’s shape, place, and travel all insist “I am still that key,” against the hidden state. Once skilled, the program is faster and a mode check is less likely to insert; the error is the right action at the wrong time. Physical modes are stiffer than screen modes because changing the shell is expensive, so products prefer to shift the same key in software. The usual motive is adding functions after the panel has frozen—non-reconfigurability makes mode effects the default exit.

Studying it

Have fluent users, immediately after a mode switch and without a hint of current mode, do “what that key is supposed to do.”

Independent variables: whether mode changes the shell, whether the user explicitly initiated the switch, similarity of the two jobs, delay after the switch. Dependent measures: rate of acting on the old meaning, time to notice the error, return under an urgent command.

First-time users will not show the mode effect. Use people trained in both modes, and insert distraction after the switch. Asking “do you know what mode you are in” yields a correct sentence and a hand still on the old meaning.

Where it stops holding

If the user is staring at a display that names the current job, the effect weakens—and returns the moment gaze leaves. If both jobs are reversible and observable, the cost is low; if one is play and the other is delete or fire, that key should not share. A panel with no modes, one key one meaning, has no such problem, at the cost of key count. A mode inserted on another channel (voice, a foot PTT) can be more noticeable than a key switching itself, because the initiating action differs.

Applying it

• Default to one physical control, one function; new functions go on screen or onto a new key, not onto shift work for an old key.
• If sharing is mandatory, the two jobs should be similar in consequence and reversible; keep irreversible jobs out of the rotation.
• Treat “what this key is now” as state that must be externalized, not as context the user ought to remember.
• Verify: after fluency in both modes, switch, then immediately give a command from the old mode; count old-meaning presses. Probe again under urgency or distraction. If old-meaning return concentrates on one key, split that key’s jobs.

Related

• Same group: C10.13.2 After a mode switch the control usually looks the same, so people keep the previous mode’s expectations · C10.13.3 When frequent and infrequent functions share a control, mis-operation cost should bias toward making the infrequent function safer · C10.13.4 Mode ambiguity needs its own lamp or legend, not reliance on remembering the current mode
• Adjacent: C10.07 Tradeoffs Between Physical and On-Screen Controls · C6.04 Modifier Keys
• Search: mode error · multifunction control · physical modes