Without capture-state visibility, users cannot tell whether silence means not capturing or not recognizing
Aliases: ambiguous silence · not capturing · not recognizing
What it is
When the UI is quiet, the cause may be that the sensor is not capturing, or that it is capturing and did not take the motion as a command. Without capture-state visibility, those two silences cannot be told apart. The user’s next step is opposite: not capturing → go operate the switch; not recognizing → change the motion or the stance. Guessing wrong repairs the other end, and the problem stays.
Why it happens
The two failures have different proximal causes and repairs. Not capturing: power off, a privacy shutter, the OS revoked permission, a power-save sleep. Not recognizing: the gesture does not match, out of the interaction volume, confidence too low, treated as a gap. Visible capture state cuts the first class away: if the lamp is dark, do not change the gesture. If the lamp is on and it is still silent, then enter the recognition / boundary / engagement debug tree. With no indicator the first cut of the tree does not exist, and users cycle among “tap the lens / do it more canonically / reboot.” Support tickets mix both causes under one “no response,” and the product cannot tell whether to fix power or the model.
Studying it
Build two silences: capture truly off, and capture on but only accepting a gesture the user does not know. Record attribution and the first repair with no indicator. Repeat with a persistent lamp. Dependent measures are correct-attribution rate, count of repairing the wrong object, time to success. Ask openly “why is it ignoring you”; do not offer the two options first, or the test measures forced choice rather than spontaneous ambiguity.
Where it stops holding
A laptop with a hardware shutter makes covered = not capturing, and ambiguity drops; many depth modules have no shutter. A voice assistant’s colored ring already carries capture indication; if the mid-air scheme shares the device, two silences stack and the indicator must say which path. Children do less causal debugging; ambiguity looks like leaving. With staff on site, social information short-circuits the ambiguity; the lab should also test unattended.
Applying it
- If the capture lamp is dark in a silence, copy should point at the switch or at permissions, not teach the gesture in the same breath.
- Only if the lamp is on and it is still silent, offer recognition or stance help, in copy separate from the lamp-dark case.
- Split “no response” tickets into capture-off versus recognition-failure columns. If they cannot be split, the product is still showing two silences as one.
Related
- Same group: C4.29.1 Whether the sensor is currently capturing should have a persistent visible indicator, not only a cue at recognition time · C4.29.2 The capture indicator should be independent of recognition results and remain on even when no gesture is detected · C4.29.4 Turning capture off should be as reachable as turning it on
- Adjacent: C4.22 Perceiving interaction-volume boundaries · C4.24 Recognition confidence and bias direction
- Search:
silence ambiguity·not capturing·not recognizing
Cards in the same group
- C4.29.1Whether the sensor is currently capturing should have a persistent visible indicator, not only a cue at recognition time
- C4.29.2The capture indicator should be independent of recognition results and remain on even when no gesture is detected
- C4.29.4Turning capture off should be as reachable as turning it on