Relative positioning: transmitting displacement increments rather than position

What it is

Relative positioning reports direction and displacement since the previous sample rather than controller location. Mice and trackpads accumulate those deltas onto the current cursor location, so the same place on a control surface can move different screen locations at different times.

Why it happens

The system stores the cursor's current location and adds each input delta after gain is applied. A small control surface can therefore traverse a large display and the hand can return to a comfortable start point without output. The result depends on history, however: people must relate hand movement to a cursor already somewhere on screen and locate it before moving.

Relative positioning has no self-correcting position reference. Each delta stacks on the previous result; if a sample is dropped, amplified by an acceleration curve, or skewed by timer jitter, the error does not reset at the next sample the way it would under absolute positioning — it just keeps accumulating. What actually closes the loop is vision: people see the cursor land somewhere unexpected and correct with the next hand movement. That is why relative positioning needs a visible, continuously updated position indicator — the moment that visual channel is cut or delayed, the accumulated relation runs away, whereas absolute positioning still "knows" where it is under the same conditions, because every sample reports a location rather than a change from the last one.

Where it stops holding

Relative input need not have a visible mouse cursor: game controls, knobs, and focus navigation can also accumulate deltas. Lost samples, unexpected acceleration, remote latency, or system-initiated cursor movement make the relation unpredictable. It cannot be treated as absolute location input for multitouch or handwriting.

Under remote-desktop or high-latency connections, visual feedback lags behind the deltas already sent: people start their next correction before they have even seen the cursor arrive, producing sustained overshoot — not a device fault but a closed loop broken by delay. In voice-only interaction, or whenever the visual channel is occupied or obstructed, relative positioning is nearly unusable on its own, precisely because it depends on the channel that has been cut.

Applying it

• Keep accumulation and gain predictable; make any programmatic cursor or focus move immediately visible.
• Support clutching, scrolling, or zooming for large travel rather than requiring one gesture to span the distance.
• Test first movements toward the same target from varied cursor starts, checking for search and corrective reversals.
• Add a perceptible display delay in a test environment and repeat the same task set, checking whether overshoot rises with the delay — this surfaces usability problems in remote or high-latency use before they ship.

Related

• Same group: C1.02.1 Absolute positioning: a one-to-one relation between device and display space · C1.02.3 Absolute positioning removes visual search for the cursor · C1.02.4 Relative positioning permits clutching beyond physical bounds · C1.02.5 Touchscreens are absolute; trackpads are relative
• Nearby: C1.03 Control-display gain · C1.04 Mouse acceleration curves
• Search terms: relative positioning · delta input · cursor control