Responsive Design: Getting Advanced Filtering Right
A practical example
Designing user interfaces for filtering content lists can be very challenging, especially when dealing with a lot of different parameters. Think of combining parameters like date range, content types and content statuses with keyword search. Good old and well-established design patterns do exist for this scenario. But now add small screens and responsive design to the mix: Great user experience faces big threats from factors such as decreased screen estate, clumsy fingers and variable viewing distances.
A View Mode Solution
As Daniel Wiklund (@danielwi) points out in his article “View mode” approach to responsive web design, off canvas navigation works well in responsive web design because it lets the user focus on the content, when browsing content, and it lets the user focus on navigation, when the user needs to navigate from a grander overview. Wiklund goes on to exemplify how this approach can also be used for filtering products on a site and performing searches.
I noticed a lot of similarities between Wiklund’s concepts and a recent design task we completed in Tradeshift, so I wanted to share our conclusions.
Dealing with Lists of Business Documents
One of Tradeshift’s services is exchanging business documents such as invoices, credit notes, purchase orders and quotes. This means that we also have document list views for users to manage their sales and purchases.
We know most users go to the list pages to track and update the payment status of unsettled transactions, so we default to this view:
On typical desktop and tablet sizes the list looks like this:
The non-filtered representation allows a person to get an overview of settled and unsettled business and work with these documents. Finding a collection of documents based on e.g. date ranges, document types, statuses and customer is another requirement, and necessitates more mechanics.
The Mechanics of filtering these Lists
Simple searches can be done on by clicking the search box and typing:
Further, a number of filters can be applied using overlay panels. We call these overlays pickers (see my article about them here) and they’re accessed by clicking the blue “Add filter” button. This slides in a picker overlay:
Also, pickers can be visually stacked to allow hierarchical selection without losing context:
When the filter has been applied, it will appear in the header section of the page, just below the search bar (yellow element on screenshot):
Multiple filters applied will line up next to each another:
Editing a filter is done by clicking the yellow filter value which opens the corresponding picker. The user will then be in filter-edit-mode and can in this isolated mode configure complex filters, with the list out of the way.
This simplified representation of filters in the header leaves plenty of space for list-browsing-mode — with the filter values serving as introduction of what the list contains.
So we achieved letting the user focus oneither view mode.
How does it respond to my Phone?
Actually, the desktop designs presented above were designed after our phone size views (yes, mobile first…). Here’re examples of the phone size UI:
There’re some tricks applied to make phone size work smoothly and allow better use of the limited vertical space: When the keyboard is active the title bar slides up-and-out and the applied filters compress to 50% height. Smooth animations ensure no abrupt visual disconnects are experienced when switching modes.
For ease of interpretation we stack the applied filters vertically, and we also give them the same yellow color treatment. The color treatment visually groups everything that filters the listed contents.
The stacked pickers work on phone size, exactly as on desktop size with minor styling tweaks such as a smaller header bar:
There’s a cognitive advantage in using the same design pattern on different devices: It only has to be learned once (probably only important if you have users accessing your service on different devices).
How about even more complex Cases?
We prefer appending the selected filter parameters above the list as a way to describe what the list contains. In extreme cases, say we had 5 or more parameters, we’d need to reconsider the way we’ve solved this, as the many parameter selections would take up so much space, that the list content updates wouldn’t be visible to the user.
Most scenarios in our case only involves adding one or two filters, so that’s not going to be an issue here. But say we had an apartment rental site. In that case the many possible simultaneous filter criteria would require a more compressed filter representation and we’d most likely have to put the individual filter edit/remove functionality into a picker instead of directly into the header of the list.
A Note on Aesthetics
We’ve chosen to keep the “thumb-sized” UI elements in our regular desktop size designs. We could easily have bumped down the sizes a bit to design around the more precise movements of a mouse pointer vs. tapping. But as the number of clickable elements is rather low and we not only aim to make a functionally easy service but also want it to look easy to use, we kept the same size UI elements. The bigger elements with the addition of white space allowed by the bigger screen sizes, simply makes it look easier to use. We even once had a user who said that Tradeshift looks easier to use than it actually is. Good for our aesthetics, calls for more work on the usability side of things, though, which this redesign represents.
If you liked this article I’d be happy if you click recommend. And/or, you can follow me on twitter @mibosc
