In this post I want to share thinking on a way to build a multi-select component. Try the demo.
If you prefer video, here’s a YouTube version of this post:
- 1 Overview #
- 2 Markup #
- 3 Layouts #
- 5 Kesimpulan #
- 6 Community remixes #
Users are often presented with items, sometimes lots of items, and in these cases it can be a good idea to provide a way to reduce the list to prevent choice overload. This blog post explores filtering UI as a way to reduce choices. It does this by presenting item attributes that users can select or deselect, reducing results and therefore reducing choice overload.
The goal is to enable swift traversal of filter options for all users and their varying input types. This will be delivered with an adaptable and responsive pair of components. A traditional sidebar of checkboxes for desktop, keyboard and screen readers, and a
for touch users.
This decision to use built-in multiselect for touch, and not for desktop, saves work and creates work, but I believe delivers appropriate experiences with less code debt than building the entire responsive experience in one component.
The touch component saves on space and helps user interaction accuracy on mobile. It saves space by collapsing an entire sidebar of checkboxes into a
built-in overlay touch experience. It helps input accuracy by showing a large touch overlay experience provided by the system.
Keyboard and gamepad #
Below is a demonstration of how to use a
from the keyboard.
This built-in multi-select can’t be styled and is only offered in a compact layout not suitable for presenting a lot of options. See how you can’t really see the breadth of options in that tiny box? While you can change its size, it’s still not as usable as a sidebar of checkboxes.
Both components will be contained in the same