Hover and dwell interactions must set a tolerance radius

What it is

Interactions that rely on the user "holding a cursor or fingertip still in one place for a while" — a hover-to-expand menu, a dwell confirmation, a press-and-hold drag — will inevitably misjudge a user as having moved away, purely because of physiological tremor, if the criterion demands the position stay exactly unchanged. The workable approach is to give the dwell judgment a tolerance radius: as long as the position stays within that radius, it counts as not having moved; only leaving the radius counts as moving away.

Why it happens

Physiological tremor guarantees that no one can pin a fingertip or cursor to a single pixel and hold it perfectly still — the actual trajectory during a dwell is always a small scattered region centered on the target point, never a single point. If the hover logic demands frame-to-frame position stay exactly identical (or within the device's minimum resolvable step), this naturally occurring scatter gets read by the system as repeated "movement," resetting the dwell timer over and over — the user is patiently holding still, yet the trigger never fires. A tolerance radius is fundamentally an acknowledgment that this scattered region exists, loosening the judgment granularity from "pixel-perfect stillness" to "staying within a reasonable range."

Where it stops holding

There is no single fixed value that works as a tolerance radius — it needs to be set relative to the actual tremor amplitude for the specific device (different input methods and postures carry different amplitudes). Too small a radius fails to help; too large a radius makes the dwell judgment insensitive to a genuine intent to move away, leaving the user unable to cancel because they're still technically "within radius."

Applying it

• Set the tolerance radius for hover/dwell interactions based on measured scatter data rather than guessing — it should cover at least the common scatter range seen during a genuinely still hover.
• The radius doesn't have to be a single fixed value: it can be set separately per input device type (touch finger, stylus, mouse, in-air gesture), since the tremor amplitude carried by each device differs substantially.
• To verify: collect real trajectory data of the target user population trying to hold still while hovering on the device in question, take some percentile of the scatter (e.g., the radius containing 95% of the trajectory points) as the tolerance floor, and tune from there — rather than picking a number first and adjusting it by feel.

Related

• Same group: A8.15.1 An unremovable baseline jitter with a characteristic frequency exists even at rest · A8.15.2 Fatigue, cold, stress, and caffeine all amplify tremor · A8.15.3 Tremor amplitude grows with arm extension distance · A8.15.5 Input smoothing introduces latency, conflicting with directness
• Nearby: C1.06 Hover state and its absence on touchscreens · C1.20 Hover delay and false triggering
• Search terms: dwell tolerance · hover tolerance · dwell time selection · jitter threshold