Design Pattern Library - Update, standardise and document the in-page search filter patterns
Problem
I first noticed this while looking at gitlab-org/gitlab-ce#46749 when I started exploring further, I found out that our in-page search filters don't really look like a search pattern and they also behave differently on different pages. The goal of this issue is to discuss, update and standardise the pattern. After that, further issues should be opened to document it (add to the search page in design system) and to update the pattern wherever it's present in our application.
As it is now, the pattern suffers from poor usability, lack of consistency and prominence. This is what the pattern looks like atm:
Interaction inconsistencies:
- sometimes the search is triggered by pressing enter or a button
- sometimes the search is triggered by typing alone
No matter which of the two is used, they look the same.
Currently used in: commits page, grooups page, projects page, branches page
Sometimes it looks like this:
Currently used in Graph page
or like this:
Commonly but inconsistently used throughout the application.
Solution
These suggestions are based on the research linked below in the 'Links/references' section. In general, there's a lot of research that suggests the following suggested updates and guidelines.
Suggested updates & guidelines:
- Add a search icon inside the input field so it's clearly recognized as a search box.
- An 'x' icon should show up when the user types in a search query. Clicking it clears the search box and focuses it.
- If the search starts by typing we should indicate when there is a search in progress (animated spinner or something similar). This indicates that there's no further action required by the user.
- If the search starts by pressing 'Enter' it should have a small icon button to ther right of the search box. This indicates that there's further action required to trigger the search.
- It should be visually separated from unrelated UI elements around it (like 'Sort by')
- It should be consistently placed on the top right of the page (doesn't seem to be a problem atm but it's good to write this down).
- Research suggests that the presence of the search icon in the search box is enough for users to recognize it so the label isn't needed. It also suggests that, ideally, the search box should be empty (no placeholder). Based on that, I think it's safe to suggest that this is one of the exceptions where labels for input fields aren't mandatory but a nice to have. Ideally it should have a label and no placeholder but it's ok if space constraints force us into using the placeholder and skipping the label.
- Update error states so that they're contextual (example)
It seems we have a basic division into two types of search filtering:
- Search by typing
- Search by clicking on a button (or pressing 'Return')
They're divided by how users interact with them. There's no need to force-merge the two patterns into one but because the ineractions are different, the UI should also be different.
I suggest we formalize and add the following two patterns to the library:
And also update the most commonly and prominently used one so it's better aligned with the 2. from above.
Then we can revisit gitlab-org/gitlab-ce#26303 and update the search boxes throughout the app and make them consistent.
Placeholder guidelines
This pattern relies heavily on correct usage of placeholders and is one of the exception where labels above the input field aren't mandatory. Despite the presence of the search icon in both version of this pattern, the search box should always have a placeholder. Either 'Search' or 'Filter' can be used but never both ('Search or filter results...') because they're two words describing the same action. Additional words can be added ('Search git revisions') but should be avoided if possible. For example, if the search box is located on the 'Git revisions' page, 'Search' alone in the search box is enough.
Naming
As mentioned by Pedro, the naming of this pattern is a bit confusing. Is it a search or a filter? He also attached a link to a similar discussion that came to the following conclusion:
“Filtering takes an existing full list, and removes items based on criteria that match/don't match. Search takes a blank slate and adds to it based on criteria that match/don't match.”
By this definition, this pattern is clearly about filtering, no matter what triggers it (typing or button click). But from the user's point of view, this is still a search. They have a list of items and they want to find a specific one. Therefore, using the word 'Search' as a placeholder in this pattern is ok (so is 'Filter'). As for the name, in-page search or search filter should be fine. When it comes to the design system, this pattern will fall under the 'Search' section.
Related patterns
(List any related or similar solutions. If none, write: No related patterns)
Links / references
- Search: visible and simple
- The Magnifying-Glass Icon in Search Design: Pros and Cons
- Design a perfect search box
- 10 Usability Guidelines For Designing The Search Interface
- Search vs Filter—what is the difference
Pattern checklist
Make sure these are completed before closing the issue, with a link to the relevant commit, if applicable.
-
Ensure that you have broken things down into atoms, molecules, and organisms. -
Check that you have not created a duplicate of an existing pattern. -
Ensure that you have used the proper method for creating the pattern depending on the complexity. Atoms and molecules are symbols, organisms are groups. -
Make sure that typography is using text styles. When applicable used shared styles for colors. -
QA check by another UXer -
Add changes to the pattern library -
Add a merge request that includes any new or updated guidelines to the Design SystemSeparate issue (gitlab-org/design.gitlab.com#92) -
Add an agenda item to the next UX weekly call to inform everyone (if new pattern, not yet used in the application)
/cc @cperessini @dimitrieh @hazelyang @jkarthik @pedroms @sarrahvesselov @sarahod @tauriedavis @katokpara @matejlatin @andyvolpe