1

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)

enter image description here

enter image description here

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

  • if they did a search in the single box for something crazy like 'Smith' and thousands of results were returned I expect they would use filters/advanced search to narrow the result set – colmcq May 18 '16 at 9:15
  • Thought of using unique IDs for each Elector? – DPS May 18 '16 at 9:17
  • there are unique IDs for each elector – colmcq May 18 '16 at 9:21
  • the question is whether multiple boxes or 1 is better – colmcq May 18 '16 at 9:50
  • updated question to clarify – colmcq May 18 '16 at 9:51
3

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)

  • the 'new' is a filter before or after search. I think a quick search followed by filters is good or access to an advanced search cool too – colmcq May 18 '16 at 11:11
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.