Octopus supports large-scale data collections across Tenants, Deployment Targets, Workers, Releases, Variables, and many more areas. Aside from representing the information in an easily digestible way, we must provide a quick way for users to find the relevant items they are looking for.
Well-designed, intuitive-to-use filtering mechanisms enable discoverability. They save time and reduce the complexity of data-heavy interfaces.
When to use filtering
Filters help narrow down large datasets based on user-selected criteria (one or more parameters) to surface most relevant results. Use filtering in those cases, especially if the goal is to:
- Enhance navigation and discovery efficiency: reduce the time browsing irrelevant data and make finding relevant items fast
- Reduce cognitive load: decrease the amount of data displayed to combat fatigue and overwhelm
- Help customize content: allow users to customize displayed data to what’s most relevant to them
Filter anatomy and terminology
Filters consist of several foundational concepts that, when combined, create a variable that determines what data is included or excluded from a dataset.
|
Terminology |
Description |
Example |
|---|---|---|
|
Parameter |
Specific property or category. Often expressed as the label on the filter field |
Health status, Deployment Target Types |
|
Value |
Specific value within a parameter |
Unavailable, Azure Web App |
|
Conditional |
Relationship between parameter and the value. Most often, the equals conditional meaning that parameter equals to a single value or an array of values |
Equals, Does not equal, Greater than |
Filtering vs searching
Filtering and searching can support overlapping goals, but there are key differences in how they work and when they should be used:
|
|
Filtering |
Searching |
|---|---|---|
|
Use case |
Refining or browsing a large dataset |
Finding a specific item |
|
User input |
Selecting from predefined list(s) of criteria |
Typing keyword(s) |
|
Scope |
Applied to specific fields or areas (e.g. a table) |
Applied to an area (e.g. whole page, a table) or product-wide |
Avoid mixing the two concepts as it might confuse users. When using filtering and search in conjunction, make sure to communicate clearly what input is expected and what area is affected.
Filtering vs sorting
Filtering and sorting are often used together as methods for manipulating data sets. Filtering removes options that don’t match selected criteria, while sorting organizes options in a selected order.
For complex data sets (especially in tables), offering both sorting and filtering mechanisms will provide the most efficient way to find relevant items.
Number of filtering options
The higher the number of filtering options, the higher the chance of analysis paralysis. To avoid choice overload, prioritize the most relevant and frequently used filtering parameters relevant to the represented data set and user goals.
If the number of filtering parameters is high, use progressive disclosure to reveal filters when they are relevant (for example, group related filtering options in Accordions).
Result fetching methods
When the results should be fetched and displayed to the user depends on the number of filtering parameters, amount of data that’s being filtered and how quickly the results can be displayed.
|
Approach |
Description |
Fetch timing |
Number of filters |
|---|---|---|---|
|
Live filter |
Filters are applied as a single option is chosen. Useful when applying a singular filter only, as it creates significant layout shifts that might be jarring to users. |
Instantly |
One filter |
|
Per filter |
Filters are applied when each parameter options are chosen. For example: three options are picked out of a single MultiSelect. Useful when making multiple selections within a single parameter. |
On submission (pressing a CTA button) |
One filter |
|
Batch filter |
Filters are applied when multiple options are chosen across multiple parameters. Useful when working with the largest datasets and performance constraints. |
On submission (pressing a CTA button) |
Many filters |
Live filtering should be used with caution, and only when per filter and batch filtering aren’t feasible. In most scenarios within the Octopus product, batch filtering is most relevant due to the number of filters available and large scale of data.
Filter positioning
Where filtering mechanisms are placed within the context of a whole page depends on what part of the page is affected when filtering (sections vs entire page) and how many filtering options have to be accommodated:
|
Filter position |
Top bar |
Sidebar |
|---|---|---|
|
Preview |
|
|
|
Description |
Filter bar placed above specific elements in the page (most often tables) that will be affected by selected filters. |
Sidebar placed on the left-hand side to the page content that houses all filtering options and selected filter summary. The entirety of the page content is affected by filtering. |
|
Scalability |
Medium. Useful with a fixed number of filters that always remain in a single line across different screen resolutions. |
High. Useful when working with a high number of filtering options that can easily scale vertically across the sidebar. |
|
Affected area |
Page section (with option to affect whole page). |
Whole page. |
Displaying selected filters
Ensure that the selected filters are always visible, so users are aware of how the displayed data is affected by their filtering choices. Selected values can be shown for a single component or a combination of components (such as the Top bar or Sidebar approach described above).
When multiple filters are applied, it is also vital to display the count of selected filters. This approach gives users direct feedback on the scale of selection and how the results will be affected.
Clearing filters
Always provide a way to clear selected filters. Each singular value should be dismissible (using the Tag component), and all values can be cleared at once too (using the Link component).
Saving filters
In some cases, users will want to repeatedly come back to a filtered data set, as it’s most relevant to their use case. Instead of forcing them to recreate filter options every single time:
- preserve selected filters until the user clears them
- append selected filter options to the URL string, so it can be bookmarked for future reference or shared with team members
Showing number of results
When filters are applied, always display how many items (out of total number of items) are currently shown. This gives users direct feedback on how filtering narrows down the dataset.
Managing no results
Avoid displaying no results. While it’s not uncommon to create filtering combinations that will yield zero found items, preventing users from finding nothing provides a better experience than displaying an empty state:
- add item count to the button used to apply the filter (e.g.: Show 0 Tenants)
- disable options that would yield no results (e.g.: entire filter parameters, or options within a certain filter), and communicate they would yield 0 results