Map interactions

Maps are the canonical case for direct-manipulation perception failure. The user drags the canvas; tiles need to load; if the tile load blocks the drag, the manipulation stops feeling direct and starts feeling stop-and-go. The perceptual ceiling here is brutal — Jota et al. 2013 Jota et al. 2013 puts the just-noticeable-difference for direct-touch dragging at ~33 ms; Ng et al. 2012 Ng et al. 2012 resolved single-millisecond differences in trained users. There is no realistic budget for "pan, then wait for tiles, then update." The pan has to be free; the tiles have to catch up.

This scenario sits in the 0–100 MS band Card-Moran-Newell Card, Moran & Newell 1983 describe. Card et al. 1991 Card et al. 1991 covers the ~10 Hz refresh rate at which progressive tile loads need to fire to register as continuous motion rather than as a series of discrete frames. The trick is to decouple input handling from data fetching, and to give the user a visual signal that tiles are still loading without making them wait for it.

What is happening in the demo

A 4×4 viewport over a tile grid that extends in every direction. Each tile's colour is deterministic from its (x, y) coordinate — you will recognise tiles when you pan back. Both sides simulate a tile load at p50 of 450 ms (gamma-distributed) on first encounter; subsequent visits to the same tile are instant in the tuned implementation but re-fetch in the naive one.

The naive side disables the pan controls during the tile load. Press an arrow; the controls grey out; a "Loading tiles…" overlay appears; ~450 ms later the viewport shifts to the new position and the controls re-enable. Your finger is on the next arrow key but you cannot use it. Stop-and-go.

The tuned side never disables the controls. Press an arrow; the viewport shifts immediately. Tiles you have already seen render at full saturation; tiles that have not finished loading render at 60 % opacity and 50 % saturation — the dominant colour is in place, the detail is on its way. As each tile completes its simulated load, it fades to full saturation over 300 ms. You can pan continuously, faster than the tiles can load, and the map catches up without you ever waiting on it.

The cached-tile mechanic is the second perception lever: tiles only "load" once. Pan back to a tile you have seen and it is already at full saturation. Real maps (Mapbox, Google Maps, the Apple Maps web client) all use this — the tile cache is what makes long pan sessions feel responsive even on poor networks.

What to tune

1. Input echo — pan responds sub-frame. The viewport shifts immediately on arrow press or drag; input never blocks on the network.
2. Placeholder tiles — in-flight tiles render at 60 % opacity and 50 % saturation. The dominant colour holds the layout; the LQIP principle without a real low-res image.
3. Tile resolution — each tile fades to full saturation over ~300 ms as it lands. Matches the perceptual frame.
4. Cache — visited tiles are instant on revisit. Stale-while-revalidate shaped for spatial data.
5. Predictive prefetch — tiles in the cursor's decelerating direction load ahead. Tune the radius against pan velocity.

When perceived performance hurts you here

Decoupling input from tile loads only works if the cached map state is honest about what it has. A user who pans far past the loaded zone and sees a smooth grid of placeholder tiles for ten seconds without any progress signal will conclude the map is broken, not that it is loading. Past a pan distance threshold, surface a determinate "Loading map data…" affordance — the failure mode of the tuned pattern is too much smoothness for too long.

The other failure is over-aggressive prefetching. Loading every tile within ten cells of the cursor wastes bandwidth and triggers tile-cache eviction for tiles the user is actually looking at. Production maps tune the prefetch radius to the user's recent pan velocity and direction — a slow drag prefetches narrow, a fast pan prefetches wider in the pan direction.

For touch devices, the gesture is pointermove with high-frequency events; the tile fetch must be debounced so a continuous swipe does not fire fifty individual fetches. Map libraries handle this with quad-tree-keyed request batching — the implementation is complex but the perceptual lesson is the same: the user's gesture is the source of truth, not the network.

Accessibility

1. Keyboard pan — arrow keys (with optional modifier for larger steps) must move the viewport. The pan controls in the demo are visible buttons for clarity, but production maps usually accept arrow keys directly when the canvas is focused.
2. aria-label describing the visible region after each pan ("Map centred at coordinates 3, -2, viewing 4 by 4 tiles"). Without this, screen-reader users have no signal the pan moved them.
3. prefers-reduced-motion — the tile fade and the pan transition both reduce to instant state changes. The cursor-to-content coupling is content, not motion.
4. Touch targets — pan controls should be ≥ 44×44 px (Apple HIG / Material guidance). The demo's 28×28 px controls are visual only; production maps would size them up.
5. Focus return — after a pan, focus stays on the control that was pressed (or on the map canvas itself if the user was using arrow keys). Never reset focus to the page top.

References