Live Search - Ajax Patterns

Live Search

From Ajax Patterns

Tags: Feedback Immediate Live Real-Time Search


Contents

In A Blink

Diagram - Halfway through a live search

ruby

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 favourite wholesaler's website and sees an empty search form, with an assortment of products underneath it and a message, "50,000+ items". First, she selects "shoes" from a dropdown and watches as the products below morph into a collection of shoes, and the message is now "8,000+ shoes". Then, she begins typing. As she types "C", she now sees all the shoes beginning with "C". This continues until the search field contains "curio", at which point only three products are shown below. One of those is "Curiously Costly", which is what Reta clicks on to successfully conclude the search.


Problem

How can users quickly search for an item?

Hai

Forces

  • Ajaxian applications often require a search capability. Users search for business objects, other users, websites.
  • Sometimes, the user is searching for a needle in a very large haystack. In the case of search engines, a hastack of over a billion items.
  • To help deal with the complexity, users should be free to experiment.


Solution

As the user refines their search query, continuously show all valid results. The search query is a combination of controls that let the user narrow down the collection of all items. It may be a straightforward text field, or a complex arrangement of Sliders, radiobuttons, and other controls. The results appear in a separate region and are continuously synchronised with the query that's been specified. The search concludes when a result is chosen.

There are several benefits of live search over the conventional style:

  • Browsing and search can be combined.
  • Search 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 more smooth - results are updated, but the input query is completely unaffected.

The most common form of live search right now closely mirrors traditional search. The user types into a free-text search field and results are frequently updated as the user types. So, searching for "catacylismic", the user will see results for "c", "ca", and so on. (With Submission Throttling 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 browsing is good for exploring all the items and stumbling across things you didn't know about. Live Search provides a way to combine the two. Some controls - such as selectors, radiobuttons, and Sliders - let the user specify an item from a small collection. If the search form is able to alter dynamically (see Live Form), you can support browsing through a hierarchical structure.

Imagine how a website search engine might achieve this. The initial control is just a free text box and a selector with ten categories - Arts, Tech, News, and so on. The user chooses News on the selector and a new selector appears - World, Busines, Science, etc. At any point, the user can change any selector. All the while, the results below are always updated to show a sampling of all 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.

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:

  • User changes a control, e.g. types a new character or clicks a radiobutton.
  • The entire input query - all of the input fields' settings - is sent in an XMLHttpRequest Call.
  • The server decides which - if any - results should be shown and returns the list.
  • The browser replaces the list of results with this new list.

In the above 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 does not show the actual results, but provides a hint about the results, such as how many results and what type of results. The benefits 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 (wls) and not so useful anyway. If the user's searching for "cataclysmic", do they really care about the results for "cat"? An alternative might be to require an Explicit Submission, but apply Predictive Fetch 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.


Decisions


How will you interpret incomplete text?

The user begins searching for "cataclysmic". Having typed as far as "cat", what do 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 options above, "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 they're looking for - a 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 really 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's probably enough to show without even trying to anticipate any further characters.


How much detail will be provided for results?

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 here would be to use Multi-Stage Download - get a quick summary immediately, then a few seconds later, if the user hasn't done anything, refine the results with a second query.


What will happen when there are too many results to show at once?

You can usually show only a fraction of results at once, typically up to 50 or 100 results. 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 to show no results at all, on the basis that the user should refine their search. This is not always the best idea, because there's 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 some way to prioritise results, perhaps against popularity or the user's personal history.

You could also consider using a Virtual Workspace to give the appearance of having loaded all results, and allow the user to navigate through them. The OpenRico Yahoo! Search Demo provides search results in this way. It's not a Live Search, but you could easily incorporate the approach to a Live Search.

A further possibility would be to place the results "on rotation". That is, run a Periodic Refresh to show an ever-changing collection of results. I've not seen this in an Ajaxian Live Search, but a slideshow-type navigation - rapidly rotating images - has been used in other domains to reduce information overload (for example, some TVs support channel-surfing with a collage of rapidly changing channels).


Real-World Examples


Delta Vacations

Delta Vacations has a hotel booking facility. After identifying a destination on the destination page, you can perform a Live Search for a hotel. For example, type "dis" in the Los Angeles page and you'll promptly see all the Disney hotels appear. You can also change the sort order dynamically.


Amazon Diamond Search

Amazon's diamond search is a unique search interface, incorporating several Sliders to set such variables as shape, price, and number of carats. 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, where the results themselves are not shown until an Explicit Submission takes place.


Ptable

Ptable uses a fat client approach to live search and displays current results in a different way. Because the entire potential result set (118) is generally in view, rather than offering additional text or a drop-down suggestion, all elements matching the query are darkened. As soon as only one result matches the text, its closeup pops into the key area. Rather than going to the server for these searches, the DOM is simply looped over, allowing the search feature to run without modification across 30 different language versions of the page.


Opportuno Jobsearch

Opportuno is a german jobseach engine. Its unique "Instant View" search interface is completely based on AJAX technology. For example, type "ajax" in the search box ("Wonach suchen Sie?") and the search results page is instantly updated. There is no search button. You can also change the sort order dynamically.

Code Examples

Delta Vacations

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

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

updateHotelList() will then call the server. In this case, the server offers an HTML-Generating Service which outputs the exact HTML for the results. If you visit [1], you can see the result is just a segment of HTML:

  <div id="H0" class="StandardHotel">
    <h2 class="FourStar">
      <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.";
  }



Related Patterns

Suggestion

Suggestion is similar to Live Search in that both involve performing a search to synchronise the display against a partially-complete input. However, they are not the same thing:

  • Suggestion is not just about search - you could use it to complete words as a user types. Here, the back-end algorithm involves search, but it's not the user's goal.
  • Even in the context of search, Suggestion aims to complete the query, while Live Search aims to fill the results. If the search says "ab", a Suggestion will give you potentially useful terms - "abdominals", "absolutely" - while a Live Search will give you all items matching "ab" or "ab...".

Progress Indicator

While waiting for results to load after some user input, you might show a Progress Indicator. Keep it fairly subtle, as it will appear and disappear frequently.

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.

One-Second Spotlight

One-Second Spotlight can be used to transition from older to newer results.

Submission Throttling

Instead of submitting upon each keypress, Live Searches often submits the input query at intervals, a form of Submission Throttling. In many cases, it makes sense to submit only after an idle period, so that the search term is exactly what the user was looking for, rather than a partially complete version.

Unique URLs

Different search queries should generally have Unique URLs associated with them.


Visual Metaphor

Live Search is about using filters to narrow down the entire space. Performing a Live Search is like using physical filters to extract something from a mixed substance.