Price/hourly rate filter radio - input correlation

Question

I was faced the following problem. We have a search engine in our web application that makes it possible to filter results by selecting a single filter from each set, with four-five sets given - let's say, we can choose one language from ten given, one category from seven given, and one whatever else - let's say, a color, one out of six. In our particular case this kind of filter function is an absurd idea, however this is not the point. One of the aforementioned criteria in our filters is price. Since the typical workflow with each of the filters is that filter is added to the search right after the user clicks on it, we had to break it, because of the obvious need of entering some data from keyboard.

This is how it's supposed to look (and, in our sad case, can't be changed)*:

^{download bmml source – Wireframes created with Balsamiq Mockups}

Typically, a user sets the radio button to an appropriate state, and then enters the values. However, this is a happy case scenario; there's a few more of them

• User mistakenly enters fixed rate, but hourly rate is set; apply button is pressed and no-result search of "$1500 per hour" appears (and the other way round)
• User is less likely to switch fixed to hourly rate, because on the basis of previous experience, he might think the change itself will cause the page to reload

One of the most important guidelines for our UX is to minimize chances of showing no results on the search results page, so these are not the best options...

The client, who is the official world champion in micromanagement, said he wants these from/to fields to get reseted to zero after the user changes fixed/hourly radio button. This, obviously, makes no sense in the scenario when the user accidentally enters values for "hourly price" before switching the radio button (and this also forces him to fill them again...).

In these conditions, I simply ran out of ideas for answer to the question: how do I optimize this price process?

*Feel free to suggest answers involving changes, the client might change his mind.

Answer 1

If the situation is completely rigid then there are some things you can do:

1. on radio select focus on 'price from'
2. set up tabs for radio button > price from > price to > apply filter
3. bind enter key press event to the form elements as a group
4. depending on the size of the result sets / complexity of the server side search make ajax update the results immediately
5. on completion of the three fields show a result count before apply - in the case of a large, complex search this value could be stored in an optimised form on the server every time the items being searched are updated
6. offer the user an option with a button to reload their last search via localstorage

This would then make correcting a mistake easier and give the user some options and valuable feedback.

However, here are some further thoughts which might help you persuade people that a change is good. If you were to provide preset price ranges you could improve this interaction. Two clicks would render a set of results, one to select the type of range and a second to choose the range. This would benefit in the following way:

1. You would lose all text field / currency formating related number issues.
2. You would be able to display sensible ranges for each selection, so maybe $20-$50 / hour or $1500-$3000 per job.
3. The user would see quickly that they had the wrong range type selected by the available price choices.
4. You could load the filter with counts presented for each range and even drop or grey out a range that included no results.
5. The whole interation would be possible with either mouse or keyboard (with tab order done nicely).

In this case you could still allow a user defined range and then store that range in the users local storage to use it again when they come back and you could still apply some of the optimisations in the first list.

This artcile might help also: http://www.uxmatters.com/mt/archives/2010/02/numeric-filters-issues-and-best-practices.php