Scan cost stays high when the set is huge

What it is

Two columns do not shorten a large set. A thousand rows on each side still make people hunt names in two long rosters — almost twice the scan of one list, plus the move. A transfer list separates chosen from unchosen; it does not make the universe small. Past that line, without search, grouping, virtualization, and honest empty states, the shuttle is only a long select’s pain laid out in two panes. This is a capacity bound: the semantics still hold, the efficiency has already collapsed.

Why it happens

Visual search time grows with visible rows. Two columns on screen add a saccade between panes, an extra spatial conversion. Each scrollbar is its own, so place memory is two sets; a name just seen on the left scrolls away, and the right cannot help. Without search, a known-name task decays into two linear scans; without grouping, a known-kind task has no category cue in either column. Rendering thousands of rows also drops frames, so scanning is interrupted by performance noise and people quit earlier.

“See the selection whole” likewise fails once the right column exceeds one screen: the whole becomes “somewhere in the scroll.” The shuttle keeps the handover metaphor and drops the whole-set promise, so search and a count have to make the whole queryable.

Where it stops holding

A huge source and a tiny subset is the usual asymmetry: the right can still be taken in, the left must be searchable. Do not treat a comfortable right column as evidence the widget scales. Virtualization keeps frames, but in-page find, scrollbar mapping, and blank rows on fast flicks need extra work. A transfer list is not the only large-set tool: a grouped shuttle, a searchable shuttle, or “search to add + a chosen list” often beats two naked rosters. A permission matrix or a table of ticks scans better on two-dimensional attributes than a squeeze into dual columns.

Applying it

• Give columns that may pass a hundred rows search and grouping, and pin the chosen count on the header.
• When the source is large and the target small, strengthen retrieval on the left and keep a complete roster on the right.
• Virtualize when row count stutters, and keep search; do not rely on scrolling alone.
• How to check: on a realistic roster, add three known names and verify the right has no misses. If it cannot be done without search, or people quit mid-scroll, scan cost has already outweighed the dual-column benefit.

Related

• Within the group: E3.14.1 A transfer list is for picking from a large set and seeing the selection whole · E3.14.2 Both lists need their own search and bulk actions · E3.14.3 Whether order is kept after a move must be defined
• Adjacent: E3.17 In-List Search and Filtering · E4.18 Virtualized Long Lists
• Search terms: scan cost · large transfer list · virtualized listbox