Typeahead

Problem Context

• The product has a large searchable result set where users can identify useful hits from partial input.
• The search backend or index can support low-latency prefix or as-you-type matching.
• The interface must balance immediate feedback with network cost, privacy, mobile typing, and keyboard control.

Selection Rules

• Choose typeahead when live result hits should appear as the user types and the result set can update safely before explicit submit.
• Set a minimum query length before searching when short prefixes produce noisy, expensive, or privacy-sensitive results.
• Debounce or pace remote requests and ignore stale responses so older results cannot overwrite newer query state.
• Show a loading, searching, or stalled state when live results are not yet ready.
• Keep typed text under user control; selecting a hit should not be confused with auto-filling the input.
• Let users open a typeahead result directly or submit the typed query for a full result page.
• Use autocomplete when the field must resolve to a known value; use search suggestions when rows are suggested query phrases; use basic search when results should wait for explicit submit.
• Show result type, source, count, and enough secondary metadata to distinguish similar hits.
• Handle no live results, offline or failed lookup, cleared input, input blur, Escape dismissal, and mobile viewport constraints.
• Avoid typeahead for sensitive searches, high-latency backends, costly queries, or domains where every keystroke should not leave the device.

Required States

• Empty state before typing.
• Below-minimum-length state explaining when live lookup begins.
• Loading or stalled state tied to the current query.
• Populated live-result state with result count, source labels, and active result.
• Selected result state where opening a hit is distinct from submitting the query.
• No live results state for the current typed query.
• Stale-response ignored state when older results arrive after a newer query.
• Submitted full-search state after the user explicitly searches the current query.

Interaction Contract

• Typing changes the query and schedules live lookup only when the minimum length and privacy rules allow it.
• Each response must be associated with the query that requested it and ignored if the user has typed a newer query.
• The active result can move with arrow keys without replacing the input value.
• Enter opens the active result only when result focus or active option semantics make that explicit; otherwise it submits the query.
• Escape closes the typeahead panel without clearing the typed query.
• Clicking or pressing a result opens that result or previews it, while final search submit runs the typed query.
• Clearing input cancels pending live lookup and resets result, loading, and active-result state.

Implementation Checklist

• Define whether rows are result hits, entities, commands, or query suggestions and label the source accordingly.
• Configure minimum length, debounce interval, maximum visible results, request timeout, and stale-response guard.
• Implement loading, stalled, no-results, error, offline, and cleared states for live lookup.
• Preserve typed query separately from selected result ID and full-search submitted query.
• Expose combobox or listbox semantics when the panel behaves like selectable options, including active descendant or equivalent focus management.
• Provide keyboard behavior for arrow movement, Enter, Escape, Tab, and pointer selection.
• Test rapid typing, deleting text, IME composition, mobile keyboards, screen readers, slow responses, failed responses, privacy-sensitive queries, and result opening.
• Measure request volume, stale response suppression, selected result rate, full-search rate, no-result rate, and abandoned typeahead panels.

Common Generated-UI Mistakes

• Calling a known-value autocomplete field typeahead even though no result set is searched.
• Calling suggested query phrases typeahead when no live result hits are shown.
• Auto-filling the first result into the input while users type.
• Sending a remote request for every keystroke with no debounce or minimum length.
• Letting stale results overwrite the current query's result panel.
• Showing no loading or stalled state during slow lookup.
• Mixing ads, recent searches, query suggestions, and result hits without source labels.
• Moving keyboard focus out of the input unexpectedly.

Critique Questions

• Are rows live result hits for the current typed query, or are they query suggestions or known-value options?
• What minimum length and debounce policy prevents noisy or expensive every-keystroke search?
• How does the UI show loading, stalled, no-result, and stale-response states?
• Can users keep typing without the first result replacing their query?
• Does Enter open an active result or submit the query, and is that contract clear?
• Can users distinguish source, type, and relevance of live hits?
• What privacy, telemetry, or backend-cost constraints apply to sending partial queries?