Section 14.7. Live Search | Ajax Design Patterns

14.7. Live Search

Feedback, Immediate, Live, Real-Time, Search

Figure 14-21. Live Search

14.7.1. Goal Story

Browsing a trade magazine, Reta has just spotted the "Curiously Costly" line of shoes and declared them a "must-have" for the upcoming season. She heads over to her favorite wholesaler's web site and sees an empty search form with an assortment of products underneath it and the message, "50,000+ items." First, she selects "shoes" from a drop-down and watches as the products below morph into a collection of shoes; the message is now "8,000+ shoes." Then, she begins typing. As she types "C," she now sees all 500 shoes beginning with "C." This continues until the search field contains "Curio," at which point only three items remain. One of those is "Curiously Costly," which is what Reta clicks on to successfully conclude the search.

14.7.2. Problem

How can users quickly search for an item?

14.7.3. Forces

Ajax Apps often require a search capability. Users search for business objects, other users, web sites, and more.
Sometimes the user is searching for a needle in a very large haystack. In the case of search engines, a haystack of over a billion items.
To help deal with the complexity, users should be free to experiment.

14.7.4. Solution

As the user constructs and refines his search query, continuously show all valid results. The search query is a combination of controls that lets the user narrow down the collection of items. It may be a straightforward text field, or a complex arrangement of Sliders (see earlier in this chapter), radiobuttons, and other controls. The results appear in a separate region and are continuously synchronized with the query that's been specified. The search concludes when a result is chosen.

There are several benefits to using Live Search instead of the conventional style:

Browsing and searching can be combined.
Searching proceeds more quickly because no explicit submission is required. The results are ready almost immediately, so the user can experiment more easily.
There's no page reload, so the interaction feels smoother; results are updated, but the input query is completely unaffected.

The most common form of Live Search right now closely mirrors traditional searching. The user types into a free-text search field, and results are frequently updated as the user types. So, searching for "cataclysmic," the user will see results for "c," "ca," and so on. (With Submission Throttling (Chapter 10) in place, the sequence might skip a bit, so a fast typist would see results "c," "cata," etc.)

Search and browse have often been considered mutually exclusive on the Web, which is unfortunate because both have their benefits. Search is good for finding something you already know about, while browse is good for exploring all of the items and stumbling across things you didn't know about. Live Search provides a way to combine the two. Some controlssuch as selectors, radiobuttons, and Sliderslet the user choose an item from a small collection. If the search form can change dynamically (see Live Form later in this chapter), you can support browsing through a hierarchical structure.

Imagine how a web site search engine might achieve this. The initial control is just an empty text box and a selector with ten categoriesArts, Tech, News, and so on (Figure 14-22). The user chooses News on the selector and a new selector appearsWorld, Business, Science, etc. At any point, the user can change any selector. All the while, the results below are updating to show a sampling of results in the most specific category that's been specified. Furthermore, the text input is there all along, acting as an additional filter. So if you search at the top level, the interface degenerates into a standard live text search. But if you search while the selectors are set to a category, only the matching results from that category will be shown.

Figure 14-22. Live Search with Live Form

Live Search makes use of event handlers on the input controls, which listen for user activity and update the results. A typical sequence works like this:

The user changes a control; e.g., types a new character or clicks a radio button.
The entire input queryall of the input fields' settingsis transmitted to the server in an XMLHttpRequest Call.
The server decides whichif anyresults should be shown and returns the list.
The browser replaces the list of results with this new list.

In the preceding scenario, the XMLHttpRequest Call need not occur in direct response to the user input. Often, Submission Throttling is used to delay the response.

A weaker form of Live Search doesn't show the actual results, but hints at them, e.g., indicating how many results and what type of results. The benefits to this are that there are less processing, improved caching opportunities (because there's much less to store), and no space required for results while the search is occurring.

Live Search is not always desirable. Showing intermediate results, which happens when the search involves typing, can be distracting (http://looksgoodworkswell.blogspot.com/2005/12/distracting-or-narrowing-looking.html) and is not very useful anyway. If the user is searching for "cataclysmic," does she really care about the results for "cat"? An alternative might be to require an Explicit Submission (Chapter 10) but apply Predictive Fetch (Chapter 13) to keep pulling down results according to the user's current input. That way, the results will be ready as soon as the user clicks on the search button.

14.7.5. Decisions

14.7.5.1. How will you interpret incomplete text?

The user begins searching for "cataclysmic." Having typed as far as "cat," what will you show?

Matches for "cat," "catalogue," "cataclysmic," and anything else beginning with "cat"?
Matches for "tomcat," "delicate," scatter," and anything else containing cat.
Just matches for "cat".
A combination, with a few of each.

In the first two preceding options, "cat" is implicitly transformed to "cat*" and "*cat*", where "*" represents any character. For most searches, the "cat*" style is preferable because the user knows what she is looking fora user searching for "cataclysmic" has no need to search for "*aclys*"so inserting a wildcard at both ends merely clutters the interface and increases search cost.

Whether to use a wildcard at all is another matter. That is, should "cat" match just "cat," or also "cataclysmic"? There are benefits on both sides, which is why combining them is worth considering. It also comes down to how many results you generally expect. If there's only one or two results for "cat," then you might want to anticipate further typing. If there's a heap of results for "cat" alone, then there are probably enough to show that you don't need to anticipate any further characters.

14.7.5.2. How verbose will the results be?

As with regular search, you need to decide how much each candidate result will show. Because the results are sent frequently, you might need to limit results to just a basic summary. An interesting variation on this would be to use Multi-Stage Download get a quick summary immediately, then a few seconds later, if the user is inactive, refine the results with a second query.

14.7.5.3. What will happen when there are too many results?

You can usually show only a fraction of the results at oncetypically, up to 50 or 100 results and probably much less than that if bandwidth and server processing are critical constraints. However, there could be thousands of results. In the worst case, before the user has specified anything, there are no constraints and every item is a candidate. So you'll need to decide what happens when there are too many results to show.

One option is not to show any results at all, on the basis that the user should refine his search. This is not always the best idea, because you will have missed an opportunity to provide a little feedback and help the user explore. So you often want a way to provide a reduced list of matches. The search algorithm might have a way to prioritize results, perhaps based on popularity or the user's personal history.

You could also consider using a Virtual Workspace (Chapter 15) to give the appearance of having loaded all results and thus allow the user to navigate through them. The OpenRico Yahoo! Search Demo (http://openrico.org/yahooSearch.page) provides search results in this way. It's not a Live Search, but you could easily incorporate a Live Search into the approach.

A further possibility would be to place the results "on rotation"that is, run a Periodic Refresh (Chapter 10) to show an ever-changing collection of results. I haven't seen this in an Ajax Live Search, but a slideshow-type navigationrapidly rotating imageshas been used in other domains to reduce information overload (for example, some TVs support channel surfing with a collage of rapidly changing channels).

14.7.6. Real-World Examples

14.7.6.1. Delta Vacations

Delta Vacations has a hotel booking facility. After identifying a destination on the destination page (http://www.deltavacations.com/destinations.aspx), you can perform a Live Search for a hotel. For example, if you type "dis" in the Los Angeles page (http://www.deltavacations.com/destination.aspx?code=LOSANGELES), you'll promptly see all of the Disney hotels appear (Figure 14-23). You can also change the sort order dynamically.

Figure 14-23. Delta

14.7.6.2. ListSomething.com

ListSomething.com offers Live Search for classified ads (Figure 14-24).

Figure 14-24. ListSomething.com

14.7.6.3. Amazon Diamond Search

Amazon's Diamond Search (http://www.amazon.com/gp/gsl/search/finder/102-1689279-4344148?productGroupID=loose%5fdiamonds) is a unique search interface, incorporating several Sliders (see earlier in this chapter) to set such variables as shape, price, and number of carats (see Figure 14-5). Each time you alter a Slider, a message appears beside it showing the total number of results for the current search. Unfortunately, this is a weak variant of Live Search in which the results themselves are not shown until an Explicit Submission (Chapter 10) takes place.

14.7.6.4. Skype

Skype's Skype-In service (http://skype.com) lets you choose a real-world phone number that will redirect to your Skype account. As you type some digits, you'll see Skype's available numbers.

14.7.7. Code Example: Delta Vacations

14.7.7.1. Delta Vacations

The Delta Vacations search registers an updateHotelList event handler on each control that manages the Live Search: the text input, a radiobutton pair determining whether to show all hotels or just those matching the text input, and a selector for the sort order. For example, here's the static HTML or the text input:

   <input type="text"  onfocus="setChecked('FindByName')"   onkeyup="updateHotelList('hdnDestCode', 'HotelNameBox', 'SortOptions');" />

updateHotelList( ) will then call the server. In this case, the server offers an HTML Message that outputs the exact HTML for the results. If you visit http://www.deltavacations.com/ajax.aspx?d=LOSANGELES&n=dis&s=rating, you can see that the result is just a segment of HTML:

   <div  >     <h2 >       <a href="property.aspx?code=LAX0001&&dest=LOSANGELES">Disneyland Hotel</a>       </h2>       ...

The results are then morphed to show the HTML:

   var container = document.getElementById('HotelListView');   if (null == container) return;   if (http.responseText)   {     container.innerHTML = http.responseText;   }   else   {     container.innerHTML = "No hotels matched your search.";   }

14.7.7.2. Assistive Search demo

The Assistive Search demo (http://ajaxify.com/run/assistiveSearch) can be considered a weak form of Live Search because it shows which categories of results will be retrieved but not the results themselves. It does illustrate some of the concepts discussed in this section and is analyzed in the examples in Live Command-Line, later in this chapter.

14.7.8. Related Patterns

14.7.8.1. Progress Indicator

While waiting for results to load after a user inputs data, you might choose to show a Progress Indicator (see earlier). Keep it fairly subtle, though, as it will appear and disappear frequently.

14.7.8.2. Data Grid

Live Search results can be shown in a Data Grid (see earlier).

14.7.8.3. Virtual Workspace

Early in the Live Search, there are often more results than you can show at once. Consider presenting them in a Virtual Workspace (Chapter 15) to let the user explore all the results.

14.7.8.4. One-Second Spotlight

One-Second Spotlight (Chapter 16) can be used to transition from older to newer results.

14.7.8.5. Submission Throttling

Instead of submitting upon each keypress, Live Searches often submit the input query at intervalsa form of Submission Throttling (Chapter 10). In many cases, it makes sense to submit only after an idle period so that the search term is exactly what the user is looking for rather than an incomplete version.

14.7.8.6. Unique URLs

Different search queries should generally have Unique URLs (Chapter 17) associated with them.

14.7.8.7. Predictive Fetch

You can look at Live Search as a kind of Predictive Fetch (Chapter 13) in which the prefetched results are made visible.

14.7.8.8. Suggestion

Suggestion is similar to Live Search in that both involve performing a search to synchronize the display against an incomplete input. However, they differ in the following ways:

Suggestion is not just about searchyou can use it to complete words as a user types. The backend algorithm involves search but searching isn't the user's goal.
Even in the context of search, Suggestion aims to complete the query, whereas Live Search aims to fill the results. If the search says "ab," a Suggestion will give you potentially useful termse.g., "abdominals," "absolutely"while a Live Search will give you all items matching "ab" or "ab . . . ."