A product that spans form factors needs two schemes

What it is

A product used both on a pointer desktop and on a touchscreen cannot share one interaction that appears only when the pointer enters. Two schemes means: the desktop scheme may spend the gap hover gives, the touch scheme carries the same job with persistent chrome, a tap, or an explicit button. The switch follows the actual input form, not a wish for one design system.

Two schemes are not a visual reskin. Triggers and the moment information appears are written separately, then joined on the same task.

Why it happens

A cross-form-factor product faces two input vocabularies, not two artboards. The desktop scheme can hang secondary actions on arrival, so the first paint can stay sparse; the touch scheme has no arrival event to dispatch, so the same job must hang on press, press-and-hold, or a control that was visible from the start. Maintaining a single structure either strips desktop of preview or leaves touch without an entrance. The product-level answer is to admit two structures and choose at runtime, not to force-translate one into the other.

The choice is “does hover exist right now,” not how wide the window is. A two-in-one can be finger-driven at a wide width and mouse-driven at a narrow one; switching on breakpoints switches wrong. The two schemes have to be equivalent in task outcome: preview-then-click on desktop, open-details-then-confirm on touch, writing the same record. Two schemes that are not equivalent are two products, not a span across form factors.

Where it stops holding

A single-form-factor product does not need two schemes; building them is maintenance cost. Using press-and-hold on touch to stand in for hover collides with whatever press-and-hold already means on that form, and needs another exit. In a browser, fine versus coarse pointer media queries split some devices, but a tablet with a mouse plugged in, or a notebook with the keyboard folded away, will still be mis-classified. Scheme choice must be able to re-run when input changes, not once at launch. Gamepads and far-field remotes are a third vocabulary and do not fit a “desktop / touch” pair.

Applying it

• For every job that uses hover, write a two-row table: desktop spends enter; touch uses which persistent or tap entrance. Both rows must lead to the same result.
• Switch on pointer capability, not viewport width. Re-choose when a pointer appears or disappears, rather than waiting for the next launch.
• Verify with the same account and the same task once on a pointer desktop and once on a touch-only tablet. Desktop should be able to look before deciding; touch should finish without hover. Unplug the mouse and plug it back in: the session should change scheme, not stick.

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.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: K2.07 Touch Coexisting with Keyboard and Mouse · K8.07 Consistency versus Platform Convention
• Search terms: dual design · form factor specific interaction · hover and touch schemes