Put the identifying information on the first line and do not truncate it
Aliases: primary text · list truncation · identifying field
What it is
When people scan a list, the eye’s landing on each row is almost always the first line of type. That line has to identify the object on its own — a name, a subject, a filename, the other party in a thread. First-line identifier integrity means that field appears whole, not eaten by an ellipsis. Timestamps, tags, and previews may wrap, fade, or drop to a second line. If the identifier is cut, neighbouring rows become indistinguishable stubs and the scan stalls.
Why it happens
List scanning is a loop of land, match, leave. Landing is set by the row’s origin and the aligned left edge; matching compares that short high-contrast string with the target in memory. Truncation breaks matching, not landing. “Q3 budget rev…” does not tell you whether the item is a review or a revised approval flow, so the reader opens it, reads the full title, and comes back — scanning becomes sampling. Collections that share a prefix (files with the same stem, threads from the same sender) suffer most, because the discriminating material was in the tail, which is exactly what the ellipsis cuts. A second line of metadata does not help; this pass never reads down. Languages without spaces are harsher still: a cut inside a word can leave a fragment that is not even a legal token.
Studying it
Take titles that differ only in the tail or the middle. Show them as a full first line, tail-truncated, or middle-truncated, and ask people to find a named item while scrolling. Independent variables: truncation locus, prefix overlap, character budget on line one. Dependent variables: time to target, opens of the wrong row, spoken “can’t tell which one.” Eye tracking should show extra regressions under truncation, as a failed first-line match sends the gaze to line two or a neighbour. A neatness rating is not a proxy: a tidy line can still be unidentifiable.
Where it stops holding
When the identifier is already short (a two-letter country code, a three-letter airport code) truncation barely arises. Monospaced codes, hashes, and identity numbers discriminate at both ends; keeping only the head still collides, so show them whole in a tabular face or ellipsize the middle and keep the tail. On a search-results list the query may hit the middle of a title, and preserving the hit fragment outranks preserving the start. German and Finnish compounds eat a first-line budget fast; sign off per language, not on a Chinese or English sample.
Applying it
- Name the identifying field of each row and reserve width so it is not truncated; only supporting fields may ellipsize or move to line two.
- For prefix-heavy collections, ellipsize the middle and keep the tail, or add a short discriminator on line one (a number, a time, a status). Do not just lengthen the ellipsis.
- When dynamic type grows, let the identifier wrap in full rather than stay on one clipped line.
- How to check: pair every identifier’s full string with what is actually visible. If the visible string cannot uniquely pick the object out of the set, that row fails.
Related
- Within the group: E4.02.1 Row height trades viewport comparison against how hard a row is to hit · E4.02.3 Priority between row actions and a whole-row click must be explicit
- Adjacent: E4.03 Tables · E4.17 List grouping and sticky headers · E2.08 Character limits
- Search terms:
list scanning·text truncation·primary identifier