PJs filter region
As outlined in #827 (closed), there are a number of inconsistencies in how we allow users to filter in GitLab.
We need to create designs & documentation for a unified filter region experience and show how this works systematically for every use case across GitLab.
UI component design isn't my forte, so I'm very open to critique! I do, however, think the design principles shown below are fairly robust.
I can probably test the designs for this filter region in some upcoming research on To-Dos.
1. Dropdown option
|Example||Hidden||Dropdown filter||Search filter||Saved filters|
2. Rolldown option
3. Simple/advanced toggle option
The filter region is a flexible region which allows users to filter data sets using a variety of input methods. This region should satisfy the vast majority of filtering use cases across GitLab including filtering of tables, metrics, boards, lists & charts - meaning one region can be used for everything.
Design principles / solution criteria
- Space - Maximise screen real-estate for filter bar globally
- Optionality - Provide different filtering options for different personas
- Flexibility - Provide flexibility (with guidelines) around filtering parameters layouts for different use cases
- Modularity - Configured with General metrics API for ease of implementation, integrated with other common components/regions such as page header region
The filter region uses a dropdown located immediately above the filter bar in page header (or tab bar, if present). It lets users choose between their filtering mode of choice...
- Hidden - Sometimes the filter will not be required or a user wants to maximise focus on the page.
- Dropdown filter - Dropdown filters are the simplest way of filtering. It is useful when there are fewer filter parameters or the user needs more obvious guidance on what their filter options are. This filter method is currently found in To-Do lists.
- Search filter - Search filters are the most efficient way of inputting new filters and are described in filter component. It is useful when dealing with power users who want to maximise time using their keyboard. This filter method is currently found in Issue lists, Issue boards & Analytics pages.
- Saved filter - Saved filters provide a list of recent and saved filter combinations. Users can create "filter sets" by pressing the plus button (which brings up a modal) or by saving directly from dropdown and saved views. This is useful for applying common filter parameter combinations. This filter method is currently not in use.
Based on the use case and application, there will naturally be varying filter parameters - meaning it's impossible to have a completely uniform component across the product. We can, however, standardise on layouts within the filter parameter mode to improve consistency and clarity for users...
The key layout anatomy would be...
- Keyword search [optional] (left-aligned)
- More popular parameters (left-aligned)
- Less popular parameters [optional] (left-aligned)
- Date time range [optional] (right-aligned)
- Clear page (right-aligned)
We can create continuity between the dropdown filter mode and search filter mode by allowing dropdown-type parameters as search queries. For example, a date range could look like...
Communicate technical constraints within the UI and limit user input to prevent error messages.
- Hidden - n/a
- Dropdown filter - Handled within the dropdown components & error validation messages, and by hiding options (progressive disclosure)
- Search filter - Handled within the dropdowns in the token component & error validation messages, and by hiding options (progressive disclosure)
- Saved filter - Handled when creating the saved filter set
|Search parameter options limited||label quantity limited||Date range constained within calendar UI|
We can eventually save even more space in the filter bar by having a single
[date-range-picker](https://gitlab.com/gitlab-org/gitlab-design/-/issues/895) component which handles the date range limit within the dropdown.
Filters should be placed immediately above the data set and component they are filtering. On some more complicated page layouts, such as Dashboards, seeing what has been filtered vs what hasn't can get confusing. Therefore, clear filter signifiers should be provided to show which components have been filtered and which haven't...
- Lists -
- Boards -
- Tables -
- Charts -
- Metrics -
Pros and Cons Analysis
|Search filter||Dropdown filter combination|
|Unlimited filtering variables||Better: no matter how many filter ariables are there, there is aways space||Limited improvement: increase the lines of displaying filter, using Kabab icon etc.|
|Visibility all available variables before selecting||Placeholder?||Better: no need to click, by glace understand|
|Visibility all available variables after selecting||Better: what is selected is easier||Can be improved: with two lines filter or other formats of filter|
|Easier to learn how to use||There is a learning curve on how to use the search filter. This is not a free text filter. How to use filters. How to combine filter and free text. When the search filter is applied.||Better: click -> select -> apply. It is a comparable easy interaction|
|Easier to understand filter variable relation: "OR"||The default logic is less visible||Better: By default, multi-filter is OR relation even if a user is not familiar with OR and AND logic. In other words, the user doesn't need to think this way.|
|And adapt more logics: "AND", "OR", "!="||Possible, but there is an learning curve. Plus thinking of a mixed combination of different logic is not easy||Not possible|
|Touch screen||Challenging the touch area is always the same on the top. Imagine user already selected two filters, and want to apply another one, should expand the search area and show less dropdown selection or the other way around? When to display keyboard? etc.||Slightly Better, because touch screen needs to know when to load keyboard. Free text load keyboard. Others don't|
|The ideal applications/use cases of each filter mode||When the combination of filtering fields need to be flexible: mixed of And/OR and unlimited growing possibility; It is easy for user to guess what can be filtered||Limited amount of filter field. user need to change the filter quick and often.|
|Have a pre-defined/default/previous filter-or-searched value for filter.||Challenging Having a default value in search or keep the last search result is not common. For most searches available outside there, each time user refresh the page, search reset to empty. We can introduce search history to serve similar.||Slightly better, for dropdown, default value is sually all or none, and it is obivious for user to see what have been selected. For multi-selectin dropdown if the default value is not all or empty. It becomes a bit diffiult for user get it by a glance|
|Switch between different mode||search filters>>quick filters Challenging we are asking user to choose an interaction pluse quick fitlers might contain less than search. Need to explain that.||quick filters >> search Challenging It feels like filter contains a free text search. We are asking user to imagine a search-filter function they never seen before ... might be easier to ask them to add more filters fields|
|Where and when we set each mode as a default||If switching is chanllenging, I would assume use prefer one that likely user won't need to switch between them is better?|