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

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.

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.

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 Ajax 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).

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 (Figure 1.61, “Delta”). You can also change the sort order dynamically.

Figure 1.61. Delta

ListSomething.com offers Live Search for classified ads (Figure 1.62, “ListSomething.com”).

Figure 1.62. ListSomething.com

Amazon's diamond search is a unique search interface, incorporating several “Slider”s to set such variables as shape, price, and number of carats (see Figure 1.48, “Amazon Diamond Search” in “Progress Indicator”). 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.

Skype's Skype-In service lets you choose a real-world phone number to be redirected to your Skype account. As you type some digits, you'll see Skype's list of numbers available to you.

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 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 Message” which 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 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.";
    }

The Assistive Search demo 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 here, and is analysed in the “Live Command-Line” examples.

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.

Live Search results can be shown in a “Data Grid”.

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

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

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.

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

You can look at “Live Search” as a kind of “Predictive Fetch” in which the pre-fetched results are made visible.

“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: