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.

6 Answers
6

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!

nice mockups! the swipe is a very interesting idea
–
talkolSep 20 '12 at 8:06

yes it's kinda is ))) but it will require a lot of additional programming which will lead to budget increase also it has to be user-tested to check if it's intuitive enough for your users. Does it worth it? Think again about the separate filter screen ;))))
–
LoomyBearSep 20 '12 at 20:27

Unfortunately I haven't received the answer I was looking for, but your answer was the closest in mind + I appreciate your work on the mockups -> bounty goes to you. Thanks!
–
talkolSep 23 '12 at 21:23

Wow! Thank you for this!! If you don't mind can you tell me what did you end up with? Because as far as I see every single person commented here (incl. me) tried to presuade you to use the separate filter screen. I guess you've got very strong reasons to stick up to your initial idea. I really wanna know what did you decide after all ... you can comment or send it to me personally if it's ok with you!
–
LoomyBearSep 24 '12 at 14:33

The question aimed at designing a general purpose control for same-screen table view filters. We finally went with the same approach used by AppZapp. You can see an example of this control in action here: appixia.com/demos/clarityenhanced/video (it shows the website the app is based on in the beginning to help understand the context)
–
talkolSep 27 '12 at 13:21

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.

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..

Good idea, but I think the Facebook approach is very similar to 2 screens. It's slightly better since the 2nd screen is always partially visible, so users are more inclined to pay with it.. but still, a solid single screen approach is what I'm looking for
–
talkolSep 17 '12 at 9:32

Ok, so what you want is: a way to display the filters, maintaining the width of the visible table untouched. But, at the same time, you don't want to deprioritize any filter, so it's should be intuitive to the user how to access them all "on the fly". An idea that would be (but I never tested it) to adopt a partial modal view sliding up from the bottom (or down from the top), that will contain the scrollable list of filter controls. Being actually a tableview (I guess) the user will naturally scroll through it, viewing all the filters.
–
Nicola MiottoSep 17 '12 at 9:45

Clearly, if you believe it could be a valuable idea, I will explain it better in the answer, with some mockup maybe
–
Nicola MiottoSep 17 '12 at 9:49

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.

1. The results are of course updated on-the-fly as the user updates the sliders, so that's a nice adventage. 2. The real-estate example shouldnt be taken too literally since this control is planned for other apps as well - for example a diamond filtering app. The requirement to have the filters more accessible comes from the client..
–
talkolSep 23 '12 at 10:51

Well, from a UX-standpoint one doesn't make requirements for a UI when there are better alternatives. I think the replies here clearly state the consensus that what your client wants is not in the best interest of the user.
–
ChristianSep 24 '12 at 11:14

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.

That's a nice idea.. place the filters on the top of the table (in the table header). And make the table start scroll from right after them. So if someone wants to filter, he would scroll upwards - kind of like "pull to reload" which hides on the table header. Don't know how intuitive this is though..
–
talkolSep 23 '12 at 10:59