On touch, long-press competes with other gestures
Aliases: touch and hold · gesture competition
What it is
Desktops invoke a context menu with a secondary click. Touch has no second button, so most products use a long-press (touch and hold). Long-press is not an idle channel: the same contact also hosts scroll, tap, drag, text selection, and the system’s own long-press menu. On touch, a context menu is a gesture-contention problem first, and a question of what is in the menu second.
Why it happens
A contact is an unfinished gesture until lift. The system classifies it with a time threshold and a movement threshold: lots of movement is scroll or drag; time elapsed with almost no movement is long-press; a quick lift is a tap. The context menu wants the cell “time elapsed and barely moved”. But people about to scroll often hold first and then choose a direction; once hold time nears the threshold, the menu pops before scroll starts and covers the list. Long-press on text is already claimed by the system for word selection; stacking an object menu on the same cell makes the two fight, or fire in turns. In a reorderable list, long-press is also the pickup for drag, and the object menu has almost no time slice of its own.
Raise the threshold and people who want the menu wait so long they conclude there is none. Lower it and every passing hold becomes a menu. With no second button the channel is crowded by nature. Adding another flavour of long-press will not fix it; one gesture has to be given priority on this kind of object.
Studying it
On a list, on text, and on a draggable item, assign tasks to “open the context menu”, “scroll”, “drag to reorder”, and “select text”, and record which class the gesture was judged as. Independent variables: long-press time, allowed movement, whether drag is also enabled. Dependent variables: success of the intended gesture, false menu opens, times scroll was interrupted by a menu.
Finger size and age shift the threshold; a lab “just right” for young adults may be too short for others.
Where it stops holding
Devices with a stylus or a keyboard can return to a second button or a modifier, and contention drops. When the system already offers a standard object-menu API, let it arbitrate rather than stacking another application long-press. An explicit in-object button (More) does not use the long-press channel, and fits surfaces whose gestures are already packed. Pointer desktops do not have this problem.
Applying it
- On a surface that already drags or selects text, do not make long-press the only entry to the object menu; give a visible More.
- On lists that share long-press with scroll, make the movement threshold crisp: movement at the start belongs to scroll; do not pop a menu mid-scroll.
- When it collides with the system long-press menu, follow the system or explicitly disable one; do not let two menus appear in sequence.
- How to check: on the target surface, scroll, drag, select a word, and invoke the menu in sequence. Any “meant to scroll, got a menu” or “meant to get a menu, started a drag” is contention. Then set hold time to what users describe as “I held a moment”; the menu should still invoke reliably, and a passing hold should not.