F4.10.2middle ellipsisdesignresearch

Middle ellipsis keeps the distinctive start and end

Aliases: center truncation · path ellipsis · byTruncatingMiddle

What it is

Some identifiers earn their keep at the two ends: paths, email addresses, URLs, long ids. People match them by those anchors — /Users/…/thesis.pdf still reads as a dissertation file, alice@…edu still reads as a campus account. Middle ellipsis is the algorithm that cuts the interior and keeps both flanks. It is not a prettier truncation. It is a bet that uniqueness lives at the ends.

Why it happens

Visual matching of a long identifier grabs two anchors in working memory rather than scanning the whole string. Scheme and host, folder and filename, local-part and domain, naturally park information at the flanks; the middle is often interchangeable directory layers or a hash. Middle ellipsis preserves the anchors, which is why it tracks human matching better than tail-cutting in file trees, breadcrumbs, and account lists. The cost arrives immediately: two files that differ only in a middle segment (…/draft/… versus …/final/…) collapse to the same stub. Native CSS historically had no middle ellipsis; platform controls did (truncating-middle line-break modes). Plenty of “paths” on the web still lose the tail because the engine cannot do otherwise — an implementation gap, not a design choice.

Studying it

Build confusable pairs: one pair differs only in a middle directory, one only in extension or leaf name, one only in host. Cross those with head, tail, and middle cuts. The error pattern under a forced narrow width is the result that matters — middle ellipsis clusters misses on middle-difference pairs and wins on suffix-difference pairs. Log how many glyphs remain on each flank; once each side drops below about four or five visible characters, the anchors stop being anchors.

Where it stops holding

Running prose, product titles, and warnings have no “end features”; a middle cut leaves two ungrammatical scraps. At widths that leave two or three characters per side, the features are gone. Project trees that stash dates or version numbers in a middle folder lose the unique layer systematically under middle ellipsis. For that data, drop directory levels (omit inner folder names, always show the filename) rather than slicing characters at the midpoint.

Applying it

  • Turn middle ellipsis on for paths, emails, URLs, and overlong ids; do not put it on titles or body copy.
  • Prefer hierarchical omission over a character-level bisect: keep the volume or root and the leaf filename visible.
  • Collect real names that share prefix and suffix and differ only in the middle. Drop them into the target width. If two records paint as one string, that class should not use middle ellipsis.

Related

  • Same group: F4.10.1 Where a string is cut decides whether the leftover is still usable · F4.10.3 Truncated copy still needs a path to the full string · F4.10.4 Decision-critical text such as prices and warnings must not be truncated · F4.10.5 Assistive technology must still receive the untruncated string · F4.10.6 CJK characters pack more meaning per glyph, so the same character budget loses more · F4.10.7 Multiline clamp must recast with type size, not a fixed pixel height
  • Nearby: F2.16 Extreme content and overflow · F4.07 Typeface choice
  • Search terms: middle ellipsis · center truncation · path ellipsis

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/F4.10.2