K5.01.2spatial navigationdesignresearch

Focus movement must follow spatial intuition

Aliases: 2D focus traversal · focus search · D-pad spatial map

What it is

Pressing Right should land on the neighbor that looks to the right—not the start of the next row, a hidden overlay, or the next DOM node on the far side of the screen. Movement by geometric adjacency rather than document order is spatial navigation. On the sofa, eyes on a poster wall, the hand on the D-pad is saying “nudge that way,” not “next in the focus sequence.”

Why it happens

Direction keys encode directions on the screen plane, not a preorder walk of a tree. If a visual neighbor is not adjacent in the focus graph, the press lands off the gaze, and the user has to find focus before aiming again. Irregular grids, nested horizontal and vertical strips, uneven card sizes, and wiring “next” to a list index all produce that mismatch.

The focus graph is directed: each focusable node has at most one outgoing edge per direction. If those edges are built from bounding-box center angle, overlap projection, or author-written nextFocus, and the three rules mix on one screen, the same direction behaves differently in different regions. Nested containers make it worse: focus traps inside a row, or a single press vaults a whole block into the footer.

Spatial intuition includes edges. At the rightmost item, another Right may clamp, wrap to the leftmost, or spill into the next row. All three are legal; they must match what the screen looks like. Poster rails wrap; settings lists clamp. Mixing them feels like a broken key.

Studying it

Use a spatial navigation task: on a real or paper TV layout, name a start and a target, allow only a four-way pad, and count how far the actual path exceeds the shortest path along visual neighbors, plus how often focus appears where the participant was not looking.

Independent variables: layout regularity (strict grid / mixed card sizes / nested strips), graph-construction rule (geometric projection / DOM order / hand-authored edges), edge policy (clamp / wrap / row wrap). Dependent variables: extra keypresses, off-gaze jumps, time to target, verbal reports of “where did it go.”

Lab targets are named by the experimenter, so people plan a path while staring at the destination. In a living room they nudge while watching content; a sudden jump to the footer costs more. An algorithmically optimal focus graph is not the user’s geometric neighbor—it minimises graph distance, not whether a poster’s centre sits in the visual cone of the key.

Where it stops holding

A single-column settings page barely has 2D neighbors; up and down a list is enough, and invented left/right edges dump people into a sidebar. Once a trackpad or air mouse supplies a continuous pointer, spatial navigation is fallback and the wiring of edges matters less. When focus order also serves a screen reader, document order and visual order can conflict; the graph a sighted living-room user needs is not the graph a listener needs, and one set of hand-authored edges will not serve both. Ads inserted between two presses rewrite neighbors, so spatial memory expires in seconds.

Applying it

  • Build four-way neighbors from screen geometry: the visible focusable whose projection on that axis overlaps most and whose centre angle is smallest. Do not string items by DOM or data index.
  • Pick one edge policy per screen and let the layout announce it: wrapping rows should look like a loop; list endpoints should feel like endpoints.
  • Separate in-row horizontal movement from page-level vertical movement. Left/right walks cards inside a row; up/down leaves the row. Do not drop from the last card in a row into the first card of the next row on another Right.
  • Verify by pressing each of the four directions once from every focusable item and checking that the landing is the neighbor the eye expects. Mark every “where did it go” as a defect rather than compensating with extra keypresses.

Related

  • Within the group: K5.01.1 There is no pointer, only a current focus · K5.01.3 Focus must remain clearly visible at all times
  • Adjacent: J3.02 Focus order and focus traps · C6.22 Focus order and keyboard navigation · F1.01 Distance between control and object
  • Search terms: spatial navigation · focus search · D-pad

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/K5.01.2