pros and cons of multi search box vs one search box

Question

I have been asked to come up with a search mechanism for a database. The database stores details about electors.

Is a multiple search field interface better than a single search field interface? The single search can search across all the fields the multi box can.

Drawbacks of single: it can't differentiate between strings that could be a name or part of an address eg 'Woods' vs 'Woods avenue' but the user is not likely going to be searching for something so vague; they are likely to have a unique ID or combination of details eg 'Woods SW6 2LT'

here are the alternatives (state of the system: the user has run some search and the then cleared all the search fields for some reason)

What are the pros and cons of each approach? Are multiple boxes better than one?

Answer 1

Pros:

• A single box is, well, simpler. It also eats far less space on your UI, and only seeing one box to search in is far less daunting. Imagine opening Google and finding instead of the search bar, individual fields for Page Title, Description, Site, Date, etc. Yikes.

Cons:

• Ambiguity of search. If I want to search for Alan Smith, chances are a single box is fine because it's (probably) only going to be finding that in the Name & Address field. But what if I want everything with a New status? If I search New, I'm going to get all of those... but also everyone who lives in New York. And our valued customer Bob Newton. Maybe you can google-ify it with search hints - eg searching status: new, but that means...
• A "Simpler" interface might end up being harder to use with a steeper learning curve. The multi-box format makes searching for Status = New records really easy - there's a box labelled Status. Put New in it. Job done. But for a single-box approach with search hints, I have to learn a whole new syntax first. I have to dig out the documentation to discover how to only search in the Status field.

A compromise:

Why not both? A directory application I use has a "Quick Search" field at the top that searches all fields, and then separate individual-field searches below. I find it works quite well (I do not have any numbers to back up this claim, I didn't design it)

Answer 2

The beauty of a single search field is that it works like Google... You just type in all the keywords you care about and Google takes care of the rest for you.

However the devil is in the details. In order to make one field work, your backend search needs to search for each keyword (delimited by white space) across all columns of data (I'm assuming a SQL backend). While physically possible this often leads to un-optimal queries that are a bunch of OR conditions... E.g. Return all results where X is this OR this OR this OR this... Without lots of care you end up with what I'll call "bloated" results because it brings back matches that are not really relevant.

On the other hand, having separate column filters is more work for the user in having to mouse/tab between fields but this enables your backend query to run much faster and bring back much more precise results.

If you have a status column and you provide say a drop down with your valid status options then the user can easily filter to say just the "Active" items (and likewise you can set sensible defaults)

In this scenario the user typically sets 2-3 filters of their choosing to get the results they want. E.g. I only want people in the (Markham) region, that are (Active) status, with a name starting with (Th).

This typically helps the backend generate a super fast and specific query... Returning the small data set 10-15? possible matches to the UI almost instantaneously.