Search scope selector

Problem Context

• The product can search across different sites, spaces, repositories, channels, conversations, teams, result types, hubs, tenants, or organization-wide indexes.
• A user's current location creates a useful default scope but may not match the user's intent.
• Broader scopes can expose more results, take longer, change ranking, or be limited by permissions.

Selection Rules

• Choose search scope selector when users need to decide where the search runs before interpreting results.
• Show the active scope before submission when the default could be confused with a broader or narrower corpus.
• Repeat the active scope in the result heading, result count, URL state, or applied criteria summary after submission.
• Preserve the typed query when users switch scope if the query syntax works in the new corpus.
• Reset pagination to the first page when scope changes, because the result set is different even when the query text is the same.
• Use permission-aware scope choices so unavailable broad scopes are disabled with explanations or omitted according to security policy.
• Use user-facing content names rather than backend index, tenant, vertical, or source IDs.
• Distinguish result-type tabs from pre-query search scope when both are present, because switching Messages to Files after search is not always the same as searching only files next time.
• Use filter panel after scope selection when users need attribute constraints within the chosen corpus.
• Use advanced search when users need boolean logic, fielded query syntax, or multiple clauses rather than a small set of named corpora.

Required States

• Default scope state based on current location or product-wide policy.
• Explicitly selected scope state before the query is submitted.
• Submitted query state with scope name and result count.
• Scope changed state where the query is preserved and results rerun.
• Unavailable or permission-limited scope state with explanation.
• No-results-in-this-scope state with path to broaden or change scope.
• Mobile compact state where the active scope remains visible near the search input.
• Deep-linked state where query and scope restore from the URL or saved view.
• Incompatible query syntax state when a qualifier or field only works in one scope.

Interaction Contract

• Selecting a scope changes the corpus searched, not merely the visual grouping of existing results.
• The search input, result count, result list, and result summary all update from the same query and scope state.
• Changing scope preserves the current query unless the user confirms clearing it or the query cannot run in the new scope.
• Changing scope resets pagination and clears stale highlights or result selections that belonged to the previous corpus.
• Scope choices remain keyboard reachable and have accessible names that include what content they search.
• Unavailable scopes explain whether the reason is permission, product plan, guest mode, indexing delay, or no content source.
• When a scope is encoded as query syntax, the visible UI still explains it in plain language.
• Deep links, saved searches, and browser history restore both query and scope.

Implementation Checklist

• Define the canonical scope IDs and map each one to a user-facing label, content source, permission rule, and result route.
• Keep query, scope, filters, sort, and result type as separate state so changing one does not silently mutate the others.
• Place the active scope in or next to the search form and repeat it in the result summary.
• Persist scope in URL parameters, route state, or saved search definitions when users need shareable or resumable results.
• Reset pagination and stale selected-result state whenever scope changes.
• Validate whether typed query qualifiers are compatible with the selected scope and offer repair copy when they are not.
• Disable, hide, or explain broad scopes that the current user cannot search.
• Test current-location defaults, broadening actions, mobile presentation, keyboard order, result counts, no-results recovery, and permission-limited users.

Common Generated-UI Mistakes

• Putting scope only in placeholder text, which disappears when users type.
• Using tabs as scope selectors without saying whether future searches will use the selected tab.
• Calling scope choices filters even though they change the corpus before attribute filtering begins.
• Changing scope while leaving the previous result count, highlights, or selected result active.
• Showing broad organization scope to users who cannot search it.
• Using internal source names or index IDs as menu labels.

Critique Questions

• Can users tell where the next search will run before they submit it?
• After results load, does the result summary name both the query and the active scope?
• What happens to query text, pagination, filters, highlights, and selected results when scope changes?
• Are current-location defaults clear enough when users may expect product-wide search?
• Are unavailable broad scopes explained without implying zero results?
• Are result-type tabs, filters, and scope choices visually and semantically distinct?