Prolonged tracking loss should prompt the user to adjust position or lighting

What it is

If a loss is only long enough to freeze, users often walk the hand back themselves. Once it stretches past what trial-and-error can recover, the system should prompt for a user-actionable condition—position or lighting—rather than freeze in silence or show only “hand not detected.” The prompt should point at an environmental cause the user can act on, not demonstrate the gesture again. The physics of light and occlusion belong elsewhere; what is required here is that a long loss speak the recovery step.

Why it happens

Typical causes of a long loss are actionable: standing outside the capture envelope, backlight, the other hand covering the working hand, a sleeve wiping the lens. Doing the same gesture more canonically will not clear them. A silent freeze leaves the job at “wait some more,” which people wait into fatigue and abandonment. The prompt has to be specific: “step forward,” “don’t stand with the window behind you,” “move the other hand away” end a loss faster than “tracking failed.” Wrong specifics harm too: shouting “come closer” when the person is already inside walks them out the other side. So the prompt should be chosen from side evidence still available (is the torso there, ambient brightness, is the hand at the frame edge), not from one universal sentence.

Studying it

In the lab, manufacture recoverable long losses: step the person past range, open a window behind them, cover the working hand with the other. Compare no prompt, a generic failure phrase, and cause-split prompts. Dependent measures are time to recover, whether the first repair hits the true cause, and abandonment. Log secondary losses caused by misleading prompts (already inside, still told to come closer). Do not test lighting prompts only in a dark lab; that misses backlight.

Where it stops holding

A headset strapped to the face may make “go turn on a light” impossible; the prompt has to change to “turn toward a brighter part of the room” or switch to a controller. In public, users often cannot close a window or move a lamp; prefer stance and self-occlusion. When the loss is actually hardware failure, stance and lighting prompts blame the user; after a timeout, escalate to “the device needs service.” If speech already occupies audition, a long spoken prompt fights the task and needs a short, deferrable visual bar.

Applying it

• After a loss longer than the product’s short freeze window, show an actionable prompt chosen from stance / occlusion / lighting given current side evidence. Forbid “not detected” alone.
• The prompt must be dismissable, and must auto-clear when the hand returns, so it does not cover content after recovery.
• Walk three manufactured long losses and check whether the first sentence points at the true cause. If it points wrong, change the side-evidence rule; do not lengthen the copy.

Related

• Same group: C4.23.1 Tracking loss must be distinguished from ordinary action gaps so it is not treated as disengagement · C4.23.2 In-progress continuous operations should freeze rather than zero or cancel when tracking is lost · C4.23.3 After tracking recovers, the system must decide whether to resume the frozen state or require a restart
• Adjacent: C4.31 Lighting, occlusion, and environmental conditions · C4.25 Predefined fallback paths
• Search: recovery prompt · tracking lost · relight