A directional threshold can distinguish horizontal dragging from vertical scrolling at gesture start

What it is

A directional threshold compares horizontal and vertical displacement early in a gesture, deciding whether later movement is a horizontal drag or vertical scroll. It is common for horizontally swipable cards within vertically scrolling pages, preventing one diagonal beginning from moving both object and page.

Why it happens

The system accumulates initial travel, then compares axis components or direction-sector angles once total distance is sufficient. The dominant axis claims the gesture and the other is delayed or suppressed. Early trajectory is evidence of intent, but evidence near a diagonal is inherently ambiguous and premature lock misassigns it. Once an axis wins, reversing that decision usually needs a margin of hysteresis: without it, a finger path that wobbles slightly between the two directions causes ownership to flip back and forth between horizontal and vertical, and the scroll feels like it keeps stuttering to a halt — which hurts the experience more than a single wrong call, because one wrong call is a single misjudgment while repeated flipping is a continuous breakdown of feel.

Studying it

Test angles, speeds, content density, and start points, recording intercepted scrolls, failed horizontal drags, switches, and time. Analyse near-45-degree trials specifically, comparing fixed ratios, dynamic tolerance regions, and strategies that allow early reconsideration. The hysteresis margin itself needs separate measurement: have participants move repeatedly along a path deliberately close to the diagonal, and count how many times axis ownership actually flips, to judge whether the current margin sufficiently suppresses that oscillation.

Where it stops holding

Direction lock does not suit truly two-dimensional drawing or map panning. Strong locks make natural diagonal drags feel stuck; weak locks restore competing gestures. An explicit drag handle, mode, or multi-finger gesture can be more reliable than guessing direction. Touch systems also often reserve their own gesture zone along the screen edge for system-level navigation, and an application's directional lock cannot extend into that zone without colliding with a system gesture that always wins priority — this is not something the direction-lock algorithm itself can resolve, but something that has to be designed around from the start by ceding that edge strip entirely.

Applying it

• Keep a brief undecided zone at the start, locking only after enough travel is observed, and add a reasonable hysteresis margin after locking so axis ownership does not flip back and forth on a wobbling path.
• Bias toward vertical scrolling in reading pages and toward horizontal drag on explicit card handles.
• How to check: log the angle distribution at the moment axis lock actually occurs in real usage, isolate the samples that fall near the diagonal (say, within roughly 35 to 55 degrees of either axis), and check whether this subset's misclassification rate is significantly higher than the rest.

Related

• Same group: C1.22.1 A threshold that is too small misclassifies natural hand tremor as drag intent · C1.22.2 A threshold that is too large discards real short drags as clicks · C1.22.3 Drag thresholds must scale with input precision and display density, not fixed pixels · C1.22.4 While held below threshold, the cursor should show no drag feedback
• Nearby: C1.23 Two-finger and horizontal scrolling · C1.20 Hover delay and false activation
• Search terms: directional lock · gesture disambiguation · scroll