Hover-open needs a delay to prevent misfires
Aliases: intent delay · pass-through prevention
What it is
A pointer passing a menu bar or a parent item is not the same as intending to open that item. A hover delay puts a time gate between “pointer entered” and “menu opens / switches”, to tell passing-through from dwelling. Without the gate, a pointer crossing a row of menus will lift every door along the way, cover content, steal the gaze, and may slam them all when the pointer leaves — a trail of flicker. This is not the geometry of the diagonal corridor. Delay handles intent that is not yet settled; the corridor handles how to walk once intent is settled.
Why it happens
Pointer position is sampled continuously. Crossing a menu briefly enters every item’s hit box; open-on-enter treats passing-through as a choice. The actual intent signal is dwelling: speed drops, the pointer stays on one item past a short window. The delay is that window. An open delay stops pass-by lifting; a close delay (hysteresis) stops the whole tree being torn down when the pointer leaves briefly to take a shortcut. The two gates are asymmetric: a slightly slower open prevents many lifts; a slightly slower close protects the one crossing that is already in the corridor.
Too short, and passing-through still opens. Too long, and people who meant to open think the menu is broken and switch to clicking. A workable window is often on the order of one or two hundred milliseconds, and should be more sensitive to motion that is slowing toward a target than to constant-speed crossing — reading velocity, not only a clock.
Studying it
Have the pointer follow a specified path across the menu bar, then have another group stop on a chosen item; measure false opens and wait time for intended opens. Independent variables: open delay, close delay, whether velocity is considered. Dependent variables: opens caused by passing-through, time to an intended open, and flicker (open then immediate close).
A zero-delay baseline should raise pass-by lifts sharply, which is what shows the delay is preventing misfires rather than repairing corridor geometry — corridor tasks should still fail on their own after delay is already adequate.
Where it stops holding
Click-to-open menus do not use this gate; they use explicit activation. Adding hover on top creates two intent channels. Touch has no hover. Keyboard focus movement that reuses the same delay makes arrow keys feel sticky; the keyboard should open immediately or only show focus, not wait on a clock. Dense toolbar icons make passing-through more costly, so delay can be a little longer. Once a menu is open and the pointer is moving inside it, switching among items should be shorter than opening from outside, or choosing an item inside will also be treated as passing-through.
Applying it
- Use an open delay when entering from outside the menu; use a shorter delay or immediate switch for movement inside an already-open menu.
- Do not close the instant the pointer leaves; leave close hysteresis for walking the submenu corridor.
- Do not lengthen delay to paper over geometric out-of-bounds; tune the two separately.
- How to check: cross the whole menu at constant speed — almost no door should lift. Stop on the target item — it should open in a short time. Then go diagonally from parent into a child; the menu should not close because of a brief leave. That is close hysteresis, not a longer open delay.