Too wide a window fuses unrelated input
Aliases: window too long · false binding · cross-talk
What it is
When the window is too wide, input from the previous action, ambient noise, or another task is absorbed into the current intention. A cough, accidental touch, point elsewhere, or confirmation intended for the next item may supplement “close it,” changing object, quantity, mode, or execution timing.
Why it happens
Widening absorbs human hesitation and device latency, but weakens the criterion for “same event.” If pending state is not cleared, an unconsumed object from the last command keeps waiting for a match; shared microphones, touch surfaces, and gaze trackers contribute ambient candidates. A wide window can also pull a later confirmation into the earlier command, letting two separate intentions overwrite each other at interpretation. False binding is more dangerous than failure because it yields a plausible command.
Studying it
Create interference sequences: after one intention completes, insert unrelated speech, a gesture toward another object, a second button, or ambient sound while varying the interval. Record whether fusion occurs. Variables include whether the old event executed, whether its candidate stayed highlighted, shared channels, and semantic similarity of the distractor; outcomes include false-binding rate, wrong-object selection, parameter changes, and time to discovery. Log audits can estimate real incidence by looking for overlap between consecutive commands in one session.
Where it stops holding
Wide windows are not inherently wrong: continuous revision and dragging do need a longer context. The criteria are whether state still belongs to the task, whether users know the system is waiting, and the consequence of false fusion. Shared ambient channels, high-consequence operations, and multiple simultaneous users need stricter clearing; one person's continuous editing may tolerate a longer revision chain if each change is visible and reversible.
Applying it
- Clear pending fusion state immediately after execution, cancellation, focus change, or timeout; retain only an explicitly declared revision chain.
- Use object binding, action type, and parameter consistency as gates; trigger clarification when timing is close but semantics conflict.
- Define source and ownership rules for shared microphone, touch, gaze, and multi-user input.
- Verification: insert distractors between real sessions and measure false bindings, changed parameters, and time to discovery.
Related
- Within the group: D5.07.1 Multimodal input must fall within one temporal window to count as one intention · D5.07.4 Window length should be tuned per modality pairing, not fixed universally
- Adjacent: D5.08.2 Silent guessing causes harder-to-notice errors than explicit fallback · D4.07.4 Adjudication should let users perceive that a conflict occurred
- Search terms:
overinclusive fusion·false binding·cross-talk