Pickers and search blocks
These are the controls for answers that will not fit on the screen: every date there has ever been, every user in the account, every colour, every file on the machine. What they share is that the answer has to be narrowed before it can be chosen.
8 families, 35 blocks
- Date Picker5 blocksBooking flows, filters, scheduling forms
- Time Pickers5 blocksScheduling, reminders, bookings
- Comboboxes5 blocksLong option lists, pickers, settings
- Autocomplete2 blocksSearch, mentions, address entry
- Tag Inputs4 blocksLabels, recipients, multi-select filters
- Color Pickers5 blocksTheme editors, design tools, branding
- Filters3 blocksTables, catalogues, search results
- File upload6 blocksAttachments, avatars, document collection: anything that leaves the device
What these are for
A picker is two problems wearing one control. The first is finding a candidate in a set too large to display, which is search, filtering or a calendar grid. The second is confirming the choice and showing it afterwards, which is where most implementations fall down — a picker that clears its own field on blur, or shows an id where it should show a name, has solved the hard half and lost on the easy one.
Because they open something over the page, these blocks carry the overlay problems too: what closes them, what happens on a phone where a popover the width of a desktop dropdown would run off the screen, and where focus lands when they close. Those are answered in the block. A date picker that traps focus is worse than a plain text field that accepts a typed date.
Filters and file upload are here for the same reason the rest are: both are a choice made against a set the reader cannot see at once. A filter narrows the records; an upload dialogue narrows the filesystem. Both need a clear way back out, which is why every filter block here shows its active state as something removable rather than only as a changed result.
Choosing between them
Combobox or autocomplete?
A combobox has a fixed set of valid answers and typing narrows it — a country, a currency, a repository. Anything not on the list is not an answer. Autocomplete suggests against an open set where typing something unlisted is legitimate: a search query, an address, a person you are about to invite by email. Getting this backwards produces either a field that rejects a valid answer or one that silently accepts a typo as a new record.
Tag input or multi-select combobox?
Both collect several values. A tag input is right when the values are short, the order does not matter, and the reader may add ones that did not exist — labels, recipients, keywords. A multi-select combobox is right when the set is fixed and each item needs more than a word to identify it. The practical test is whether a chosen value reads sensibly as a small removable pill; if it needs two lines, it is a list with checkboxes.
Date picker or three inputs?
A calendar grid is for dates chosen in relation to other dates — a booking against availability, a range, anything where the day of the week matters. For a date the reader already knows, typing is faster than navigating, and a date of birth is the clearest case: nobody finds 1974 by pressing a back arrow six hundred times. The best fields accept both, and every date picker here can be typed into.
Where do filters belong on the page?
Above the records on a phone and beside them on a wide screen, and in both cases the active filters need to be visible from the records rather than only from inside the panel. The failure mode is a reader looking at an empty result set with no visible reason for it, which is what happens when filters live behind a button that does not show its own state.
Questions
Can the pickers be typed into as well as clicked?
Yes, and that is deliberate. A picker that only accepts pointing is slow for anyone who already knows their answer and impossible for anyone using a keyboard only. Typing and picking resolve to the same value, and the field shows the result the same way whichever route produced it.
Does the file upload block handle the actual upload?
It handles selection, drag-and-drop, the file list, progress display and the error and retry states. The transfer itself is yours, because it belongs to your storage and your credentials. Progress is a value you pass in, so it works the same whether you are uploading to your own server or straight to object storage.
How do these work on a touchscreen?
Each one is capped to the device rather than to the window, so a picker that opens as a dropdown on a wide screen opens as a sheet on a phone instead of running off the edge. Targets are sized for a finger, and nothing here depends on hover to reveal how it works.
The other categories
All documentation
Getting started
Foundations
All components