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.
Hey all thanks for all the feedback,
Am currently working on a PR for an initial release:
I took note of examples above and combined it with:
- the existing styling for buttons and text inputs
- respsonsive, icon only , text only variations. similar to USDS implementation
- displaying as table (so everything is in line and works on <ie9)
- png icon fallback for ie8. I couldn’t get utf characters to work properly for the magnifiying glass icon. Will not be shipping this component with this png, rather will provide some guidance on how to add the png fallback for ie8
- have removed the default clear icons for the
type="search"input element. These were inconsistent across browsers and have very small target areas, creating an accessibility issue.
- autocomplete, however this would likely be added to the text-inputs component
- potentially having clear buttons, would need to ensure they have a larger target area compared to the defaults as per 2.5.5
- any others?
Looking at the latest PR (https://github.com/govau/design-system-components/pull/871) -
I’d suggest discussing the following for future releases:
aria-label="SCOPE", the intended scope of a search form is clearly indicated, but may be unnecessarily noisy when combined with other labels for the search input. Worth exploring (or at least documenting) when/if these attributes should be added.
Site search behaviour on small-screens
Bigger question here - when on a small-screen device, the site search input appears above, and competes with, the collapsed version of mainNav to a ‘Menu’ burger.
Could / should the header search input be similarly-toggleable, and receive the same visual weight and prominence of the collapsed menu bar when in small screen mode?
A brief environmental scan would indicate that header menu bar positioning is typically on the left, site search toggle on the right, and that they’re mutually-exclusive. This is worth confirming in more detail with usability testing.
Each of these could warrant its own GitHub issue, but expected search input behaviours may vary considerably from a typical text input. Consider how a default search input might be expected to use (or deliberately disable) the following HTML attributes: