Touch devices have no stable way to trigger a tooltip
Aliases: touch tooltip · long-press hint · missing hover
What it is
A tooltip is bound, by default, to pointer hover. A finger has no hover: contact is a click, lift is the end, and there is no steady state of “rest here and read.” No stable trigger on touch means that channel is unreliable on a touchscreen. It is not a claim about whether tooltip copy should exist. Long-press, or first tap shows the tip and second tap fires the action, are other gestures pressed into simulating hover, and they compete with system gestures and with the control’s own click.
Why it happens
A pointing device splits location and activation: move onto the target (hover), then press. Touch fuses the two into one contact, which the system must treat as activation or no button would ever fire. “Look without acting” has no legal input. Long-press is borrowed to fake hover, but it is already the competing gesture for context menus, text selection, and drag, and the delay has to be long enough to separate from a tap, so reading becomes “hold and wait.” First tap shows the tip, second tap activates, which breaks “tap means do” and cannot tell whether the user meant to read or to act. On touch, then, a tooltip either never appears, or appears awkwardly and injures other gestures. Information that must be read on a touchscreen has to move onto a surface visible before press.
Studying it
On the same icon buttons, identification that depends only on the tooltip, with mouse versus touch. Record the rate at which the tooltip is successfully invoked, which gesture invoked it, and clashes with long-press menus. Independent variables: no extra gesture, long-press tip, first-tap tip. Dependent variables: identification success, mis-activation, gesture conflict. On touch with no extra gesture, invocation should be near zero; with extra gestures, conflict should rise.
Where it stops holding
A two-in-one device in pointer mode has hover again; in touch mode it vanishes. The same UI cannot assume the channel is always there. Stylus hover exists on some hardware and is not a capability of all touch users. An attached keyboard can show the tooltip on focus; that rescues keyboard users, not finger users. Turning the tooltip into a tap-opened popover stabilises the channel and also turns the control into a popover, which must follow popover rules and must not still be called a tooltip.
Applying it
- Do not build identification on hover tooltips in a touch UI; show the name, or open a layer that includes the explanation.
- Do not simulate hover with long-press or with “tip first, action second.”
- On UIs shared by mouse and touch, the tooltip can only be an extra channel; the primary name still has to be drawn on the control.
- How to check: on a phone, with no mouse, finish an identification task. If a long-press or a second tap is required to know what the control is, the trigger is not stable.