E3.17.1in-list search not scrolldesign

When options overflow, offer a search field rather than relying on scrolling

Aliases: typeahead · filter box · do not scroll-hunt

What it is

Once an option roster no longer fits one scan, the list needs a search field so a known name can shrink the set to a few hits. Search, not scroll is about the inside of an already-open selector: a dropdown panel, a transfer column, a tree, a multi-select menu. Scrolling may remain as a way to browse; it must not be the only retrieval. Without a search field, even someone who knows the full name is stuck in a linear scan, and the task fails as the set grows. This leaf is “there must be a door”; matching rules and empty results come after.

Why it happens

Visual search on a long roster worsens with row count, and place memory is destroyed by the scrollbar. If the target name is already in hand, the best strategy is a query, not a sweep. A search field upgrades the keyboard from first-letter jump to substring or token match: first-letter jump only serves people who remember the start, and it sticks on a long run of the same initial. Relying on the browser’s in-page find is unreliable — a native select swallows keys, and a custom list is often out of document flow.

Search should also be usable as soon as the panel opens, with focus allowed on the field, not only after scrolling to the top to discover it. An entry hidden in a disclosure is still “rely on scroll.”

Where it stops holding

A search field on a short list is noise; three shippings need not be searched. Trees and cascades that offer “search the leaf” may still need scrolling to understand structure; search does not ban scrolling, it bans “only scrolling.” On touch, a keyboard can lift the search field out of view so a submit tap hits empty space; pin the field above the keyboard. A read-only long roster (a table of clauses) can also be searched, but that is page find, not in-selector filtering — do not make it a filter that mutates the selected set.

Applying it

  • Pin a search field at the top of any option panel taller than one screen; typing should work as soon as it opens.
  • Keep scrolling for browsing, and give “I know the name” explicitly to search.
  • Do not park retrieval on browser find or first-letter jump.
  • How to check: give a known full name that sits late in the roster. If finishing without the search field requires a long scroll, the door is missing.

Related

  • Within the group: E3.17.2 Filtering should match pinyin, abbreviations, and other fuzzy forms · E3.17.3 Empty filter results need an explicit message, not a blank · E3.17.4 Selected items must stay visible or trackable after filtering
  • Adjacent: E3.10 Matching Option Count to Control · E3.05 Select Menus · E3.14 Transfer Lists and Dual-Column Selection
  • Search terms: in-list search · typeahead · filter options

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/E3.17.1