The actor is working with a collection too large or varied to take in whole, and what they are doing right now decides what matters in it — which items, in what form, in what order. A collection shown one fixed way answers someone else’s guess at that question, and the actor is left doing the framing work in their head, every visit.
Forces
- One collection vs. many purposes — the same items serve scanning, comparing, and planning, and each purpose wants different items in a different form and order
- Designer control vs. actor control — every part of the framing fixed at design time is a comparison the actor can no longer make; every part handed over is a decision the actor must now make and maintain
Solution
Give the collection a named projection — the same items shown from one angle — built from a query (which items), a representation (rendered how), and an arrangement (ordered and grouped by what), with the framing itself open to inspection and change.
Representation switching
One collection as list, board, table, calendar, map, etc. The items don’t change; the form they are rendered in do, and each representation makes different comparisons effortless (a board makes status visible, a calendar makes time visible, a table makes attributes comparable).
Attribute selection
Which attributes the compressed rendering carries decides what the actor can scan, compare, sort, and filter by. Handing that set to the actor is attribute visibility’s move; the framing owns its defaults — the subset each representation starts from before anyone touches it.
Saved views
Saved views persist the whole framing — query, representation, arrangement, visible attributes — as a named, shareable object, with three authorship poles: developer-defined defaults, role views an administrator curates for a team, and personal views the actor tunes for their own workflow.
Writable views
A view is not only read through — some edits are legal through the projection itself. Which edits, and through which representation, is a design decision: dragging a card between board lanes writes the grouping attribute.
Related components
- Representation: Table, cards, list, timeline, canvas, grid, calendar, gallery, kanban, gantt, the list goes on
- Action bar — the container for batch actions once a selection has been made
Resources & references
- Min, Chen, Cao & Xia (2025) Malleable overview-detail interfaces — fluid attributes
- Min & Xia (2025) Meridian — the saved framing generalised into a portable, declarative specification
- Shneiderman (1996) The eyes have it — the extract task: saving the sub-collection, or the settings of the control widgets themselves
- Bancilhon & Spyratos (1981) Update semantics of relational views — the view-update problem; with bidirectional lenses
- Fowler — Projectional editing — the same write-through-a-projection move, scoped to code editors
To-do
- Follow-up patterns to capture: search, pagination
Consequences
- the collection reaches the actor already framed — queried, represented, arranged — and the framing is inspectable and adjustable rather than baked in
- a framed population of items makes designating some of them for action cheap; what the framing exposes is what selection can operate on
Related patterns
Enables
- Selection — staking a subset of items as the target of subsequent action
- Overview and detail — the overview side: every item rendered in the same compressed form
Enacts
- Malleability — the framing controls hand the actor the view itself — what to show, how to render it, how to arrange it — the customisation most products still withhold
- Density — each representation is a density commitment: a table row, a card, and a map pin spend the same screen budget very differently
Complements
- Semantic zoom — scale-bound traversal between collection and item granularities, uniform across the population
Related
- Charting data — a chart is one of the representations a collection framing can take — the analytic sibling of table and cards
- Editing in place — writable views are this move applied through a projection; which edits resolve to the underlying data is data view's question
- Purpose-keyed view — data view supplies the framing machinery — query, representation, arrangement — that a purpose-keyed view fixes around one recurring purpose
Enabled by
- Attribute visibility — attribute visibility is the representation leg of the framing — the query picks the items, the arrangement orders them, the attribute set decides what each item shows
- Item view — a data view is many item views rendered in the same compressed form; which form — row, card, pin — is the representation choice
- Drag and drop — dragging is how a writable view takes its most direct edits — a card dropped in a lane writes the grouping attribute through the projection