Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c02/h01/mnt/42598/domains/ on line 468

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c02/h01/mnt/42598/domains/ on line 483

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c02/h01/mnt/42598/domains/ on line 490

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c02/h01/mnt/42598/domains/ on line 526

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c02/h01/mnt/42598/domains/ on line 103

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c02/h01/mnt/42598/domains/ on line 21

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c02/h01/mnt/42598/domains/ on line 618
Pound Takes » Blog Archive » Field Notes: Live Search/Auto complete
Ideas on Engineering Breakthrough Applications

Field Notes: Live Search/Auto complete

What is it?
In the last few years, a modification to search on many websites and applications has become popular. As the user begins to enter search criteria, a list of possible results is “suggested” just below the input field. Those suggestions can be clicked on or selected with the keyboard arrows without requiring the user to type out their full term. This method is a shortcut for long search terms such as “Attack of the Killer Tomatoes!” and is especially helpful when the user is unsure of the full spelling of a term such as “perseverance.”

While real time suggestions have been standard issue on desktop software, it is relatively novel and new on websites due to network constraints and the previous implementation difficulties (those difficulties have been resolved by libraries such as JQuery). The first time I remember seeing this method used was when Google set up Google Suggest in their labs - it’s since been released to the Google home page and is now prevalent on most search engines under various names such as Search Assist and Live Search. I’ve also heard auto-complete and dynamic search used to describe this technique.

How it works
The idea behind live search is simple: with each keystroke in a search input, the software guesses, or suggests, what you are typing. The user is relieved from typing the full search term, and is only required to enter enough characters to reveal their term, at which point the user can arrow down or click on the search term.

When to use it?
Live search is a great tool for many, but not all, search situations. We typically recommend this method when the result set is available at a relatively low overhead. For example, if you are querying one table or an indexed or cached result set, the results will come quickly and without a major tax on the server. Conversely, if the input is meant to search multiple tables or a volatile source, then the result set may be slow, unpredictable and possibly too taxing on the server.

Limited results sets are the best candidates for live search. A clear and common example is a list of cities used for travel sites. The list is finite enough to inventory misspellings and aliases, but broad enough that the suggestions will add value to the user’s experience. If I am booking a trip to Saskatchewan, I might not be sure of the spelling, and it is doubtful that I will know the airport code. The suggestions that would appear after “sas” would reduce my task time enough to add value to the experience.

Live search is a natural fit for inputs where only full or partial titles will be used. For areas where boolean rules and multiple keywords will likely be used, the real time suggestions might return awkward results. The user expects to see the characters they are typing repeated in the real time results and this is not guaranteed when the user is typing in logic characters (”:”,”~”,”-”). See the result set below, where we’re searching for the mammal dolphin, but receiving only football results. If such queries are a high probability in your search fields then they might not be candidates for live search.

It should be noted that if your result set is extremely limited, say under a dozen, then the standard dropdown box will suffice and live search might be overkill.

The major drawback we’ve identified in implementing live search on our projects has been the deceptively simple nature of user and client expectations surrounding the results. As anyone who has programmed any robust search functionality knows, the engineering required to execute the result set anticipated by various users is not trivial. This seems to be magnified in live search due to the ultra-compressed timeframe in which the user expects to receive feedback from their entry. For example, on a pharmaceutical website, one user might be expecting Viagra, while other’s are expecting viatamins (a likely user misspelling) when they enter “via.” To further that example, vitamin C is a popular product, yet typing “vitamin” into a result set would return hundreds of other vitamins, possibly excluding vitamin C from the results all the way until the user had fully typed in “Vitamin C,” thus rendering the live search pointless in that case. These considerations should be accounted for when deciding to employ live search or to stick to more traditional search with results only show after the user submits a query.

Another drawback is the processing and bandwidth resources live search requires. While the result set may seem small in terms of size and processing requirements, search fields are often the most utilized function of a website, and therefore are often included in the header of websites, making them even more heavily utilized. On a mainstream production website, it is foreseeable to receive hundreds or thousands of searches per minute. Using a live search method can easily add support complexities and monopolize server resources.

And, of course, the live search results involve JavaScript and hide/show techniques. Adding such complexity across browsers and platforms is an invitation for bugs and additional troubleshooting time, and therefore comes at a cost. Those complexities can be reduced by the introduction of a tested JavaScript library (such as JQuery), but should be accounted for when budgeting time and schedule.

Design Considerations

  • Restrain results until the second, third or fourth character. The larger the dataset, the more characters you should use to suppress the suggestions. The reasons for doing this are twofold: a) you want to avoid totally irrelevant suggestions based on strings like “tr” and “st,” and b) you want to avoid huge result sets being sent across the network for similar strings.”
  • Identify common misspellings, aliases and relationships. For example, if the result set is a list of universities, make sure to associate acronyms (UF, UM, OSU) and common nicknames (Vandy, Navy).
  • Place the search box in a place where the suggestions will not interfere with other items on the page.
  • Think about the next step. Since not all live search selections go to a new page, think about where to put the mouse focus after a suggestion is selected such as the next form element.
  • It can be helpful to bold or highlight the matching characters in the suggestions. For example, if the user has entered “mus,” then the results might appear like this: Mustard and Hummus.
  • If the result sets are extremely large, live search may just return a count of results rather than suggestions. We’ve implemented a search of medical conditions that would constantly trim the number of results left as you typed. So, you may see a small 1,002 as you typed “canc” and see that number lower with each additional character until you came to a list that you felt was manageable. The user was getting a sneak peak into how large (or limited) their result set was going to be.
  • Design for network latency. If the process is too dependent on the suggestions, and they take too long to return, then the experience has been compromised. A visual cue to denote progress can be helpful as well. A very small and simple animation just to the right of the text field is common.
  • You can show more than just suggestions with the results. For example, Google shows the number of results that will be returned for each suggestion. You might display a category or object type (file, message, link) next to the suggestion as well.
  • Be aware of accessibility concerns. Consider providing an alternative, accessible means of search for browsers without javascript, as well as users with mobile devices. For example, submitting a search query in a browser with javascript disabled might take users to a traditional search results page.

Technical Considerations

  • The speed at which the results can be returned is highly dependent on your database size, layout and optimization techniques.
  • Caching common lists can protect processing resources.
  • For lists, results can be transferred once and filtered on the client side. Send the result data when the minimum character set is reached (such as three) and pair down the result set with JavaScript as more characters are added. This is not feasible when you are using advanced logic to guess the suggestions rather than pairing down a list. For example, “peac” might have different suggestions than “pea”.
  • The use of a javascript library, such as prototypejs or jQuery, can speed up client-side development, and also provides a baseline for cross-browser compatibility.

Tags: , , , , ,

3 Responses to “Field Notes: Live Search/Auto complete”

  1. by joe January 20th, 2009 at 12:27 am

    Excellent article on auto complete. Just what I was looking for. Nice website by the way….

  2. by Andover IT January 23rd, 2009 at 2:00 pm

    Great article. Am looking forward to seeing this being developed by the search engines such as Google as it is often useful to see alternatives to the search you had planned.

  3. by KrisBelucci June 2nd, 2009 at 8:22 am

    Hi, cool post. I have been wondering about this topic,so thanks for writing.

Leave a Reply