Making sense at scale

Added · Last updated
Prerequisites

A collection has grown too large for one view, such as an archive, a backlog, a library, or a record of runs, and the actor's question is not yet specific enough to write as a query. No pattern here settles this.

An actor is working with a collection too large to take in through one view. They do not yet know exactly what they are looking for, so they cannot simply search or filter for it.

Choosing how to show the collection

  1. Choose how detail and the overview share the screen

    Choose for each surface; the options can be combined. Each keeps the overview available at a different cost: a second view takes space, a scale control takes time, a graded view loses detail at the edges, and a generated summary has to be checked. In every case, open on the overview and show detail on request. Skip this step when the work is discrete items moving through a defined process, where the item and the queue already give enough structure.

    Combine any of:

    • Split the view — Overview and detail

      Show the overview and the detail as two linked views. The splitting steps of composing views continue from here.

    • Change the representation with scale — Semantic zoom

      Show one level at a time under a scale control, with a few named levels such as year, month, and day. Decide where the thresholds between levels sit and how the change between them looks.

    • Show full detail only where the actor is looking — Focus and context

      Show one continuous view with full detail at the focus and a reduced outline around it. Decide what produces the outline, and label it if it is generated.

    • Generate summaries at several levels — Text lens

      For prose, generate the levels, such as heading, abstract, and full text, instead of writing them in advance. For a whole collection, generate an overview that helps the actor gather items rather than judge them, and link every claim in it to its source.

  2. Show the difference directly — Comparing · optional

    Give the comparison its own representation, side by side, overlaid, or with the difference drawn, so the actor does not have to keep one view in memory while looking at the other. Build it when the actor asks for it, within whichever option is in use. Skip this step when the questions are about items rather than differences.

Marking items while reading

Applies when

The actor reads, scans, and sorts the collection. Each pass produces judgements, and they are lost when the session ends unless the actor can record them. Marking has to take almost no effort, because a mark the actor postpones is usually never made.

  1. Let the actor mark items where they are looking

    Both kinds of mark, in either order, follow the same rules: made in one action where the actor is looking, private by default, and drawn from a flat vocabulary that grows with use. Do not ask for structure up front.

    In any order:

    • Annotate in place — Annotation

      Let the actor highlight and add notes to content they cannot edit. Keep the marks from obscuring the content as they accumulate.

    • Label recurring themes — Tag

      Let the actor apply reusable labels, several per item if needed, and accept near-synonyms while the vocabulary settles. Each label becomes a facet to filter by.

  2. Offer structure once the marks show it — Incremental formalisation

    When marks have accumulated, offer to add structure: merge near-synonyms, confirm the vocabulary, turn a recurring label into a field, or turn list-like prose into a list. Offer these changes rather than applying them automatically, and make them reversible.

  3. Share selected marks with others — Commenting · optional

    For the few marks that need a reply, rewrite the note and its anchor so that someone else can find and understand them; making private marks visible as they are is not enough. A shared mark becomes a thread others can reply to. Skip this step when the actor is the only reader.

Saving useful views

Applies when

When a view answers a question that comes up again, the actor rebuilds it by hand each time, because it was not saved. Composing views builds the view itself, and the labels provide its facets. The steps here decide what is saved, for whom, and how much of the judgement the system takes over.

  1. Save the view that answered the question — Data view, its saved-views dimension

    Save the view under a name, as a saved search, a smart folder, or a label opened as a view, for one person, for a role, or as the default. Remove saved views when they stop being used.

  2. Give each recurring purpose its own view — Purpose-keyed view

    Give each recurring purpose behind the saved views, such as a quick check, a review, or a follow-up, its own view, and keep the general view reachable from each. When the system offers a view on its own schedule, treat it as an interruption and show where its contents come from.

  3. Write the judgement down as rules — Problem-curated view · optional

    Write the recurring judgement down as detection rules, and show the result as a checklist that says why each item was flagged. Keep false flags rare, let the actor report them, and keep the unfiltered collection one step away. Skip this step when the domain cannot define its problems in advance.

Leaves: Recurring questions have saved answers, which need maintenance: stale views removed, rules corrected, and the general view kept one step away. The marks and saved views are now part of the collection, and the next actor starts from them.

Connections