A master-detail view keeps the list in context
Aliases: split view · list and detail · collection plus inspector
What it is
A master-detail view puts the collection on one side and the current object’s detail on the other, both on stage. Its value is not “looks like a professional tool.” It is list context retained: after reading this record, neighbours’ names, statuses, and sort positions remain in peripheral view, and moving to the next row does not mean leaving detail and relocating the list. A single column of “open, then back” hides the collection on the previous page and rebuilds context every time.
Why it happens
Inspection and comparison move through a collection; they do not settle inside one record. Detail spends working memory on understanding this item; the list externally stores “which stretch I am in, who sits beside me.” With both columns visible, changing row is a selection, not a navigation: scroll, filter, and read-state remain. Pushing a full-screen detail turns the collection into a stub in memory, and return has to recover scroll and the neighbour that was half-seen. Master-detail cuts navigation from stack-push to reselection, provided the list column is actually carrying context — if it is shrunk to icons, or the detail covers it, context is present on paper and gone in fact. The list column also has to show the selection against its neighbours, or it is a row of triggers, not context.
Studying it
On the same mail or records, compare master-detail with push-detail-and-back, on an inspection task (process items while checking neighbour state) and a deep-read of one item. Independent variables: whether the list column is visible, its width, how rows change (click neighbour / back then in). Dependent variables: time to change row, lost position on return, misread neighbour state. Inspection should be faster in master-detail; deep-read need not be, because it does not need neighbours.
Where it stops holding
With one item, or a task that almost never changes row, the list column is persistent noise. A portrait phone that cannot fit two columns will only shave both into uselessness if it insists on master-detail; it should degrade rather than keep both on stage. If the list column cannot update selection (a title changed in detail still shows the old name), context lies. Read-only preview can stay split; an edit with many fields may squeeze the list into a meaningless strip, in which case edit should take the surface and the list should become recallable.
Applying it
- Use master-detail for inspect, compare, and walk-through workbenches. Keep the list column wide enough to read identifiers and see selection.
- When detail changes an object’s name or status, the corresponding list row must follow, or context is stale.
- Do not fake master-detail with a full-page jump: if the URL replaced the list and the list unmounted, it is not master-detail.
- How to check: process three of ten items, then ask for a neighbour’s current state. If answering requires returning to the list, context was not kept.