Filters and filter bars

Every product with more than a few hundred rows eventually grows filters, and they arrive in roughly the same order: a search box, then a couple of dropdowns, then a date range, then somebody asks for "status is not closed AND owner is me" and the whole thing needs rethinking. The 3 filter components and 38 variants above cover that progression, from a simple bar to a slideout that builds real conditions.

Bar, dropdown, or slideout

The filter bar is the surface people see, and it comes in eight layouts: a simple bar, tabs with search, tabs with a date picker, date filters on their own, dropdowns, dropdowns with a date picker, and advanced versions in both inactive and applied states. Each one exists at 1,216px for desktop and 343px for mobile, which is where most filter designs quietly fall apart, since four side-by-side dropdowns have nowhere to go on a phone.

Behind the bar sits the filter dropdown, and for the heavier cases a slideout panel at 440px on desktop and full width at 375px on mobile. Reach for the slideout when a filter needs a field, an operator, and a value rather than a single choice. Cramming a query builder into a 240px dropdown menu is how you end up with a scrolling menu inside a scrolling page.

Apply button, or results that update as you go

This is the real decision, and it is not a matter of taste. Updating results on every click feels responsive with one filter and punishing with four, because each selection throws away the layout the user was reading.

Nielsen Norman Group’s research on filter intent lands on erring toward batch filtering with an Apply button, and the reason is simple: someone selecting a fourth facet has already decided what they want and does not need three interruptions on the way there. Instant filtering earns its place when the data set is small, the query runs fast, and users are browsing rather than hunting.

On mobile the calculation shifts again. NN/g’s work on filter trays found that keeping the result count visible while the panel is open lets people catch a wrong selection immediately, which is why the slideout variants here carry their applied state rather than hiding it.

The states a filter control needs and a menu does not

A filter trigger has a job an ordinary menu button does not: it has to show what it is currently doing. The dropdown component carries an active state where the trigger widens to hold the applied value, so a bar of filters reads as a sentence about the current query rather than a row of identical grey buttons.

There are also three distinct open states, one for a menu with nothing to show, one for an unset filter, and one for a filter with values already applied. And every state exists left aligned and right aligned, because a filter menu opening from the right edge of a table needs to flip or it opens off screen. It is a two-second fix in code and an easy thing to forget in a mockup, which is why the alignment is a property here. The whole file ships in light and dark.

Building it so the mobile version survives

Filter bars are the clearest argument for auto layout with wrap turned on. Set the bar to wrap and the dropdowns hug their contents, and an active filter that grows from 115px to 141px pushes the last control onto a second line instead of overflowing the frame.

Pair that with the mobile variants of each layout and you can show, rather than promise, what happens when someone applies four conditions on a phone. Add the date picker and tag components for applied-filter chips and the whole pattern stays inside one system, so a filter bar above a table or a dashboard looks like it belongs there.