Single search box for different types of searched criteria

Question

I have a scenario where users can search for a particular hotel and add it to their private list. Up until now the search was performed on the hotel name, but now there is a request to also search hotels by ID. This is how the UI looks now:

To keep things simple, I was considering using the same searchbox and labeling it "Search by name or id", which would return the following results:

Now the thing is, in the above example if a user types in 26A5C they will normally get a list with results that match one if these cases:

1. Have the ID containing the 26A5C sequence
2. Have the "26A5C" string in the hotel name (E.g. "Bellisimo 26A5C Resort")

But if the user types in "26A5C Bella" then what would they expect to see? Would they expect to see:

1. All hotels with an ID starting with 26A5C and a name starting with "Bella"?
2. All hotels containing the "26A5C" and "Bella" strings in their name?
3. Both of the above (see next wireframe)

From a technical point of view it's harder for the development team to implement the single searchbox feature. It would be easier for them to implement two separate searchboxes with separate result lists: one for hotel IDs and one for hotel names. So the options I have now are the following:

1. Single searchbox for both hotel name and ID (harder to implement, better UX)
2. Two searchboxes: one for hotel ID and one for hotel name (easier to implement, cluttered UI)
3. Single searchbox with two radio controls for the user to pick the search type: hotel ID or name (less cleaner UI than #2 but same development time as #2, but an extra click for the user)

Given the situation described above, what would you think is the best approach? Are there any other options besides those I mentioned? Thanks for the help!

Answer 1

In my opinion, the obvious answer here from a UX perspective is that the box 'just works'.. no radio button, no double search field. As you stated, it then becomes a challenge of technical implementation.. a few notes on that.

I'm going to assume that one of your goals for this search is that its fast.

With a fast query, you can give the user results as they are typing. This visual feedback to the user should cut down on some of the ambiguity cases.

Search services that operate quickly precompute their results. There is a data structure called a 'trie' which basically precomputes 'If the user typed 'A' for the first character, give them these.. Aardvark Hotel, Adagio, Allawishes Underwater Hotel, etc'. Then as the user types the second charectar after the 'A', you search ONLY inside of the set which was already returned (since it contains all possible combinations of A followed by A, A followed by B, A followed by C, etc. Therefore, additional searches dont require an additional request to the server.

What I'm getting at, is that your interface should have access to a local subset of the data and allow to locally search through that data, OR have access to the entire dataset and do the searching entirely locally.

For a normal website, a server would periodically compute this file (or set of files). A user who accesses the page would dynamically load the file(s) and be ready to instantaneously show any result. As the user types more than 2 or 3 characters, the search for results would be done locally on that users computer, rather than on the server and having the user have to wait for the results.

ADDITIONAL NOTES:

Also keep in mind, that as soon as the user sees what they are looking for, they are going to stop typing and click it... so that partially makes your 'But if the user types in "26A5C Bella"' a non issue

you would have to 'index' each of the hotels both by their name, and id when you created the local search data structure

if this is a consumer facing service, PLEASE hide the ids in the result box UNLESS the user typed an id.. it will just look nicer.

as I subtly stated, traditionally you dont try to do a result lookup as the user is typing UNTIL they have typed more than 2 or 3 charecters.. this cuts down on the data being analyzed.

precomputing these data files is usually done by a 'cron' job on a server OR when each request for the file comes in, the server gets the file, checks when it was built, if it was built too long ago (last week for example), then you hand the user back the file existing file, kill the connection, and recompute the file and replace it with this new version so that its kept up to date.

Here is some info on tries.. that talk about performance.. your performance would be be based upon your data, and programming languages you guys use. If this looks technical, its not really, just remember that the concept is not different then when I search A you give me back this chunk of results, when I search B you give me back this other chunk of results. http://ejohn.org/blog/javascript-trie-performance-analysis/ http://en.wikipedia.org/wiki/Trie