Toolbars and filters
Author: Kevin Hatchoua | Last edit: March 21, 2023 | Design type: Charts | Product area: Hybrid Cloud Console
Toolbars for Charts
We recommend having a toolbar that is horizontally parallel to the charts. It is a more economical use of screen real estate and you can use an expand/collapse mechanism to get it out of the way.
Having a toolbar that is vertically parallel to the charts can be problematic because it could clash with navigation and take up horizontal space for charts that might need breadth (e.g. charts with timelines as axis). Still, it could help alleviate the problem of advanced filtering needing to]]]]]] be visible/readable (e.g. numerous filter variables/dimensions/attributes).
Having a toolbar in its own panel that could hide/show next to the charts (usually a sliding out panel that is vertical) is something to consider, but then would need some more research on the interaction with the chart and how it affects layout (e.g. is it on top or w/in context?).
Toolbar placement: w/in the greater layout
DON’T have a floating toolbar. Always have it anchored with either the header of the page or the card that contains the chart depending on its effect.
DO If the toolbar is w/in the chart’s card: right align the filters on the same line as the title. However, if there are so many filters that it’ll collide with the title, have it go to a new line, then make it left aligned on the new line (this is also what the wrapping behavior would be for responsiveness). If the toolbar is w/in the page header: left align the filters.
Filters for Charts
Filter types (selectors vs. attribute/value)
For charts, you may use attribute filters, or stand-alone dropdowns (ie: one toggle per attribute).
If you have more than 3 toggles, an attribute filter is recommended.
especially when you have more than 3 possible toggles/attributes, and when there are a lot of filter types to filter on, and having them all stand on their own would cause too much visual clutter. However, this drop-down menu ideally should not exceed 10 attributes.
If you only have 3 toggles or less, having to stand-alone toggles are recommended.
Attribute/value filter type
If your filters relate to the whole page, use an attribute filter at the toolbar level (with the assumption that there will be more than 3 filters)
If your filters deal with just a chart, use stand-alone toggles (with the assumption that there will be fewer than 3 filters)
Should I use chips or not?
Use chips if you have an attribute filter, or a mix of exposed multi and single selects so that users can see their selections at all times.
No need to use chips if your attributes are all exposed and all are single selects. In this scenario, every selection would already be visible in the selection toggle, making the chips redundant. If the filter deals with the entire page, default to attribute/value with chips. If it deals with one particular chart (w/in a page) and allows the user to select multi-options w/in the same attribute, use the “checkbox select w/badge”.
Try not to use labels for quick filters, try toggles - Margot suggests.
Date selectors (filter)
Date selectors should not be included in any attribute filters. They should be their own stand-alone filter.
To maintain consistency, your date pickers should follow this pattern:
Relative time date pickers
The relative time date selector should be a single list of relative times. What the time will be within your date selector will depend on your use case.
If you want to add a custom option, you may add it at the bottom of the dropdown. When a user clicks “Custom”, the date picker component will appear and be attached to the original relative date/time picker. “ By default, the pickers should have the words ''Start” and ''End”, and should not have any type ahead capability (you may change this if needed for your use case) Clicking on the “Start” date picker will open up a calendar picker.
See an in-context example of this here: https://tower-mockups.testing.ansible.com/analytics/jobs/analytics-jobs-date-dropdown/
Using “Last” vs “Past
Per Alana’s guidance:
Use “Last # days”: for time intervals that include the user’s current day.
Use “Past # days”: for time intervals that do not include the user’s current day.
Example: if Today is Aug 6th, and the user clicks on “Last 5 days”, they will see information for August 2nd to August 6th. But if the option were to say “Past 5 days”, they would see information for August 1st to August 5th.