C1.04.1Pointer accelerationdesignresearch

Acceleration dynamically changes gain with movement speed

Aliases: mouse acceleration · dynamic gain · velocity-dependent gain

What it is

Pointer acceleration changes control-display gain with device movement speed: slow motion moves the cursor less and a fast flick moves it farther. The same physical distance can yield a different screen distance at a different speed. It is a nonlinear, velocity-dependent mapping, not merely higher fixed sensitivity.

Why it happens

An acceleration curve assigns high gain to rapid transport and low gain to slow correction, attempting to reduce both long travel and endpoint overshoot. The system estimates velocity and applies a gain from the curve; thresholds, slope, sampling, and filtering all affect the feel. Latent or uneven velocity estimates make response appear to jump.

Behind this design sits a two-phase model of aimed movement: a pointing action typically starts with a fast ballistic transport that brings the hand near the target, followed by one or more slow corrective phases that settle the cursor onto it. What an acceleration curve is actually trying to do is apply high gain only during the ballistic phase and fall back toward near-fixed gain during correction, so each phase gets its own optimum. This is exactly why the wrong threshold or slope flips the outcome: if the curve stays in its high-gain region during correction, small deliberate adjustments get amplified into large ones and the user ends up over-correcting — and the correction phase is precisely where velocity estimates are noisiest, since low speeds give the poorest signal-to-noise ratio, so estimate jitter there is most easily misread by the curve as a fast intentional move.

Studying it

Compare fixed and velocity-dependent mappings with slow fine adjustment, rapid crossing, and variable-speed trajectories; measure time, errors, overshoot, and perceived predictability. The reciprocal tapping task and throughput measure (bits/s) from ISO 9241-9 put different curves and devices on a common scale, but the ballistic and corrective phases should be timed separately rather than folded into one movement-time average — otherwise a curve that helps in the ballistic phase and hurts in the corrective one can look like a wash. Report the complete curve and system version: “acceleration on” is not reproducible across platforms.

Where it stops holding

Acceleration suits discrete pointing only when velocity can imply intent. It need not suit drawing pens, absolute touch endpoints, or force controls. With latency, tremor, or dense targets, unstable velocity estimates can add correction rather than improve acquisition, especially during the corrective phase described above. Sensor noise at very low speed on a high-polling-rate mouse, or a low sampling rate that lags the velocity estimate, can both make the curve's response feel like a sudden jump rather than a smooth follow.

Applying it

  • Make velocity-dependent mappings continuous and intelligible, avoiding jumps at thresholds.
  • Offer a fixed mapping or precision mode for work requiring stable control.
  • Validate slow, fast, and mixed-speed paths, inspecting overshoot and reverse correction at curve transitions.
  • Hold the ballistic phase's entry speed constant for a given target width and vary only the final approach speed, tracking overshoot rate and correction count for that phase alone — this pinpoints the speed range where the curve starts working against the user.

Related

  • Same group: C1.04.2 Acceleration disrupts a stable device-to-screen mapping · C1.04.3 Acceleration is a net loss for tracing and drawing · C1.04.4 Acceleration must be disableable
  • Nearby: C1.03 Control-display gain · C1.08 Drag and drop
  • Search terms: pointer acceleration · velocity-dependent gain · transfer function

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/C1.04.1