Screens constrain overview browsing
Aliases: display fragmentation · keyhole effect · procedure overview loss
What it is
Electronic procedure display fragmentation occurs when a bounded display exposes only a few steps or one branch at a time, creating a keyhole effect — the name comes from looking at a room through a keyhole: what sits directly in front of the hole is perfectly clear, but no one can assemble the room's overall layout from a sequence of keyhole views. The current action may be legible while dependencies between steps, work that could run in parallel, and how much of the job's structure remains are all harder to apprehend quickly.
Why it happens
Paper builds a procedural map from three cues: a step's spatial position on the page (important content tends to live in a spot you remember), adjacent content visible at once across spread-out sheets, and the sense of overall thickness and progress that comes from riffling through pages by hand. A scrolling or paginated electronic interface replaces all of these stable landmarks with a single transient window — once the previous screen scrolls away, it no longer occupies any visual attention unless someone actively scrolls back. Collapsible panels, paginated navigation, and auto-jumping to the current step remove peripheral cues further, forcing the user to hold entirely in working memory three things paper used to show directly: where they came from, why a given branch was taken, and what downstream actions depend on the current one. After an interruption, recovery tends to restore only "the line the cursor sits on," not the higher-level goal that line was serving — the screen shows where you stopped, not why you stopped there.
Studying it
Studies can vary the number of visible steps, overview design (a navigation map, a progress bar, or neither), branch nesting depth, and where interruption is inserted, measuring dependency comprehension, backtracking, resumption errors, and completion time. Tasks must include prospective coordination — such as needing to stage material now for an action three steps later — or genuinely parallel dependencies; otherwise the comparison between a narrow and a wide display collapses into a difference in reading speed and misses the real loss in structural understanding. Navigation-log click counts should be paired with participants' verbal explanations, since frequent back-and-forth navigation is often purposeful verification of a dependency rather than getting lost — judging quality from navigation frequency alone can produce the opposite of the right conclusion.
Where it stops holding
A small screen need not eliminate overview: stable structural navigation (a fixed phase list, an expandable tree) and layered summaries can substantially compensate for physical size, so the real question is whether the design actively rebuilds landmarks, not how many physical pixels the screen has. Tasks that are genuinely linear, short, and require no anticipation of downstream dependencies are affected little, and heavy investment in overview design there has limited payoff. The opposite extreme — showing every step at once on one screen — is not the answer either, since dense information creates its own clutter and search cost; the actual objective is keeping task structure perceptible, not maximizing how much a page can hold.
Applying it
- Persist, in a fixed location, the current work phase, exact position, count of completed versus pending items, and the key downstream dependency tied directly to the current step, rather than surfacing this information only when scrolled into view.
- Offer a one-action overview with the current position highlighted; when returning from the overview to a specific step, preserve the scroll position and panel-expansion state the user left, so every overview check does not require re-navigating from scratch.
- Co-locate the current action with its prerequisites and the next consequential preparation it feeds into on the same screen, rather than scattering interdependent information across tabs or sub-pages that need extra clicks to reach.
- Validate through interruption recovery testing: introduce a deliberate interruption mid-task, and afterward, instead of asking which button was clicked, ask operators to state in their own words the current goal, the next dependency, and which branches remain unfinished — checking comprehension, not click success.