D5.07.3Overinclusive fusiondesignresearch

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

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/D5.07.3