Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

We have tens of thousands of authors in the database and there are sometimes over 100 books published by a single author. Each specific type of book is uniquely identified by ISBN.

I want to create a single search box (currently there are several) in which the user can start entering either the book name or the author name or the isbn. The goal is to select a specific ISBN, from which book name and author names follow. Note that there are different formats for the same work, so ISBNs will differ depending on the book format, etc. The page will show all of the three selected values somewhere, but ISBN will be considered an authoritative key. A user would enter an Author's name if they do not remember the exact name of the book.

I am using an http://jqueryui.com/autocomplete/ widget which can trigger search on any minimum number of characters that the user has typed. Right now the threshold is 3, but some book names (albeit few) have only two characters in them, and so do some authors (I know, weird). The search results are backed by a web service that ends up querying the database. I have a lot of flexibility in terms of how the web service should function. For example, if the user has entered fewer than 3 characters, I can perform exact match only. If the user has typed 3 or more, I can match on anything that starts with those characters. If the user has typed 7 or more characters, then I can search for anything that contains them. I could even employ something based on the Levenshtein distance in the future, since the database provides this functionality.

Using the Autocomplete widget I can also format rows that come back as a table, so I can show Author, Book name, ISBN and other relevant info on the same line.

My biggest question is - how to present the results back to the user most optimally? What if I type a string and it matches both part of the isbn and the book name? What if it matches both the author name and the book name? I suppose, if the search input is all numeric (or has numbers and dashes), then I can first treat it as isbn and bring those results at the top. What if the user typed "Aristotle" - are they searching for books written by Aristotle or about Aristotle - e.g. author name or book name?

I suppose I could compute results in all three buckets and then present the smallest bucket first, or have some rules that decide which bucket should be presented first as a function of three numbers. I could try to visually separate the three buckets with something like an http://jqueryui.com/accordion/ widget with a table inside of each of its three sections. Or I could lump things all together. I could let the user do a more advanced search where they get to toggle three check-boxes. They could also specify the minimum length after which I should start performing a wildcard search anywhere in the middle of a string and not just the beginning.

However, some who understand UX opine that preferences are a cop-out. http://gettingreal.37signals.com/ch06_Avoid_Preferences.php

I can see their point.

My question is a bit vague. I want to provide the best user experience for the users who are searching for a book. Google and Amazon and others make it seam so easy. I want to be able to offer the same ease of use.

Any suggestions? Any questions?

share|improve this question
    
Is this question about the autocomplete, or about the final results of the search? –  Andrew Leach Oct 4 '13 at 7:16
    
@Andrew Leach, about the entire process, I suppose. If the auto-complete widget allows me to do what I want, then great! Otherwise, I will need to implement something else. Does this make sense? I am not sure I answered your question. –  Leonid Oct 4 '13 at 16:00
    
Google has years of experience and thrown tons of resources at this problem (if not exactly the problem you're facing, something similar). I would study how google does it, really dig into it and try to figure out why they do it the way they do it. –  obelia Oct 4 '13 at 21:16

4 Answers 4

This possibly sounds like a good use case for categorised autocomplete - http://jqueryui.com/autocomplete/#categories

A single search box that splits the result into logical grouping when presented back to the user.

mockup

download bmml source – Wireframes created with Balsamiq Mockups

Hope this helps.

share|improve this answer
    
This does help. I do not know how I missed this. The only trick is that at the end of the day I would be selecting an ISBN (and author and book name would follow from that), except that I need to show all three columns in the autocomplete. I think I can do that with customization, and the category names could be: "Match by ISBN", "Match by Author", "Match by Book Name" or something like that. –  Leonid Oct 4 '13 at 15:44

Firstly a key part of the magic behind Google search (and I expect Amazon) is that it balances a number of "signals" in conjunction with text entered.

Today Google’s algorithms rely on more than 200 unique signals or “clues” that make it possible to guess what you might really be looking for... http://www.google.com/intl/en_us/insidesearch/howsearchworks/algorithms.html

i.e. If you could tell some of the below

  • where is the user
  • what have they searched for / looked at previously
  • other products have they bought / used
  • what have they conversed about in email or I.M.
  • what is topical/'trending' in their interest group
  • what is their age
  • what is their local time
  • where have they travelled to / from
  • education level

then "Gar" will be far more lightly to mean "Garfield" (comics) for user A, while User B would almost certainly be interested in "Garth Brooks" (autobiography)

Gathering and analysing this data may be daunting. But I would expect a few key signals to be (A) what is trendy in their location (B) what user has viewed (C) what user has bought before.


Secondly "Spotify" has a good sectioned search example similar to @Whitingx described. A few refinements offered below (but please ignore alignment and mixed visuals in this sketch):

mockup

download bmml source – Wireframes created with Balsamiq Mockups

share|improve this answer

Not a direct answer, but I find myself curious, why are you reducing the number of boxes down to one? With three boxes you have the ability for the user to self-select a search criteria up front (author, title, ISBN). No need for them to set a preference, and a way for them to search based on the criteria they are using mentally. Multiple boxes provide results specific to the user's search viewpoint. If I am looking for a book by author I don't need to see results by ISBN.

If you're space saving then I can understand going through through the exercise, but providing three different types of predictive search data in one box seems like creating technical complexity (and increased cognitive load) in an effort to make things visually simpler. The single box isn't making the process any less complex, but shifting where the complexity occurs.

share|improve this answer
    
Zak, currently I have an Author search box and a title search box. When the user finds and selects the author, I make another AJAX request and pop up a selectable table with a few dozen books or so. Then the user clicks on the title and that gets populated as well. The problem is with keeping the state and the dependency between the author and the title straight. With ISBN it will be even harder. If the user starts to change the title when the author is already selected - what does this mean? At the end the goal is to select the ISBN, not the author, so the author box creates interm. state. –  Leonid Oct 4 '13 at 15:37
    
Also part of it is that I am new to web development, and so I try to keep things simple to avoid wiring dozens of events. I would feel much more at ease doing something complicated in a desktop Winform C# form, but not so much in HTML/JS. I will go that route if I have to, but simplicity has a strong appeal to me. –  Leonid Oct 4 '13 at 15:40

If you can't predict it, let the user choose. This is what filters are for.

If the user types "Wheel of time" and you only find 14 results, all of them in book titles, show only the results. But if the user types "Aristotle" and you have X works by Aristotle and YYY works about him, show them all, in whatever sequence you return your search result (e.g. for each result, determine a score of how frequently it gets clicked when the user sees it on SERP and use this as a score), it will mix both books on and by Aristotle. Additionally, add a filter on the side which says "Title containing Aristotle" and "Written by Aristotle". A user who needs both (who knows, maybe he is a student who has to write a homework on Aristotle and needs both the original works and sources talking about him?) will ignore the filters and be happy with the results. A user who needs only one of them will look around, notice the filters and use them to get the subset of results he actually needed.

In the best case, you will have to implement other filters beside this one. Users always want to cull unwanted results, especially in large databases. For books, you can set a language filter (most people don't understand ancient Greek, but a few will only be interested in reading Aristotle in original and won't want to wade through tons of translations), hard/soft cover, and others, depending on what your use cases are. But for your current problem, the found in author or found in title filter will be sufficient.

The autocomplete is a more difficult matter, I think Whitingx' suggestion covers it well. Still, I would suggest implementing the filter beside the autocomplete. You will only show the top few results in the autocomplete, and the user will hit enter when they don't contain what he wanted.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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