Inertial scrolling friction and stopping expectations

What it is

Inertial scrolling friction is the response function by which content keeps moving and gradually decelerates after a finger or trackpad is released. People predict where it will stop from launch speed, prior experience, and content density; friction and deceleration determine whether that stopping expectation holds.

Why it happens

The system converts terminal input velocity into content velocity, then continuously decays it along a friction curve. Low friction lets one flick travel farther but makes it harder to stop precisely; high friction aids positioning but requires repeated input. When frame rate, loading, or boundary bounce alters velocity, the internal prediction and the actual endpoint diverge, producing backscroll and correction.

Where this predictive ability comes from is worth tracing one layer further: people are not running a precise physics calculation, they are encoding "how fast this flick was, how far it usually goes" as a form of motor memory built from statistical regularities accumulated through repeated use on the same device, not a real-time computation performed each time. This explains two things. First, switching friction coefficients across contexts (a list uses one curve, a canvas another) breaks that memory, and people will systematically overshoot or undershoot on the unfamiliar curve. Second, a unified OS-level friction curve matters because it lets "about how far one flick goes" transfer across applications — an app that quietly substitutes its own curve is secretly rewriting a prediction model the person already built elsewhere.

Studying it

Manipulate launch speed, deceleration, content length, and target position. Record endpoint error, reverse scrolling, retouch time, motion discomfort, and completion time. Test short lists, long text, nested containers, and boundaries rather than only average travel on an infinite canvas. To test whether motor memory has actually been broken, use a repeated-measures, cross-session design: have the same participants practice to stability on the system default curve, then switch to a custom curve, and watch for a short-term rise in endpoint error.

Where it stops holding

Physical realism does not necessarily mean usable: line-by-line reading, low visual stability, or precise-stop tasks may favour shorter or no inertia. Platform-established scroll feel is itself a source of expectation, so an in-app custom curve should not diverge without reason — unless the application's core task (continuous panning in a professional canvas tool, say) genuinely needs a feel different from a reading list, and that difference is made explicit.

Applying it

• Use continuous, stable deceleration and boundary behaviour so similar flicks produce predictable endpoints; do not deviate from the system default friction curve without a specific reason.
• Allow immediate touch or wheel input to interrupt inertia instead of making people wait passively.
• How to check: measure near-target endpoint error and reverse correction, tuning friction for the content task rather than visual spectacle; compare first-use error between the system default and a custom curve for the same users, to confirm the custom curve has not systematically broken an existing prediction.

Related

• Same group: C1.11.1 Discrete step scrolling and pixel-level smooth scrolling · C1.11.3 Scroll-position jumps and anchoring under asynchronous loading · C1.11.4 Scroll hijacking breaks expectations of user control
• Nearby: I1 State, time, and response · C1.08 Drag and drop
• Search terms: inertial scrolling · scroll friction · motor memory