Advanced search

Problem Context

• The search backend supports fielded queries, operators, Boolean logic, exact phrases, date ranges, functions, history references, qualifiers, regular expressions, or other expert syntax.
• Users need precision, repeatability, auditing, or shareability that cannot be achieved with one keyword box and a few post-result filters.
• Small syntax mistakes can return no results, too many results, or confidentially broad results, so the interface must help users inspect and repair the query.

Selection Rules

• Choose advanced search when users must combine multiple search clauses before execution, such as field plus operator plus value joined by AND, OR, or NOT.
• Use a builder when users know the concepts but not the exact query syntax; use raw syntax when expert users need full control that a form cannot represent.
• Show generated syntax or a readable query preview for every builder state so users can verify field names, grouping, phrase matching, exclusions, and date ranges.
• Validate field/operator compatibility before running the query, especially for dates, numeric ranges, controlled values, functions, and exact-phrase syntax.
• Offer result-count preview or add-to-history actions when users need to compare query alternatives before opening a full result page.
• Keep search scope, filters, sort order, and saved query identity separate from advanced clauses so changing one does not silently mutate the others.
• Use filter panel instead when all criteria are visible controls that narrow an already returned result set without Boolean grouping or query syntax.
• Use saved search when the primary task is naming, sharing, rerunning, or alerting on a query that already exists.
• Use query correction when the main failure is a misspelled term, not a malformed fielded query.
• Use browse by category when users are exploring a known taxonomy rather than constructing a precise retrieval expression.

Required States

• Empty builder state with field, operator, value, and Boolean controls labelled.
• Partially built query state with a generated preview and clear next action.
• Valid query state with result-count preview or ready-to-search status.
• Invalid syntax state for unmatched quotes, unsupported operators, missing values, or broken grouping.
• Unsupported field/operator state with suggested alternatives.
• Builder-to-raw-syntax state that preserves representable clauses and warns about clauses the builder cannot represent.
• Search history state where previous queries can be combined or copied.
• No-results state that keeps the full query visible and offers clause-level repair.
• Deep-linked or saved state that restores clauses, raw syntax, scope, filters, and sort separately.

Interaction Contract

• Adding a clause appends a visible field, operator, value, and joiner to the canonical query state.
• Removing a clause updates the generated query, result-count preview, and validation state without clearing unrelated clauses.
• Changing Boolean joiners or grouping updates the preview immediately so users can see whether the query became broader or narrower.
• The product must not execute malformed syntax as a silent zero-result query when it can detect a missing value, unmatched quote, invalid field, or unsupported operator.
• Switching between builder and raw syntax preserves all query meaning that both modes can represent and explicitly warns before dropping anything.
• Submitting an advanced query includes its clauses in the URL, history entry, saved search, export, or audit trail when those features exist.
• Result-count preview belongs to the same query, scope, and filters currently shown; stale previews must be marked pending or cleared.

Implementation Checklist

• Define the searchable fields, user-facing labels, allowed operators, value types, autocomplete sources, and backend syntax for each clause type.
• Model the query as structured data first, then serialize to backend syntax so the UI can validate, preview, restore, and edit clauses reliably.
• Provide explicit controls for AND, OR, NOT, grouping, exact phrase, date range, field selection, and value entry only where the backend supports them.
• Show generated syntax or a plain-language query summary before submission.
• Validate missing values, unsupported field/operator pairs, unmatched quotes, malformed dates, unsafe wildcards, and grouping errors before running.
• Add a result-count preview or add-to-history option when users compare query variants.
• Preserve raw query text when parsing fails so users can repair rather than retype.
• Keep advanced search state shareable through URL parameters, saved searches, or history when users need to resume or collaborate.
• Test expert syntax, builder mode, invalid syntax, history combination, mobile layout, keyboard order, screen reader labels, and no-results repair.

Common Generated-UI Mistakes

• Calling a simple filter drawer advanced search without supporting clauses, Boolean logic, or query preview.
• Hiding generated syntax so users cannot inspect exactly what the builder will submit.
• Returning zero results for parse errors instead of showing the broken clause.
• Mixing search scope, filters, sort, and advanced clauses into one opaque text string with no recoverable controls.
• Using backend-only field names in the UI without user-facing labels.
• Discarding raw syntax when switching to a builder that cannot represent the query.

Critique Questions

• What makes this search advanced: fields, operators, Boolean logic, grouping, history, syntax, or result-count preview?
• Can users inspect the exact query before it runs?
• How does the UI distinguish malformed syntax from a valid query that has no results?
• Which field/operator combinations are allowed, and where are invalid combinations blocked or repaired?
• What happens when users switch between basic, builder, and raw syntax modes?
• Are scope, filters, sort, saved-search name, and advanced clauses stored separately enough to avoid stale counts or lost criteria?