Too many, too fine groups raise scanning cost instead of lowering it

What it is

Grouping is supposed to cut the number of chunks a scan faces at once. When the number of groups nears the number of items, each group holds one or two rows, or several header levels stack on one list, the headers become objects to scan. Over-fine grouping encrypts structure until it is as dense as content; people have to cross a forest of titles before they see items. Cost goes up, not down.

Why it happens

Structure helps because it is sparser than content. One header over a dozen or two dozen rows lets the eye jump by title. One header per row makes header density equal row density; jumps have no coarser grain, and an extra visual style must be parsed. Nested grouping (year, then month, then day, then thread) fills every screen with titles, items are pushed out of the viewport, and the comparison window shrinks. Over-fineness also comes from cutting a continuous dimension into too many buckets (a timeline grouped per hour): bucket names stop being lookup keys, because nobody remembers whether the target sat in “14:00–15:00” or the next bucket. Gain against group size is an inverted U: too coarse and the class cannot be found; too fine and a class is no longer a class.

Studying it

Take one collection as coarse groups, fine groups, and nested groups, on locate and compare tasks. Independent variables: mean items per group, header depth. Dependent variables: time, headers mistaken for items, share of the viewport taken by headers during scroll. Fine grouping may be slightly faster at “find this class,” and should be clearly slower at “compare items across two classes,” because the viewport is all headers.

Where it stops holding

An address book grouped by letter looks like many groups, but each group still holds many items and the letter is a stable lookup key — not over-fine. Empty groups (a header with no items) are another noise; hide them rather than filling with still finer groups. User-defined tags can be many and fine by nature; collapse infrequent tags rather than paving them as first-level headers.

Applying it

• Treat “a group large enough to form a comparison window on one screen” as a floor; merge when groups are far finer than that.
• Keep one grouping level that helps lookup; deeper levels belong in item fields, not extra header rows.
• Hide empty groups. Bucket continuous time more coarsely (today / this week), not by the hour.
• How to check: count header rows versus item rows on one screen. If headers often outnumber items, grouping is too fine.

Related

• Within the group: E4.17.1 Section headers make the inner structure of a long list readable · E4.17.2 A sticky header names the group you are in while you scroll · E4.17.4 A sticky element must not be mistaken for a tappable row
• Adjacent: E4.21 Timelines and stream structures · E5.15 Number of navigation items
• Search terms: overgrouping · section density · information scent