Hover-dependent designs cannot migrate to touch

What it is

An interface that stores information, entrances, or state changes on “the pointer entered, and has not yet pressed” fails structurally when it is moved to a touchscreen. Touch has no such beat: a finger coming down is already an activation. Buttons that appeared only on hover, copy that could be read only on hover, panels that expanded only on hover, have no corresponding event, so the capability vanishes from the product rather than taking another shape.

The failure is the act of migration. How to prepare two schemes is the next step; this entry only judges that the hover-dependent scheme does not survive the crossing.

Why it happens

Desktop’s design freedom is built on the enter event. A toolbar whose icons exist only on hover, a price or permission that exists only as hover copy, a secondary menu that opens because the pointer passed, is capability stored inside one input event. Touch’s event vocabulary is contact, move, lift—there is no “enter without activate.” Pixels can be copied—the same layout, the same paint—but the trigger cannot. Comparisons of mouse and touch in the Forlines and Wigdor line keep finding that information on the hover path is the first to go missing when the input changes.

So this is not a missing stylesheet. :hover is sometimes faked on touch by the first tap, but that tap has already spent the beat that belonged to activation; preview and submit collapse into one, and a menu may pin itself to the screen. The deeper the dependence, the larger the hole after migration: losing a hint still leaves a usable product; losing the only entrance does not.

Studying it

Place an unmodified desktop UI on a touch device and run the same tasks (a migration-failure experiment). Record which steps have no event to fire. Contrast with a version whose entrances were rewritten for touch. Independent variables: whether hover carries a hint, the only entrance, or a state change. Dependent variables: task dead-ends, first taps taken as previews, times the former hover content cannot be found.

Clicking with a mouse on a touch emulator measures the failure away—the emulator still has a pointer. Use a finger, or a tablet with the pointer disabled.

Where it stops holding

Devices with a stylus that reports pen hover fail a step more lightly, but finger users still fail. A two-in-one notebook still has hover in clamshell posture; the same UI collapses the moment it is folded into a tablet. Hover used only for decorative highlight, never for information or entrance, loses affordance rather than function. Gamepads and ten-foot television also lack hover; the failure shape is similar, not unique to touch.

Applying it

• Inventory every information and entrance on enter events, and mark “if enter never fires, can this step still finish.” Anything marked no is a migration-failure point.
• Do not add a layer of touch clicks on the desktop UI and hope the first tap impersonates hover. That postpones failure until the second tap.
• Verify by completing every primary task on a tablet with no pointer. Any step that needs “hover first, or it cannot be seen or clicked” has already failed migration. List those steps; do not claim the product “also supports touch” before they are rewritten.

Related

• Within the group: K2.06.1 Hover allows preview and hints without commitment · 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.5 Hover delay must filter pass-through mouse movement · 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.06 Hover States and Their Absence on Touchscreens · K2.07 Touch Coexisting with Keyboard and Mouse · D1.12 Distinguishing focus, hover, and selection
• Search terms: hover migration · hover-only UI · touch has no hover