R2.05.2cardinality layout framesdesign

Zero, one, and many each need their own defined layout

Aliases: zero-one-many handoff · cardinality frames · count-dependent layout

What it is

For slots that hold lists, attachments, tags, or people, count changes structure, not density. Cardinality layout frames are three geometries in the package: zero items, exactly one, and many. At zero, does the container itself remain. At one, do you still use repeating row chrome and dividers. At many, where does folding or paging start. Painting the three as opacity variants of one list is the same as not shipping them.

Zero here is the layout when the collection’s count is nil — rows, headers, footer actions on or off. It does not write the speech that tells someone to create the first object. That speech is a different deliverable.

Why it happens

Implementation is a tree of nodes. Zero often deletes the repeating body and takes the header, bulk actions, and count footer with it; the page turns from “a set of rows” into “a shell.” One item still wearing a list’s zebra, spacing, and overflow menu looks as if neighbors were supposed to arrive. Cramming a singleton into the many-template makes people hunt for unrendered rows. Many is the first time overflow, pagination, and sticky column headers earn their keep.

The three cardinalities cannot be scaled from a middle frame. The usual three-to-five-item mock teaches everyone “this is a list,” so zero is filled with a blank card, one is treated as a short list, and the fold point is argued only at integration. Place the three frames side by side and count == 0, count == 1, and count >= 2 can be three layouts that do not borrow from each other, instead of one list with conditional hiding.

Where it stops holding

Objects that can exist only once in the product — a profile header, the current session — have no “many” to draw; one is the normal case, and three frames are a fake cardinality. Continuous quantities (progress from 0 to 1, stock as a number rather than rows) are scales, not item counts. Infinite scroll turns “many” into a window: specify the minimum visible rows and the “load more” row, do not pretend to draw the entire set. A filter that collapses ten rows to zero is still a cardinality of results, but the header and filters usually stay — do not reuse the “this collection has never existed” shell for that zero.

Applying it

  • Ship three frames per collection slot, labeled n = 0, n = 1, and n = k where k is the count at which scrolling or folding starts.
  • On the zero frame, mark which chrome survives: title, filters, primary action. Do not leave an unlabeled white rectangle.
  • On the one frame, drop decorations that exist only to serve repetition (a divider reserved for the next row, a bulk-select column) so a singleton reads as a singleton.
  • Feed the same endpoint an empty array, a one-element array, and an array past the fold threshold. Overlay the three screens on the three frames. If zero still shows leftover row height, or one still says “N items” in the plural, cardinality has not been split.

Related

  • Same group: R2.05.1 Handoff must show both extreme-long and extreme-short content · R2.05.3 Whatever is left unspecified will be invented by the implementer · R2.05.4 Bound values come from real distributions, not imagined extremes · R2.05.5 Overflow behavior must be specified separately by content type · R2.05.6 Stacked edge cases need their own frames
  • Adjacent: R1.03 Completeness of component states · R2.09 Empty and Exception States in Handoff
  • Search terms: cardinality layout frames · zero one many · collection cardinality

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/R2.05.2