Are collapsed filters an antipattern? or does it depend on the intended user?
morde last edited by
So we are building a monitoring page intended for a specialized group of users who would like to keep an eye on their logs. We are implementing a filtering solution to help users find the type of messages that they would be interested in. While researching, I noticed that Shopify has implemented filters on their product page within collapsable panels.
Filters within collapsable panels are treated as a big no-no when building e-commerce sites and it is recommended to show everything and let the user scroll through them. Shopify admin doesn't follow this pattern. I am aware the users for the admin section and the ecom site have different needs and use the products differently. I assume the Shopify's implementations aims to give the user the birds eye view of all the available filters so that the user doesnt waste time scrolling to find the required filter. I have not see any ux design doc/blog supporting this implementation so was wondering what the consensus is in the UX community? I know this is very subjective and looking for your personal take on this matter and will be greatful for any links or resources that might support this type of implementation.
I am currently facing a similar challenge regarding pages with "too many" filters. Showing all of them and asking the user to scroll through all of them, while reading each and every one, seems to be a no-go.
The benchmark upon which we chose to work is the component used at mixpanel.com:
No filters are shown, just a "+ Add" button
All possible filters are then shown in a scrollable list. They are also divided by categories using both tabs on top of the list (the default one being "All") and separators inside the list. Recently used filters are always on top, which is a very nice touch in my opinion. If you hover over a filter, a description of the filter is shown on the right.
The key point in this implementation is sending the focus straight to the search, which filters the filter list as you type:
After selecting a parameter (filter) the user is presented with a component that is relevant to the type of data of that parameter: numeric only field for numeric value, generic text field for alphanumeric value, calendar for dates, switches for boolean choices, etc. The user can also set a logical operator for the input: equals, does not equal, is in range, is not in range, etc.
After confirmation, the filter is presented as a single line. If during the previous steps the user chose more than one option for a parameter (by ticking two or more checkboxes), those options are presented in a "this OR that" logic. If the user adds another filter, it will be added in a "this AND that" logic.
I see this as a very intuitive implementation for such a complex range of possibilities. One could certainly tweak this implementation, like removing the logical operation functionality, for example, to solve the "many filters" problem.
Now, for the problems:
This implementation is very different than what people are used to. It might require a second of learning, which is probably a deal breaker for e-commerce sites (but I don't believe that is the kind of project you're working on, right?)
This implementation kinda does away with traditional search. Your user wouldn't be able to find a smartphone by typing "smartphone" or "android" right away, since those would be "values" inside the "name" parameter.
It is more complex than it needs to be for simpler requests. Even the most straightforward user query would have to undergo a couple of steps and that user would be presented with quite a bit of information (filter categories, data type, logical operators..) that he or she didn't really ask for.
The main point I'm currently working on is adapting this to solve the "search for smartphone" problem. The challenge is returning results for both parameter names and parameter values at the same time in a clear and intuitive presentation.
Well, hope this helps you get going on your challenge.