Drag-follow latency thresholds sit far below click response
Aliases: touch tracking lag · dragging latency · follow-the-finger
What it is
Tap a button 80 ms late to highlight, and most people still feel a clean press. Drag a slider 80 ms late, and a gap opens between thumb and thumb-piece; the whole gesture feels rubber-banded. Tracking latency has a far lower detection threshold than click latency: continuous following has to stay with the hand frame by frame, while a discrete click only needs one state change inside the causal window. The two must not share a single “be fast” metric.
Why it happens
Dragging is closed-loop control. The hand moves, the eyes take object position as an error signal, and the next increment is corrected from that error. Every extra frame of delay in the loop applies a stale error, so the object oscillates or sticks and people slow the hand to wait for the loop. A click is open-loop: press, wait for one confirmation. Confirmation can arrive at the edge of the instantaneous window because there is no continuous error to correct.
So the thresholds differ by a factor of several. On touch dragging, an extra twenty or thirty milliseconds is already stably detectable; a click can approach a hundred milliseconds before “I pressed” turns into “it replied”. Frame rate writes the gap into hardware: one frame at 60 Hz is ~17 ms, which sits near the dragging threshold and is almost invisible on a click.
Studying it
Jota, Ng and colleagues injected latency into pointing and dragging on high-refresh apparatus and measured detection thresholds and performance. Dragging is more sensitive: at the same delay, path error and subjective “following” scores collapse first, while click accuracy still holds.
Independent variables: injected delay, task type (tap / drag / pinch), display refresh. Dependent variables: delay detection threshold, path error, completion time, subjective tracking ratings.
Labs often use a contact display and a planted arm. Phones held in one hand, gamepads and mice each have their own baseline latency. Thresholds have to be remeasured on the target device; do not copy 20 ms from desktop touch into a phone acceptance test.
Where it stops holding
Inertial scrolling after lift-off is no longer closed-loop tracking; the tracking threshold governs the finger-still-on-glass segment. Keyboard shortcuts and a remote’s “OK” belong with clicks. Eye and head as pointers often need a tighter tracking threshold because the head moves faster and the predictive model is more brittle. In networked collaboration the other person’s cursor is necessarily late; do not judge remote cursors by tracking standards. The local pointer still must meet them.
Applying it
- Split delay budgets: clicks may align to the instantaneous window; drags must align to frame time.
- Compute dragging, pinching, drawing and scroll-follow on the local UI thread. Do not send them through the network or a heavy relayout.
- Measure separately in acceptance: button press to highlight, and finger-to-object gap while dragging. A single “mean response time” will wash the dragging failure out.
- How to check: on the target device, drag a small object across the screen. A stable spatial gap or a tug-of-war means tracking has failed — even if buttons on the same page still feel fast to tap.