The problem
“Viewing an object” covers two different jobs that get conflated because they both start with a reader looking at data. Scanning a hundred campaigns to find the one that matters is reading a collection — that job already belongs to List view, and this page does not re-cover it. Once the reader knows which object they want and needs to know more about that one, the job changes: now it’s how much of it to show, and where. That second job still isn’t one answer. Glancing at one more field on a row already on screen, previewing an object without losing the list it came from, and needing the object’s full context before acting on it are three different amounts of reading, and three different surfaces already exist for them.Choosing a surface
The same two axes CRUD overview names — Density and Continuity — decide this from the reader’s side rather than the author’s: how much do they need right now, and can they afford to lose sight of the list while getting it.1
Inline expansion — one more layer, no surface change
A row already shows the object’s name and status. Revealing one or two more fields in
place — without opening anything — is Progressive disclosure’s
territory exactly. That page already decides the trigger, the default state, and when a
“show more” control is the right scope. This page is citing that answer, not deriving a
second one for objects specifically.
2
Drawer preview — oriented, without leaving
The reader wants more than a glance but still needs the list behind them — checking three
campaigns in a row without losing their place in a filtered table, for instance.
Drawer’s own “Choose Drawer when”
section already states this exact case: editing, configuring, or reviewing one item while
the list or page it came from stays visible. A read-only preview is the same reasoning
applied to viewing instead of editing.
3
Full Detail view — full context, possibly to act on it
The reader needs everything about the object, not a subset, and losing the list is an
acceptable cost for it — often because they’re about to act on what they find. This is
also where Update’s full-surface edit usually
lives: an object with enough permanence to have a Detail view at all is the same object
whose ongoing edits, once past the quick-create Modal, land on that surface or a Drawer.
Reading and editing converge on the same destination once the object has earned it.
When this applies
- The reader already knows which object they want; the question is how much of it to show and where.
- The object has enough attributes, or enough related data, that “which one” and “what about it” are genuinely different questions.
When it doesn’t
Structure
Behavior
Constraints
Content
Accessibility
- Opening a Drawer preview is expected to move focus into it and return focus to the trigger on close, the same as Create’s own Drawer behavior — though Drawer’s own accessibility section notes this is not confirmed by a test in source. Treat it as the expected behavior, not a verified one.
- A full Detail view’s navigation is announced the way any page navigation is; no additional live region is needed beyond what routing already provides.
- Inline expansion’s trigger and disclosed state follow
Progressive disclosure’s
accessibility section — an accessible name stating what’s revealed, and
aria-expandedwired at the call site rather than assumed.