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:

enter image description here

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:

enter image description here

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)

enter image description here

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!

  • 1
    I would be very surprised if it is significantly harder for the dev team to combine the results. Maybe it'll take a little longer to test that it's working, but not to actually build the query.
    – JonW
    Commented Oct 24, 2014 at 9:42
  • 1
    The user task is “find hotel”, not “find hotel by …”, so definitely single search box. IDs are usually fixed in length and unambiguous, unless they come from different issuers, which makes for fewer strange cases. In a short list of results, users need to see exact matches first (Bella), then initial matches (Bellagio), then other matches (Clarabella) and finally fuzzy matches (Bello). Hide excessive matches with a “More hotels” link or in a scrollable list view with ca. 7 items showing. It’s better to show all probable results, not just the one best match.
    – Crissov
    Commented Oct 24, 2014 at 9:58
  • How many people would use the search by Id
    – Mervin
    Commented Oct 24, 2014 at 10:57
  • @Crissov Actually the hotel IDs have an irregular format: they can vary from "5" or "12A7" to "34C4T" or "AMS45267". The results list would be scrollable indeed, with a max 10 items visible at a time. Commented Oct 24, 2014 at 13:10
  • @MervinJohnsingh The search by ID would be used by a considerable amount of users. Is the number of people searching by ID relevant to the way the feature would be implemented? Commented Oct 24, 2014 at 13:12

1 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.


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

  • So in the end we did decide to not compromise the UX and have the search box "just work", as you've said. Thanks for the thorough response regarding the implementation. Commented Nov 7, 2014 at 9:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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