Overlays should show and hide with task relevance, not stay resident

What it is

On the last screw, the previous “parts list” is still pinned in the middle of the view. The list is irrelevant to the current subtask and still occupies that patch of reality. Task-contingent overlay requires overlays to appear and vanish with the step being done, not to stay resident from power-on to power-off.

Residence is cheaper to implement: no need to judge what should be seen now. The judgement saved is spent by the wearer, every step, hunting the current item inside an irrelevant layer.

Why it happens

A task is a sequence whose focus changes. Each step truly uses a small bundle; the rest is residue from the last step or preview of the next. Vision does not automatically peel “irrelevant” from “relevant”; a resident layer sits as a stable foreground. People either treat residue as still to-do (repeat a finished step) or spend a search to find the current item in the residue. Both cost more than “no layer this step, it appears on the next.”

Show/hide has to bind to a task state machine, not to a timer or “the user looked for three seconds.” Looking is not finishing; once finished, even if they are still looking, the layer should yield the view. Previewing the next layer too early interrupts the current action; disappearing too late covers the completed state. The window should track “this step starts → this step commits,” not session lifetime.

Studying it

Stepwise assembly or stepwise navigation: the same information volume, comparing a resident HUD, show/hide per step, and a manual toggle. Record search time per step, errors from reading the previous layer, and rated “in the way.”

Task factors: step count, whether layer-to-step relevance is accurate, automatic versus manual switch. Scores: step time, serial-step errors, fraction of gaze on an irrelevant layer, whether the layer remains after completion.

If the task has no encodable steps (wandering, browsing), per-step show/hide has no state to follow, and you will measure random flicker.

Where it stops holding

Monitoring (a level that must stay visible, vital signs) does not drop relevance between “steps”; residence is right, and show/hide will create misses. Wrong step boundaries make automatic show/hide worse than residence: what should appear does not. A manual toggle is more stable when steps are slow and thinking sits in between, but unusable when the hands are occupied. When the environment is already full, even relevant overlays need a further cut — that is density against the environment, not timing. Clearing overlays in a safety-critical zone is forced by place, not by task step.

Applying it

• Bind overlays to a task-step ID: mount on entry, unmount on commit or a leave timeout. Forbid a session-level resident list.
• Allow a short preview inside a step (the next screw). The preview must be weaker than the current layer, and promote or vanish when the current step ends.
• Give “this step has no overlay” a perceptible empty state, so people do not think the system died and reopen the layer into residence.
• How to check: slice an assembly recording by step and ask whether the layer in each frame belongs only to that step. A previous list still in the centre, or a torque number missing on its step, means show/hide is not following the state machine.

Related

• Same group：N5.12.2 Information bound to a specific object is easier to associate correctly than information floating in view · N5.12.3 Handling the real environment and overlays at once costs extra attention; they compete for bandwidth · N5.12.4 When the environment is already information-rich, overlays must reduce, not add · N5.12.5 Density control aims at task completion, not at showing as much available information as possible
• Nearby：N5.07 Overlay Density · N5.13 Safety Risks from Occluding Reality
• Search terms：task-contingent overlay · attention-aware AR · just-in-time label