Two panes keep the list and the detail on screen together

What it is

A tablet or an unfolded foldable has a work surface wide enough for two panes: the collection in one, the current object in the other, both in view. The point is not an extra column of chrome. It is that switching items does not unload the collection—names, flags, and sort position stay in peripheral vision, and the next item is a change of selection rather than a round trip. Phones trade time for width with drill-in and back. A large screen that still pushes a full-screen detail wastes the extra physical width. How pane ratios follow the window, and when the layout must collapse, are separate problems.

Why it happens

Inspection moves through a collection. Detail occupies working memory for the current item; the list externalizes “where I am and who sits next to it.” When both panes are readable, switching costs about one tap. Once the list leaves the screen, that coordinate has to be rebuilt from memory or from navigation. Tablet width is what makes simultaneity possible: each pane still has to meet its own minimum for type size and hit targets. Side-by-side layout without those minima is not two-pane use, it is two starved columns. A large screen that keeps a single-pane stack throws away spatial memory; the device is then just a phone with bigger type. A list pane reduced to icons, or covered by the detail, keeps the look of two panes after the context has already gone.

Studying it

On a tablet in landscape, run the same mail, file, or record set under “list and detail both visible” versus “full-screen detail plus back.” Split the work into inspection (process items while checking neighbors) and deep reading of one item.

Independent variables: whether the list stays in view when detail opens, whether the list pane shows identifying fields, whether switching is a tap on a neighbor or back-then-in. Dependent variables: switch time, misjudged neighbor state, lost position after return, subjective workload.

Inspection should be faster with two panes; deep reading need not be, because it does not use neighbors. Do not substitute desktop-window data for tablets—selection is touch, there is no hover preview, and the switch gesture is not a mouse click. Lab scripts that force people to finish every item will undercount real abandonment when context is lost.

Where it stops holding

A one-item collection, or a task that almost never switches, makes a persistent list pane noise; a single-pane detail is cleaner. Short read-only previews can sit side by side; a long edit form will crush the list into a sliver, and editing should let detail take the window for a while. Portrait hold, split-screen, and a folded cover display can drop below the width two readable panes need; forcing two panes then makes both unusable. With a hardware keyboard and a pointer, arrow keys can change selection, so the “tap the neighbor” advantage shrinks, but the list still serves as external memory.

Applying it

• Default to two panes on tablets for mail, files, threads, and grouped settings—the work of walking a collection. Do not scale up a phone stack.
• Keep identifying fields and selection state readable in the list; if detail edits a title or a flag, the corresponding row has to update, or peripheral context is stale.
• Switch by changing selection. If the navigation stack unloads the list, it is no longer two-pane.
• Verify by processing three items out of ten, then asking for a neighbor’s current state. If the answer requires going back to the list first, simultaneity did not hold.

Related

• Within the group: K3.01.2 Pane widths have to track the window · K3.01.3 A narrow window collapses to one pane and still needs a way back
• Adjacent: E4.08 Split Views and Master-Detail · K3.05 Split-screen and Multitasking · K2.01 Window Management
• Search terms: two-pane · split view · list-detail simultaneity