Moved from: https://github.com/govau/uikit/issues/31
We have just released a search box that composes Design System ‘button’ and ‘text input’:
Maybe it’s a start?
Will you be expanding this to an ‘advanced search’ at any stage? It is currently something our team is trying to put together, for internal web applications.
Can you work advanced search into the smarts of the search engine? This is how Google became king-- type whatever and it gives you great results.
We spent alot of time tuning our search as well to provide the best results possible for the context of Digital Guides.
Advanced search is generally made up of a combination of elements that exist in Design System, like checkboxes, link lists, etc. and the preferred implementation is likely to depend on your specific content and back-end search technologies, so it might be hard to have a generic one-size-fits-all solution.
There could potentially be an example template though, which pulls together some elements as an example of a possible solution.
There may be a few options here worth extending in the Design System:
1. Pre-query parametric search
A search input showing one or two additional scoping options (Search Within: [All | Services | Media Releases], Search Near: [Anywhere|My Location]). For infrequent users, adding more scoping options or parameters during query formulation may be more likely to result in zero-result queries, with no obvious indication as to why their search is a dead end.
(I realise Select inputs are almost always a sub-optimal approach.)
2. Mid-query search suggestion / autocomplete
Potentially combined with the scoping options above, users’ partial queries are either completed (as words or phrases) prior to submission, or full-fledged results (answers) are suggested as they type. While these widgets can be made accessible, there’s not likely to be a comparable no-JS fallback aside from ‘Did you mean’ or ‘Best Bet’ UI widgets appearing post-query.
This may be also be seen as a ‘JS-enhanced’ version of a regular text input field, but wildly dependent on the JS being used and the capabilities of any server-side endpoints.
3. Post-query refinement via faceted search
An increasingly common design pattern, generally suitable for the refinement of very large result sets, rather than a <1000 document index on a small departmental website. An initial simple search term (say, ‘payments’) may provide several hundred results which might then be refined by Date, Audience, Life Event, etc.
Options 1 and 2 might be worth considering as variations of the existing Header component (a header with a right-aligned site search form, for example).
The three options above would seem to consist of one or more components (many of which already exist in the Design System), but combining them together in predictable, consistent patterns would start to allow templates to take shape.
A Design System template (or series of templates) focused on delivering a search engine results page (SERP) would seem appropriate here, providing implementations of:
- Ordered list of results with clickable titles, highlighted terms, rich summaries, text snippets, etc.
- Pagination (or infinite pagination for JS-enabled users, if it’s likely to be useful), leveraging Direction Links and Link Lists
- Status messages (indicating whether a query has been modified, or if an alternative is being suggested, errors or other edge cases, using Page Alerts in extreme examples)
All of the above, but also including:
- Groups of refinement controls for faceted search (possibly leveraging Accordion, Side Nav, Tags)
- Groups of refinement controls for parametric search, optionally constraining values to those matching one or more result in the set (Control Inputs may help here).
The Digital Marketplace uses some of these patterns, albeit without a free-text search, in the example shown at https://marketplace.service.gov.au/2/opportunities . Directory.gov.au is another WofG example that uses a simple post-query refinement option on a medium-sized search index.
I don’t believe that there’s one ‘right’ way to render search, but having both of those common search types exposed as patterns would provide a starting point for designers and researches, whilst decoupling frontends from any server-side technology selected (or inherited) by developers.
@gordon.grace #2 is a good idea for a component-- like search box or something. I can imagine front-end devs spending alot of time on the styling of this and getting it accessible.
A few aspects to consider would be
- voice input for search
- Whether inline predictive suggestions are used
- live preview/list of results or common searches
I would be inclined when it comes to ‘advanced search’ to filtering interface after results have been presented. Trying to add such functionality to a search box adds complexity that is often better left to a search results page. One reason being starting with an advanced search invariably leads to no results due to specificity. Starting with the simple search first then filtering down reduces this.
There is certainly room for different patterns. It is something that we were looking into at the state library particularly with the complexities of whether it would be searching the website, events or the various library catalogs.