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?

5 Answers
5

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:

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.

I still think Approach 3 is straightforward for a programmer to code...it all seems cluttered up to me...why can't we just ask the user to give some inputs and we can take care of producing the relevant results?
–
johnbkMay 24 '12 at 3:20

1

But approach 3 is even more confusing. Are we searching for One and (Two or Three or Four) or for (One and Two) or Three or Four?
–
Marjan VenemaMay 24 '12 at 6:39

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.

Especially next to an input field 'required' may be interpreted as "I have to fill out this field" rather than "this term will be made a must-have in my search results", despite the check box and what not. At least that automatic connotation had me tripped up for a sec or two...
–
LouiseAug 28 '12 at 11:58

Would "Must be present in the results" be better?
–
Gene GolovchinskyAug 28 '12 at 13:47