Implicit interaction does not require the user to issue an explicit command

What it is

Implicit interaction takes what a person is already doing—approaching, stopping, breathing more shallowly, lingering with the eyes—as input, without requiring a named command first. The primary task remains walking, talking, or reading; the system samples a byproduct of those activities. This is not “a shortcut buried deep”: the action was never packaged as an instruction.

Why it happens

Explicit input rests on a symbol both sides acknowledge: a click, a wake word, a move from a gesture lexicon. Implicit input cuts that symbol layer and takes an incidental path: the behavior was produced for another purpose, and a sensor reinterprets it as state or intent. Schmidt and colleagues stress that the perception–action loop is still there; the user simply need not turn attention to “speaking to the system.” Implicit channels are therefore almost always probabilistic—an approach may be an intent to interact or a pass-by. If the system treats incidental behavior as a certain command, it moves the Midas problem from gaze onto a whole life trajectory. The value of implicitness is lower task-switching cost; the price is lower observability of intent.

Studying it

Laboratories often use “primary task plus background adaptation”: people talk, lights brighten as they approach. Factors: whether users are told the system is watching, and whether adaptation is predictable. Outcomes: primary-task performance, noticing of system behavior, and counts of pass-bys treated as interaction. Wizard-of-Oz can first ask “if implicitness were perfect, would people want it,” then bring real sensors. Field logs should separate “the user deliberately exploited the adaptation” from “they merely did not object.” Measuring satisfaction without the primary task writes implicitness as costless magic.

Where it stops holding

Once users learn “walk to the door and the light comes on” and walk there on purpose, the behavior has been explicitized; the mechanism is now a shortcut. Accessibility switches and emergency stop cannot live on implicitness alone. In public space, incidental behavior belongs to several people, and the system can rarely attribute input to one body. Implicit is also not “no UI”: feedback is still required, or people cannot know they are being treated as an input source.

Applying it

• Write down the primary task first, and use only incidental signals that will not steal attention from it for preload, pre-light, or warm-up—not for commit.
• Let one explicit command override an implicit effect; implicitness must not be the only path.
• Keep implicit changes reversible and low-consequence (brightness, suggestions); leave high-consequence acts to explicit moves.
• Verify by walking the full path without briefing the user on the rule; check whether the primary task is interrupted and how often passers-by are treated as users.

Related

• Same group: C9.05.2 Bounds on system initiative need to be user-settable · C9.05.3 Users often have no way to correct a wrong implicit inference
• Adjacent: C9.12 Implicit Interaction and System Initiative · C4.02 The Midas Touch Problem
• Search: implicit interaction · incidental interaction · explicit command