Back to compare picker

Search scope selector vs Basic search vs Filter panel vs Tabs

Prefer search scope selector when the same query can run against materially different corpora such as this repository, all repositories, current site, hub, organization, current channel, all messages, files, or people.

Decision dimensions

Dimension Search scope selectorBasic searchFilter panelTabs
UI or UX UI + UX - Control that selects which corpus, location, or result source a query searchesUI + UX - Search input and result listUI + UX - Grouped filter control panel for narrowing a current result setUI + UX - Section-switching component
UI guidance Render the active search scope near the search input and result summary, using user-facing corpus names such as Current workspace, All knowledge, This repository, or People.Render a labeled search field, result count, matching rows, and clear action.Render filter categories as labelled form controls in a panel adjacent to the result set on wide layouts, with a visible result count and active-filter summary near the results.Render a tablist with short tab labels, selected tab styling, visible keyboard focus, and a single associated tabpanel that is visually connected to the active tab.
UX guidance Use a search scope selector when the same query can search meaningfully different content sources and users need to control where the system looks.Help users find known content without browsing every category.Use a filter panel to help users narrow the current list or search result set while preserving orientation, search query, sort order, pagination context, and selected values.Help users switch between sibling sections in the same page context without changing routes or losing local work.
Good UI A knowledge search field includes scope buttons for All knowledge, Current workspace, Cases, and People with the active scope repeated above results.A clearly labeled search field with result count and results placed directly below.A desktop search page shows a left filter panel with Status, Type, and Date groups, while active chips and the result count sit above the results.Tab labels are short, active tab is obvious, focused tab is distinguishable, and panel content is visually attached to the selected tab.
Bad UI The placeholder says Search this site, but after typing only a generic magnifying glass remains and the result page no longer names the scope.Search input hidden behind only an icon with no label.A filter drawer closes with no active count, leaving users unaware that filters are still hiding records.Tabs wrap unpredictably or look like unrelated buttons.
Good UX A user searches appeal in Current workspace, switches to All knowledge, and sees the same query rerun with a larger result count and broader source summary.Users can type, revise, clear, and keep context while inspecting results.A user selects Status: Open and Type: Appeal, applies the batch, lands back at the result summary, and sees 12 records with both criteria removable.Users switch between sibling sections without leaving page context or losing panel-local notes.
Bad UX Switching from This repository to All GitHub clears the query and leaves users unsure whether anything ran.Search silently changes unrelated filters.Applying a filter silently resets the query, sort order, current page, and view density.Using tabs as primary navigation to unrelated pages.
Best fit The same query can search different repositories, sites, workspaces, spaces, channels, result types, teams, or organization-wide indexes.Users know a word, name, or identifier.Users need to narrow the current search results, browse results, table, card grid, or list by multiple criteria.Users switch between sibling panels frequently.
Avoid when There is only one searchable corpus and scope selection would be decorative.The task is choosing a command with side effects.The result set is small enough that scanning is faster than filtering.The destinations are unrelated pages.
Required state Default scope state based on current location or product-wide policy.Empty query state.Default state with no user-applied filters and an explicit result count.Default active tab and visible panel.
Accessibility burden Use a labelled fieldset, radio group, select, or tablist only when the semantics match the scope interaction.The input has a stable accessible name.Use semantic form controls with fieldsets, legends, labels, and accessible names for filter categories and values.Expose the active tab and associated panel.
Common misuse Putting scope only in placeholder text, which disappears when users type.Using placeholder text as the only label.Hiding active filters inside a closed panel with no count, chips, or result-state summary.Using tabs as a primary site navigation system.

Search scope selector

UI or UX
UI + UX - Control that selects which corpus, location, or result source a query searches
UI guidance
Render the active search scope near the search input and result summary, using user-facing corpus names such as Current workspace, All knowledge, This repository, or People.
UX guidance
Use a search scope selector when the same query can search meaningfully different content sources and users need to control where the system looks.
Good UI
A knowledge search field includes scope buttons for All knowledge, Current workspace, Cases, and People with the active scope repeated above results.
Bad UI
The placeholder says Search this site, but after typing only a generic magnifying glass remains and the result page no longer names the scope.
Good UX
A user searches appeal in Current workspace, switches to All knowledge, and sees the same query rerun with a larger result count and broader source summary.
Bad UX
Switching from This repository to All GitHub clears the query and leaves users unsure whether anything ran.
Best fit
The same query can search different repositories, sites, workspaces, spaces, channels, result types, teams, or organization-wide indexes.
Avoid when
There is only one searchable corpus and scope selection would be decorative.
Required state
Default scope state based on current location or product-wide policy.
Accessibility burden
Use a labelled fieldset, radio group, select, or tablist only when the semantics match the scope interaction.
Common misuse
Putting scope only in placeholder text, which disappears when users type.

Basic search

UI or UX
UI + UX - Search input and result list
UI guidance
Render a labeled search field, result count, matching rows, and clear action.
UX guidance
Help users find known content without browsing every category.
Good UI
A clearly labeled search field with result count and results placed directly below.
Bad UI
Search input hidden behind only an icon with no label.
Good UX
Users can type, revise, clear, and keep context while inspecting results.
Bad UX
Search silently changes unrelated filters.
Best fit
Users know a word, name, or identifier.
Avoid when
The task is choosing a command with side effects.
Required state
Empty query state.
Accessibility burden
The input has a stable accessible name.
Common misuse
Using placeholder text as the only label.

Filter panel

UI or UX
UI + UX - Grouped filter control panel for narrowing a current result set
UI guidance
Render filter categories as labelled form controls in a panel adjacent to the result set on wide layouts, with a visible result count and active-filter summary near the results.
UX guidance
Use a filter panel to help users narrow the current list or search result set while preserving orientation, search query, sort order, pagination context, and selected values.
Good UI
A desktop search page shows a left filter panel with Status, Type, and Date groups, while active chips and the result count sit above the results.
Bad UI
A filter drawer closes with no active count, leaving users unaware that filters are still hiding records.
Good UX
A user selects Status: Open and Type: Appeal, applies the batch, lands back at the result summary, and sees 12 records with both criteria removable.
Bad UX
Applying a filter silently resets the query, sort order, current page, and view density.
Best fit
Users need to narrow the current search results, browse results, table, card grid, or list by multiple criteria.
Avoid when
The result set is small enough that scanning is faster than filtering.
Required state
Default state with no user-applied filters and an explicit result count.
Accessibility burden
Use semantic form controls with fieldsets, legends, labels, and accessible names for filter categories and values.
Common misuse
Hiding active filters inside a closed panel with no count, chips, or result-state summary.

Tabs

UI or UX
UI + UX - Section-switching component
UI guidance
Render a tablist with short tab labels, selected tab styling, visible keyboard focus, and a single associated tabpanel that is visually connected to the active tab.
UX guidance
Help users switch between sibling sections in the same page context without changing routes or losing local work.
Good UI
Tab labels are short, active tab is obvious, focused tab is distinguishable, and panel content is visually attached to the selected tab.
Bad UI
Tabs wrap unpredictably or look like unrelated buttons.
Good UX
Users switch between sibling sections without leaving page context or losing panel-local notes.
Bad UX
Using tabs as primary navigation to unrelated pages.
Best fit
Users switch between sibling panels frequently.
Avoid when
The destinations are unrelated pages.
Required state
Default active tab and visible panel.
Accessibility burden
Expose the active tab and associated panel.
Common misuse
Using tabs as a primary site navigation system.
Decision rules
  • Prefer search scope selector when the same query can run against materially different corpora such as this repository, all repositories, current site, hub, organization, current channel, all messages, files, or people.
  • Prefer basic search when users only need to enter, submit, revise, clear, and see results for one already-understood corpus.
  • Prefer filter panel when users are narrowing a result set after the corpus is already chosen, using attributes such as date, type, author, status, label, or space.
  • Prefer tabs when users are switching between sibling result views or content panels and the tab label is not changing the search index before the query runs.
  • A scope selector should be visible before submission or repeated in the result summary so users know where the search ran.
  • When a scope change preserves the query, update the result count and scope summary together; when it clears the query, warn before clearing because users may interpret the same words differently in another corpus.
  • Use names that describe the corpus, not implementation labels such as tenant, index-4, default source, or vertical unless those words are the user's vocabulary.
  • If permissions differ by scope, show available scopes only when the user can search them and explain why broader scopes may be unavailable.
  • Do not hide scope inside placeholder text because the placeholder disappears as soon as users type.
  • Keep scope selection separate from sort order and result highlighting because scope changes where the system searches, sort changes ordering, and highlighting explains why existing results matched.
Inspect live examples
Failure modes
  • The search runs only within the current site or repository, but the UI looks like it searched the whole product.
  • Changing from Current space to All spaces erases the query without warning.
  • A tab labelled Files is used as both a result-type view and a pre-query corpus selector, so users cannot tell what will be searched next.
  • Internal index names appear in the menu and users choose the wrong scope.
  • Guest users see organization-wide scope options that cannot return results for them.
  • The result count changes after a scope switch but the heading still names the previous scope.