Hover delay must filter pass-through mouse movement

What it is

Once a desktop puts previews, secondary actions, and hints on many objects, the pointer crosses a string of other objects on the way to the real target. A dwell threshold waits a beat after enter so a passing trajectory has no time to light those objects, and only the one that stays fires. Without that wait, the design freedom hover gave becomes a corridor of popups.

It filters pass-through. It is not a fine-tuning of “how many milliseconds count as fast.” Whether menus and tooltips want two different numbers is a matter for the input primitive.

Why it happens

Desktop windows are large, and hover-sensitive objects can be packed: every toolbar icon, every table row, every nav item. The pointer is a continuous path; going to the close button in the top-right also sweeps half the toolbar. If the trigger is “enter,” every object on the path fires, previews overwrite each other, secondary actions flash as noise, and the person is interrupted by content before arriving. Dwell changes the evidence from “passed” to “still here”: pass-through produces enter and leave and almost no dwell; an intentional peek produces dwell. The more a desktop design bets on hover, the less optional the gate—the scale of the freedom is the scale of the pass-through.

The threshold is a gate, not content. Too short, pass-through still squeezes in; too long, an intentional glance queues, and the interface feels dead. Desktop’s freedom holds when the gate blocks trajectories and admits staying.

Studying it

In a desktop window packed with hover objects, run two tasks: “go click a distant target” and “stop and look at one item.” Independent variables: dwell duration, density of hover objects along the path (how hard the design freedom is being used). Dependent variables: false triggers along the way, time to the real target, intentional peeks blocked by the gate.

Do not only time delay on a single button. Density is the desktop variable: the same threshold is invisible in a sparse window and decides usability in a dense one.

Where it stops holding

Intentional rapid scanning (gliding down a column of thumbnails to see which is the one) is held back by a dwell gate; those tasks need a shorter gate, or a modifier that temporarily drops the filter. Keyboard focus movement is not pass-through; a hint on focus should not inherit the mouse-trajectory dwell. Objects the pointer crosses during a drag must not fire as hover, or the drag channel is interrupted by a corridor of overlays. Touch has no pass-through mouse movement; the gate does not exist.

Applying it

• Any enter that would open a preview, a secondary action bar, or a tooltip gets a dwell gate first. Leave before fire cancels; do not queue.
• The denser the objects and the more interrupting the popup, the more the gate must block pass-through; sparse objects whose popup is only a highlight can take a shorter gate. Do not run one gate on everything in the window.
• Verify by sweeping the pointer from one end of the window to a button at the other: nothing along the way should pop. Then rest on one item: the preview should appear after the rest. A corridor of popups on the sweep, or a rest that still feels like no response, means the gate is not between passing and staying.

Related

• Within the group: K2.06.1 Hover allows preview and hints without commitment · K2.06.2 Hover-dependent designs cannot migrate to touch · K2.06.3 A product that spans form factors needs two schemes · K2.06.4 Hover can progressively reveal secondary information so the first view is not crowded · K2.06.6 Functions triggered only on hover are undiscoverable to keyboards and screen readers · K2.06.7 If hover-state information is indispensable, the interface is missing persistent cues
• Adjacent: C1.20 Hover Delay and False Activation · C1.06 Hover States and Their Absence on Touchscreens
• Search terms: hover dwell · pass-through · hover intent