Search results pattern. #3766
Search results pattern. #3766
Conversation
humancompanion-usds
temporarily deployed
to
development
GitHub Actions
Inactive
humancompanion-usds
temporarily deployed
to
development
GitHub Actions
Inactive
humancompanion-usds
changed the title
humancompanion-usds
temporarily deployed
to
development
GitHub Actions
Inactive
humancompanion-usds
temporarily deployed
to
development
GitHub Actions
Inactive
|
@danbrady - This is ready for your review. I also started the task of building out the templates, which I've linked to here in the front matter. You can review those at your leisure and @caw310 will give you all a ticket to complete those templates. Ryan has much of the work in the Design Gaps file, but there a number of variations to cover. I've annotated the ones in guidance that I thought were most relevant to start with. |
| anchors: | ||
| - anchor: About | ||
| - anchor: Examples | ||
| - anchor: Structure |
There was a problem hiding this comment.
The Structure anchor doesn't go anywhere. It looks like we have two Structure sections: the Search Results Page and the Single Search result. Perhaps add both those links here instead? Or keep the "Structure" section and have "Search Result Page" and "Single Search Result" as sections with the Structure section?
|
|
||
| ### URL | ||
|
|
||
| The text of the link of the matching page. This should not be a link (the header is the link). |
There was a problem hiding this comment.
What's the benefit of showing the URL? Could that be awkwardly read out to screen readers? Perhaps the search breadcrumb could be more helpful than a URL? (At least for the global site search.)
| * Sometimes users want to simply sort a list (and not filter anything) and should have a clear path to do so. | ||
| * Combining them adds unnecessary complexity and cognitive load, and can force users to make more clicks or taps to simply reorder a list (Sort) while still having to navigate through the Filter options. | ||
| * **Sorting happens inline on the page.** Do not take users to a new page or screen in order to sort search results. | ||
| * **Sorting does not require an additional action.** Sorting does not require an accompanying button to trigger the sort. Changing the select menu triggers the sorting action. |
There was a problem hiding this comment.
Changing the select menu triggers the sorting action.
Could auto-updating the page "onchange" of the select cause accessibility issues for AT users?
| * **Uses filters when there are facets to filter by and when there is more than one page of results.** Filtering is not required but recommended in these scenarios: | ||
| * When there are categories of results (facets) returned AND | ||
| * Where there is more than 1 page of results (i.e results are not pre-determined to be limited to a short list of 10-20 items) | ||
| * **Use filter chips to show the filters being applied when there are more than 3 facets.** 3 or more facets requires the use of filter chips to show what is currently selected in filters. |
There was a problem hiding this comment.
filter chips
Is the idea to make these a new component? Does the page auto-update when a user clicks the "x"? Is there an accessibility issue with that?
| * **Use filter chips to show the filters being applied when there are more than 3 facets.** 3 or more facets requires the use of filter chips to show what is currently selected in filters. | ||
| * **Filters collapse inside an Accordion below table width.** At mobile viewports, up until the tablet breakpoint, filters should collapse inside an Accordion component. | ||
| * **Use a left-hand sidebar when the main purpose of the product is to search.** If your product's main purpose is to allow users to search, then use a persistent, visible, left side navigation from the tablet breakpoint and wider viewports. For example, global Search, GI Bill Comparison tool, and Resource & Support (or other knowledge bases) feature search, filtering, and sorting as the main focus of their products thus they would use a persistent side navigation to hold filtering. | ||
| * **Sort and filtering are not the same!** Do not conflate the Sort action with the Filter action. See [guidance on sort](#sort). |
There was a problem hiding this comment.
Sort and filtering are not the same!** Do not conflate the Sort action with the Filter action.
This exact line was mentioned in line 167 of the "How to design and build" section. Just confirming it's intentional here.
| * **Sort and filtering are not the same!** Do not conflate the Sort action with the Filter action. See [guidance on sort](#sort). | ||
| * **Use a checkbox for filtering on multiple facets.** Multiple facet filtering uses the [Checkbox]({{ site.baseurl }}/components/form/checkbox) component as the interaction input. | ||
| * **Use a radio button when only one filter can be applied at a time.** If a facet only allows mutually exclusive results at a time, in other words only one filter can be applied at one time, then use the [Radio button]({{ site.baseurl }}/components/form/radio-button) component as the interaction input up to 5 items. For more than 5 items use a [Select]({{ site.baseurl }}/components/form/select) component. | ||
| * When there only 2-3 items within a facet that can be filtered on, use of a Segmented Button component is an option excluding task flows such as filling out a form, reviewing secure messages, etc. |
There was a problem hiding this comment.
When there are only 2-3 items...
Missing word
This just jumpstarts the template for search results. Ryan will hand us the Figma file that we can use to create a template in Figma. More to come on this but I'd like to get out what we have as a candidate.