The very first ‘Search-as-you-type’ control I saw was the in-page searches of browsers. The way words would start highlighting the moment you keyed in the n th letter of the word, was something I found very convenient, but didn’t think of its utilities or mechanism. Then I saw the same technique used for searching through tags and scripts on Userscripts.org (it’s been replaced by the traditional search mechanism now), and found it really cool … again.⌘

Ever since then, I’ve preferred using the constantly updating search results list to a normal “type-in, press Enter” approach to searches. On the web, they’re just fancy forms that don’t really submit much information as much as pass query strings to server pages.⌘

At the operating system level, the search I fell in love with was first Quicksilver’s, then Spotlight’s (not so much in Tiger, but Leopard’s version kicks butt), followed by Google’s Desktop — which was a little CPU intensive because of all the extra junk it would add, but the fast searches were good. Vista’s Instant Search leaves an unpleasant taste in the mouth. I don’t know if its the inefficient indexing or general CPU usage, but Spotlight gives me faster results (much) on the same configuration. One reason might be multiple search queries being fired with every keystroke, which just sounds like bad engineering if it’s the real deal. Otherwise, Vista’s memory management and dangerous/unstable concept of services might be the main culprit. Whatever be the case, it is testament to the inconvenience this type of search can cause if the programming behind it is not correct.⌘

The biggest drawback of traditional searching is that it doesn’t augment the fact that the reason for a ‘search’ is to save time. By increasing the time taken to show results, you are taking the impetus in the wrong direction. The complexity of implementing a search-as-you-type controller keeps developers from putting it to practice. The immediate hurdles seem to be how to trigger the search (number of characters entered, time paused after last keystroke), how to optimise for speed (cancelling incomplete searches, caching results from previous searches) and if one wants to be really fancy, an algorithm which learns search usage patterns (related searches for entered keyword, treating keywords as tags, statistics from previous searches).⌘

I firmly believe the traditional search should be done away with on sites and pages that don’t have a revenue stream tied to these search ‘pages’ (like Google ads for search), for the sake of usability and speed. We have enough tools at our disposal to implement them efficiently, and the beauty of the web being no CPU intensive or ad-hoc memory usage concerns need to be dealt with, makes it less of an optimisers nightmare.⌘

NOTE: I am dealing only with the client side search implementation optimisation — what the user sees and uses. Optimisation for faster searches at the server end and algorithms which serve the results are not my scope.⌘