Back to compare picker

Advanced search vs Basic search vs Filter panel vs Search scope selector

Prefer advanced search when the user needs multiple clauses such as field, operator, value, Boolean joiner, exact phrase, date range, exclusion, proximity, saved syntax, or search-history combination.

Decision dimensions

Dimension Advanced searchBasic searchFilter panelSearch scope selector
UI or UX UI + UX - Structured query builder for fielded, Boolean, grouped, or syntax-backed searchesUI + UX - Search input and result listUI + UX - Grouped filter control panel for narrowing a current result setUI + UX - Control that selects which corpus, location, or result source a query searches
UI guidance Render advanced search as a labelled query-construction surface with visible field, operator, value, and Boolean join controls, plus a readable query preview that shows what will run.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 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 advanced search when users need precise retrieval across multiple fields, date ranges, exact phrases, exclusions, functions, prior searches, or grouped Boolean conditions.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.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 research database builder lets users choose Title/Abstract, enter a term, add it with AND or OR, preview the generated query, and see a count before leaving the page.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.A knowledge search field includes scope buttons for All knowledge, Current workspace, Cases, and People with the active scope repeated above results.
Bad UI A button named Advanced search opens the same one-line keyword input with a larger border.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.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 adds Author contains Patel OR Journal equals Pediatrics, previews 28 matches, and saves the finished query after confirming the generated syntax.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.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 A user changes AND to OR but the UI does not show grouping, causing a much broader query than intended.Search silently changes unrelated filters.Applying a filter silently resets the query, sort order, current page, and view density.Switching from This repository to All GitHub clears the query and leaves users unsure whether anything ran.
Best fit Expert or repeat users need precise retrieval across fields, operators, phrases, dates, ranges, exclusions, functions, or prior search history.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.The same query can search different repositories, sites, workspaces, spaces, channels, result types, teams, or organization-wide indexes.
Avoid when Most users only need one keyword box and a ranked result list.The task is choosing a command with side effects.The result set is small enough that scanning is faster than filtering.There is only one searchable corpus and scope selection would be decorative.
Required state Empty builder state with field, operator, value, and Boolean controls labelled.Empty query state.Default state with no user-applied filters and an explicit result count.Default scope state based on current location or product-wide policy.
Accessibility burden Label each field, operator, value input, Boolean joiner, grouping control, generated query, and validation message with stable accessible names.The input has a stable accessible name.Use semantic form controls with fieldsets, legends, labels, and accessible names for filter categories and values.Use a labelled fieldset, radio group, select, or tablist only when the semantics match the scope interaction.
Common misuse Calling a simple filter drawer advanced search without supporting clauses, Boolean logic, or query preview.Using placeholder text as the only label.Hiding active filters inside a closed panel with no count, chips, or result-state summary.Putting scope only in placeholder text, which disappears when users type.

Advanced search

UI or UX
UI + UX - Structured query builder for fielded, Boolean, grouped, or syntax-backed searches
UI guidance
Render advanced search as a labelled query-construction surface with visible field, operator, value, and Boolean join controls, plus a readable query preview that shows what will run.
UX guidance
Use advanced search when users need precise retrieval across multiple fields, date ranges, exact phrases, exclusions, functions, prior searches, or grouped Boolean conditions.
Good UI
A research database builder lets users choose Title/Abstract, enter a term, add it with AND or OR, preview the generated query, and see a count before leaving the page.
Bad UI
A button named Advanced search opens the same one-line keyword input with a larger border.
Good UX
A user adds Author contains Patel OR Journal equals Pediatrics, previews 28 matches, and saves the finished query after confirming the generated syntax.
Bad UX
A user changes AND to OR but the UI does not show grouping, causing a much broader query than intended.
Best fit
Expert or repeat users need precise retrieval across fields, operators, phrases, dates, ranges, exclusions, functions, or prior search history.
Avoid when
Most users only need one keyword box and a ranked result list.
Required state
Empty builder state with field, operator, value, and Boolean controls labelled.
Accessibility burden
Label each field, operator, value input, Boolean joiner, grouping control, generated query, and validation message with stable accessible names.
Common misuse
Calling a simple filter drawer advanced search without supporting clauses, Boolean logic, or query preview.

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.

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.
Decision rules
  • Prefer advanced search when the user needs multiple clauses such as field, operator, value, Boolean joiner, exact phrase, date range, exclusion, proximity, saved syntax, or search-history combination.
  • Prefer basic search when one plain-language query and a result list are enough, and exposing field names, operators, or query syntax would slow most users down.
  • Prefer filter panel when users are already looking at a result set and need to include or exclude records through visible controls without learning a query grammar.
  • Prefer search scope selector when the same query needs to run against a different corpus, repository, site, channel, people index, or organization index before filters or clauses are interpreted.
  • Advanced search should show a readable query preview or generated syntax so expert users can inspect exactly what will run before they submit it.
  • If the builder emits syntax, validate missing values, unmatched quotes, unsupported operators, incompatible fields, and ambiguous grouping before running the query.
  • When users add, remove, or reorder clauses, preserve the raw query, selected fields, result count preview, and search history separately from filters, sort, and scope.
  • Do not collapse advanced search into a generic filter drawer; clauses can create nested logic, combine prior searches, and change query semantics in ways a normal filter panel cannot.
  • Do not use advanced search for simple browse categories or tabs; those should remain scannable navigation choices rather than requiring syntax.
  • Offer a return path from advanced search to basic search when users only need a plain keyword query, but do not silently discard expert clauses.
Inspect live examples
Failure modes
  • A product labels a filter panel as Advanced search even though every control is a simple post-result filter.
  • The query builder runs malformed syntax and returns zero results instead of explaining the broken clause.
  • Users add OR clauses but the UI hides grouping, so the system runs a broader query than intended.
  • Switching back to basic search silently deletes the fielded query and search history.
  • Advanced query examples use internal field names that do not match visible result fields.
  • The builder lets users select a field and operator combination that the search backend cannot execute.