Search based on multiple fields - usability

Question

We have a search scenario where the user should be able to do a search based on four inputs, three being 'optional' text inputs and the fourth one being a select box

We came with below three approaches for this

Approach 1: Just inputs and results are shown in most relevant order i.e. if the user inputs one and two and three -

the results matching (one AND two AND three) are shown first, next (one AND two) , next (two AND three),then the results matching only one, only two, only three and so on...

Approach 2: Give an extra input to the user asking for search preference - whether the results should be based on AND or OR - so if the user has values entered in one and two,provided an option in four and if AND is selected - the results will be matching on (one AND two AND four)

if OR is selected - the results will be matching on (one OR two OR four)

Approach 3: More advanced search - where AND or OR criteria can be provided for each input

---

The end users for the application are business consultants with no math background and we want to make the application usable without any special training.

My personal choice is approach 1 - which is way cleaner and most relevant results are shown first- without the need to do much explaining to the end user...

Given there is no impact on search performance whatever the approach we take, what is the best approach out of these three? or is there any other way to do it better?

Answer 1

This is not a direct answer, but are you absolutely sure that your users actually want multiple boxes where they type a search term into? So often people make search boxes that correspond to database table fields, something like this:

                            (SELECT * FROM Users
Email:  [                ]   WHERE Email LIKE '%email%' AND
First:  [                ]         First LIKE '%first%' AND
Last:   [                ]          Last LIKE '%last%')

But this is an unnecessary complication that has little relevance to the user. They just want to hunt for someone and let the computer sort it out. Something like this works better:

                            (SELECT * FROM Users
Name: [                  ]   WHERE Email LIKE '%name%' OR
                                   First LIKE '%name%' OR
                                    Last LIKE '%name%')

On a related note, it is far better usability to have a single box and allow users to use keywords than to have users construct a query from multiple boxes. Rather than your interface, could you use parsing like [alpha AND beta OR gamma], and split that out after submit into a more database friendly request?

---

In conclusion, wherever possible search every likely field for their request using OR. For requests between different fields, use AND. The number of use cases where this will not be sufficient for a users needs are vanishingly small, and I have had excellent success searching tends of thousands of users with this method. Below is a mockup of the search interface I designed at my previous job:

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

If you searched for 'john smith' in the name, behind the scenes the constructed search became similar to 'where first, last, or email LIKE '%john%' AND first, last, or email LIKE '%smith%'. 99 times out of a hundred, they got exactly what they expected.

Punctuation was stripped out, which also meant that searches like this in the address also worked perfectly: '123 Main Street, 53225' in the address. I did optimize slightly and not search the 'zipcode' field for non-numeric tokens. Only very rarely in real-world conditions does this produce unexpected results. One example might be: 54901 Wisconsin Ave. It would pull up one very specific user, but it would also get dozens or hundreds of results from the zipcode 54901 (which happens to be in wisconsin). But ambiguous interpretation happens far less in the real world than you would think, and the usability that this type of flexible search gets you is excellent.

The end result is that the queries do more work (lots of searching against irrelevant fields) in order to save the user a lot of time and thinking. This is almost always the right trade-off to make, unless your database or search volume is massive.

Answer 2

I think Approach 1 and Approach 2 can be confusing to a user because the user might not be able to understand the interaction/relationship between each field.

I think Approach 3 is the most straightforward, but I would make one change: since the choice is binary ('OR' or 'AND'), you should use radio buttons rather than a drop-down list.

Answer 3

Do you need to go that far and offer choices based on each input field? If not, approach #2 is what I would chose.

Given the background of your audience it might be better to go with something different than AND / OR. How about something like

(o) All of these terms' vs. ( ) 'Any of these terms'

Answer 4

UI is way too cluttered. So I am supposed to read each field and decide what I want to enter?

Why not consolidate all the search fields, run the query as an "AND" search, and do some testing to determine your comfort level with the results returned?

Keep in mind the "search-oriented" approach that we see in Google, iOs, and Android UIs, EVERYTHING is searchable, you type in ONE BOX, and the search is executed across multiple facets.

You want your UI to be as efficient and economical as possible, so why deviate from what they are already familiar with?

Answer 5

How about something like this: take the probabilistic approach implied in Approach 1 (the more terms match, the better), and constrain it optionally by requiring certain terms to be present. This can avoid having to explain to the user what AND and OR are for.

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