Composing views

Added · Last updated
Prerequisites

The space is structured, and there is a surface to host the views. The actor's objects and activities are named, and the collection exists as a named thing with settled attributes and labels. That naming happens before this sequence, and no pattern here makes it.

The space is structured and a surface is waiting for views. Every collection needs the framing steps. Search, links between items, and a second view come later, when the collection calls for them.

Framing the collection

  1. Build the item's ladder — Item view

    Decide how an item looks at each level of detail, from a glyph or a reference through a summary to the full item, and what keeps it recognisable at every level.

  2. Frame the collection as a named view — Data view

    Choose the query (which items), the representation (which compact level of the ladder they show at, such as a row, a card, or a pin), and the arrangement. Set the defaults the actor meets before changing anything.

  3. Decide the labelling layer — Tag · optional

    Where items belong to several categories at once, or the words for them are still changing, let items carry labels instead of a single filed place. Skip this where each item has one settled category.

  4. Decide what each view carries — Attribute visibility

    Choose which attributes each view shows, including the labels, as a starting set, and let the actor change it.

  5. Open the arrangement and the query

    Three steps in no set order, and most designs take all three. They come after the attribute step because an attribute has to be visible before it can be sorted by, grouped along, or filtered on.

    In any order:

    • Hand the actor the order — Sorting

      Let the actor choose the order, and keep their choice.

    • Give the collection visible structure — Grouping

      Group items along an attribute the actor chooses.

    • Narrow to items matching criteria — Filtering

      Keep the active criteria visible on the surface.

  6. Decide which edits pass through the view — Data view, its writable dimension

    Decide which representations accept edits, what each edit changes in the underlying items, and a way to make every drag-based edit without dragging. Editing inside the view follows making changes.

Leaves: The actor meets the collection framed, and can see and change the framing. Framings pile up, and naming, sharing, and pruning them is decided in making sense at scale.

Applies when

Narrowing is no longer enough: filtering leaves the actor at a dead end, their criteria are not ones the attributes can express, or they know the item's name rather than its properties. The information architecture is settled, and any labels are facets the search can narrow by.

  1. Give intent an entry — Searching

    Decide between keyword and natural-language queries, global or local scope, and how the actor's words are translated into the system's vocabulary.

  2. Frame the result set

    Treat the results, ordered by relevance rather than by the collection's own structure, as a named view, and take the framing steps again over them.

  3. Keep the search reversible — Searching, its stability obligation

    Keep the context the search was launched from, so returning finds the actor's scroll position and framing intact.

Cross-references in place

Applies when

The collection's items are documents with many links between them. A collection of records with few links skips these steps.

  1. Let links be sampled in place — Link preview

    Preview links on hover or focus, with increasing commitment: peek, open alongside, open fully. Use the item ladder's summary level as the preview.

  2. Surface the unauthored connections — Dynamic hyperlinks

    When the collection outgrows what anyone linked by hand, show inferred connections as ranked suggestions, never as authored structure, and give them previews, since nobody chose them.

Splitting and coupling

Applies when

One view no longer serves both scanning many items and checking one, or several views have each earned a place by showing a different aspect.

  1. Split the view — Overview and detail

    Show the collection as two linked views: an overview with every item at the same compact level, and a detail view of the current item in full. Use the named view as the overview and the item ladder for both sides.

  2. Decide the content dimension per view — Attribute visibility

    Decide which attributes appear in which view. The overview's set decides what can be compared, sorted, and filtered, so let the actor change it.

  3. Decide layout and composition

    Place the views side by side, in place, in a popover, or on a new page, and decide how many there are and how they nest.

  4. Couple the views — Coordinated views

    Once there are more than two views, carry the actor's selection or focus between them, so relationships across views can be seen. Couple views only where it clearly helps; two views linked by a current item do not need it.

Connections