Whether the sensor is currently capturing should have a persistent visible indicator, not only a cue at recognition time
Aliases: capture indicator · persistently visible · cue only at recognition
What it is
Whether a depth camera or radar is currently feeding frames into the recognition pipeline is a state independent of “did it recognize your gesture.” That state needs a persistent visible indicator: a lamp, an icon, a bezel, present for the whole time capture is on, not a flash only when some gesture is recognized. A success animation says “that one counted.” A capture indicator says “it is still looking.” Cueing only at recognition is pretending, in the idle, that it is not looking.
Why it happens
Capture is the pipeline’s power switch; recognition is a classification event at the outlet. While power is on, frames are grabbed, possibly buffered or uploaded, even with no valid gesture. Users’ privacy and control judgments target the power, not the outlet. If the indicator is bound to the outlet, it goes dark in gesture-free time, users think it is off, and the sensor is still running—a false off. A laptop camera’s hardware lamp is bound to power so “looking” cannot be muted in software. A mid-air product that only lights a cursor when a wave is recognized hides capture state inside a recognition event. Persistent can still be low-interruption: a stable dot in a corner, not a full-screen “listening.”
Studying it
Have participants judge “is the camera on now” under a persistent lamp, a flash-only-on-recognize, and no indicator, and ask during idle stretches with no gesture. Measure judgment accuracy, privacy concern, and when they go looking for a switch. Use gaze to see whether the persistent lamp is actually used as evidence or ignored as chrome. Do not ask only while they gesture; the fight over capture state is in the idle.
Where it stops holding
A headset on a face needs an outward capture indicator for bystanders; the wearer can have an internal icon—two audiences. Always-on lamps cost battery; a slow blink or a bistable “visible while on, dark means off” still must not light only on recognition. Some regions require a hardware lamp that software cannot kill; a product indicator must not replace that lamp or contradict it. An art piece may deliberately not indicate, as declared surveillance aesthetic, which is not default interaction.
Applying it
- Bind the capture indicator to sensor power or to the data stream, not to
onGestureRecognized. - Keep the indicator on while idle. Use a different, brief cue for recognition success, so the two signals do not fight over one lamp.
- Acceptance: during thirty seconds with nobody gesturing, ask both a bystander and the operator “is it looking.” A wrong answer means the indicator is still bound to recognition events.
Related
- Same group: C4.29.2 The capture indicator should be independent of recognition results and remain on even when no gesture is detected · C4.29.3 Without capture-state visibility, users cannot tell whether silence means not capturing or not recognizing · C4.29.4 Turning capture off should be as reachable as turning it on
- Adjacent: C4.30 Bystanders and third parties · C4.02 The Midas touch problem
- Search:
capture indicator·camera LED·always-on sensing