iPhone table view filter with multiple controls

Question

Assume we have a real-estate iPhone app which shows a list of properties in a table view.

I would like to offer the user the ability to filter the list according to about 6-7 different criteria.

Each filter criterion uses its own control. For example, filter by price range will use a slider with two knobs which can be used to mark a range. Filter by square footage will use a similar slider. Filter by neighborhood will show a list of 5-6 neighborhoods with multi-select. Filter by rent or sale will show a 2-item multi-select, and so forth.

In order to make the app more engaging and less tiresome to operate, I want to avoid the straightforward approach of 2-screens: First screen is the table view with a "Filter" button on the top right of the navigation controller. User presses the button, a new screen slides-in with all the filter controls in a long list. Similar to this screenshot:

.

I saw an interesting single-screen approach implemented by the AppZapp app (screenshot below). They have a toolbar under the navigation bar with multiple buttons (one for each filter field). When you tap a field, the entire table view slides down and leaves room for the filter control. When you tap again, the table view slides back up and the control is hidden.

I still have a problem with their scrollable toolbar concept. Since only about 3-4 buttons fit in the toolbar, you need to scroll the toolbar sideways to see all filters (see screenshot). Keep in mind that all filters are of equal importance and I don't want to use 3 common ones and an advanced button that opens 2nd screen.

The unfiltered list is impossible to work with. In order to make the app effective, a user will have to constantly play with different filter combinations. I feel that if users have to open a 2nd screen every time, they are less likely to filter, and will not find the app useful.

Any alternative ideas?

Answer 1

I think it is not very important to keep all these filters on sight. Besides this 44-50px height (@loRes) Segmented Controls Tab sometimes is not very easy even for a simple tap action and of course it is a way harder for more complex interactions such swipe. My main concern about this control is bad accessibility.

And if you like this control so bad. My proposal to you is to implement this swipe-tab navigation used by default in Android. Maybe like this

So the navigation between filter tabs is much more accessible and easy to use. Of course, since this kind of interaction is not in iOS-core-based you will have to provide user with some kind of tip or helper explaining how to use this control.

But my personal advice is to give up with this idea and call filters in the separate screen it is more usable and provides much better user experience!

Answer 2

If you need to put the focus on filters and allowing the user to "configure" a set of filters, you could take this approach

Upon selecting a filtering criteria, a "filter config. page" could be shown and each "completed" filter could show a tick mark.

Answer 3

I think there is nothing wrong with a usable 2-page approach, rather I feel there is a big usability issue when you put too many options on one page, and moreover if you choose slider bars for all the options.

My suggestion would be to use 2-page approach, but use different UI elements for each option. For example for the radius, you can use "slider", for price you can use a text field, when tapped the text field would only show numbers (since price will be in numbers, so the alphabet part of the keyboard/keypad will be hidden) etc.

Example:

Answer 4

What about using the side menu à la Facebook app? It gives you the chance to show the filters organised in a table, with a lot of space to fit them all and leaving the products partially visible (and then the filtering result), without opening a complete new screen..

Answer 5

I think you may be trying to solve a non-existing problem. The most important question seems to be: Does it help the user being able to have the filters always at hand?

I highly doubt it in this specific scenario, yet I cannot provide any data to support it. I can only speak from the heart of someone who is quite used to use real estate sites, so here is what I would do to come to a more informed answer:

I would try to figure out which filters are being changed on the fly at all. I assume the app is being built for an existing real estate service. So I'd ask them to either provide the statistical data they already have, or have them collect some. It shouldn't require much more than a week to get significant data, since those pages usually are highly frequented.

Then I would take things from there: What filters are really important and need to be easily and promptly accessible? What filters are usually only set once and thus can remain on their own screen?

It seems counter-intuitive to give all filters the same priority in a scenario where some (maximum cost, minimum bedrooms) most likely are gonna be less flexible on the user's end than others (neighborhood).

Additionally, the sliding solutions mentioned here are kind of the same as a second screen from the user's perspective. The differentiation we as designers and developers make may say "This is one screen with a sliding element, and that are two separate screens". Whereas for the user the implications are pretty much identical: "This one draws my attention from the result list to a sliding element, and that to another screen".

Both scenarios require the user to shift their focus to another region of the application. Taking that both solutions require the exact same interactions: 1) tap to slide in/change screen 2) adjust filters 3) tap to slide out/change screen

Unless you live-update the results while the user moves a slider I honestly cannot think of any advantage the sliding solution would have over a second screen. Nor can I see how this would make the application either one of more engaging and less tiresome.

Finally, here's one more thought: What is the motivation for a user to change a filter in the first place? I would assume the answer to be "because he is not satisfied with the results". Thus he decides that the current result list is not interesting anymore and can be dismissed. Which, in my book, is one more reason not to worry about getting the results and the filter settings on the same screen.

Answer 6

I would modify Adis approach and try to compress the filter area. Use input fields together with numeric steppers. You could fit them on the same row. The label radius could fit on the same line as the slider etc. Then you could place the filter area on the same page as the table.

With this solution the user could then scroll up and down in order to quickly change the values and see the results. Additionally you could add a button that scroll the page up to the filters or down to the table.