Have you ever tried the “I’m Feeling Lucky” button on Google? The idea is, of course, that Google will take you directly to the result you want, rather than return a list of results. It’s a simple idea, and when it works, it seems like magic.
But most of the time we are not so lucky. Instead, we submit a query and review the results; only to find that they’re not quite what we were looking for. Occasionally, we review a further page or two of results, but in most cases it’s quicker just to enter a new query and try again. In fact, this pattern of behaviour is so common that techniques have been developed specifically to help us along this part of our information journey. In particular, three versions of as-you-type suggestions—auto-complete, auto-suggest, and instant results—subtly guide us in creating and reformulating queries.
5.2.1 Auto-complete
One of the key principles in human-computer interaction is recognition over recall: the notion that people are better at recognizing things they have previously experienced than they are at recalling them from memory. This explains why most of us can find our way around graphical operating systems such as Windows and OS/X, but when faced with a naked command line, we’re lost for words.
Auto-complete transforms a recall problem into one of recognition. As you type into the search box, it tries to predict your query based on the characters you have entered. Like a human interpreter mediating between two people speaking different languages, auto-complete facilitates the dialogue between user and search application. The UK’s National Rail website, for example, recalls the railway stations that match a handful of characters. We must simply recognize the one we want:
Auto-complete does its best to remain unobtrusive: we can still enter the query in full if we choose. But in selecting these completions we save time and keystrokes. Moreover, they help us avoid spelling mistakes: if we can’t recall the exact spelling of “Aberystwyth”, no problem—we just need to know it when we see it. This type of interaction is invaluable in mobile contexts, when accurate typing on small, handheld keyboards is more difficult. On smartphones and tablets we see it applied to all manner of applications, from text messaging to email:
Auto-complete makes the most sense when the choices are based on a controlled vocabulary, i.e. a finite list of items, such as a directory of names, locations, organisations, and so on. But what of situations where the choices are potentially unbounded? Or of situations where we’re not exactly sure what we’re looking for to start with? As we saw earlier, in exploratory search and other complex information seeking tasks there may be no such thing a single ‘right answer’. In this context, a different approach is needed.
5.2.2 Auto-suggest
There’s a thin line between auto-complete and auto-suggest: both offer varying degrees of support for query creation and reformulation, and the terms are used somewhat interchangeably by many people. But if we were to draw a precise distinction, it could be this: the purpose of auto-complete is to resolve a partial query, i.e. to search within a controlled vocabulary for items matching a given character string. By contrast, the purpose of auto-suggest is to search a virtually unbounded list for related keywords and phrases (which may or may not match the precise query string). While auto-complete helps us get an idea out of our head and into the search box, auto-suggest actually throws new ideas into the mix. In this respect, auto-suggest operates at a more conceptual level, offering choices where the relationship to the query may go beyond than simple string matching. Both techniques save keystrokes and help us avoid spelling mistakes, but auto-suggest can also help us construct a more useful query than we might otherwise have thought of on our own. Ebay, for example, provides a variety of different suggestions related to the query “guitar”:
Moreover, the same product categories that we saw earlier being used to provide scoped search can also be used to drive product suggestions. Home Depot, for example, provides a particularly extensive auto-suggest function, consisting of product categories, buying guides, project guides and more. Not only do these suggestions facilitate known-item search, they also support exploratory search behaviour, encouraging the user to discover new product ideas and specialist content. While the Home Depot example demonstrates what’s possible with auto-suggest, it’s worth noting that moving from a single to multiple lists of suggestions demands greater mental effort from users.
One unique asset that the major web search engines have at their disposal is access to vast quantities of user data, which they can mine to maximise the value of query suggestions. Google, for example, derives its suggestions both from the user’s individual search history and from the collective behaviour of many users. Yahoo takes a slightly different approach, leveraging its extensive network of web properties and resources to provide an auto-suggest function that features a secondary panel containing answers and rich content:
A further technique to optimise the value of query suggestions is to display them in the context of recent searches. One approach, which Safari utilises, is to simply present two adjacent groups: one for query suggestions and another for the browser’s search history:
5.2.3 Instant results
Auto-complete and auto-suggest are both valuable techniques to help us conceive and articulate more effective queries. They differ in approach, but share the principle that as-you-type suggestions provide a shortcut from query to search results. But in some cases it is possible to go even further than this. In some instances, auto-suggest doesn’t offer query reformulations at all, but instead offers actual results to the user. For example, if we type the characters “ip” into the search box at Apple.com, six items appear. However, if we select one of these, it bypasses the search results page entirely and takes us directly to a product-specific landing page. Rather than suggesting alternative queries, the search box provides “instant results” in the form of a set of matching “best bets” for products and resources:
We can see a similar principle in action in the search function of popular desktop operating systems. In Windows 7, for example, a keyword search invokes a panel of recommended results, grouped into popular categories. We can either select one directly to open it, or choose the “See more results” option to open a regular search results page:
Figure X: Instant results in Windows 7 desktop search
Of course, in desktop search and online retail the instant results experience can exploit the metadata of a managed collection to optimise the relevance of categories and results. On the web, by contrast, it is somewhat harder to pre-emptively match queries with results in this way. Nonetheless, Google provides its own type of “instant results”, which complement their auto-suggest function to provide a highly responsive search experience. Instead of presenting a static page of results after each query, Google Instant updates the search results in real time as each character is entered. If we don’t see the results we want, we can just keep typing and watch the results update.
In common with auto-complete and auto-suggest, instant results can save us time and help avoid spelling mistakes. But more importantly, by providing immediate feedback on our query, instant results can facilitate a more interactive dialogue between user and search application. Of course, it may not be the complete solution for expert users wishing to explore and understand highly complex information spaces, but for known-item search and other information retrieval tasks, it provides a clear benefit.
Summary
Although most of us are familiar with Google’s iconic “I’m Feeling Lucky” button, few of us use it: we know that search problems of any complexity require an iterative approach, punctuated by the creation and reformulation of queries. And in this endeavour, as-you-type suggestions have become invaluable. Auto-complete is better suited for known-item search and simple information retrieval tasks; auto-suggest works well for exploratory search and complex information seeking tasks; and instant results provide a direct channel from queries to answers.
- Use auto-complete to:
- Facilitate accurate and efficient data entry
- Select from a finite list of names or symbols
- Use auto-suggest to:
- Facilitate novel query reformulations
- Select from an open-ended list of terms or phrases
- Encourage exploratory search (with a degree of complexity and mental effort that is appropriate to the task)
- For further guidance on detailed interaction design for auto-complete and auto-suggest, see the Endeca UI Design Pattern Library (note that while this resource provides valuable guidance, it conflates the different use cases described above)
- Where appropriate, complement search suggestions with recent searches
- Use instant results to promote specific items or products
Good post. I don’t think I’ve ever uses the I’m Feeling Lucky button…
I’m having a hard time understanding the real difference between AutoComplete and AutoSuggest. Isn’t is just about what one feeds into it? In your eBay example, it’s just that eBay loaded queries from their query logs (so to speak) instead of a smaller set of data from their DB, say product names. The effect is the same, the tool is the same, the only difference is what suggestions one loads, no?
Plug: this is our AutoComplete (or AutoSuggest?) tool that people seem to be very happy with:
http://sematext.com/products/autocomplete/index.html
Oh, and similar thought about the Instant Results Safari example. Isn’t this also just a matter of A) what one loads into the backend to be used as suggestions, and B) what one chooses to do when a suggestion is chosen? (e.g. take the user directly to the item selected or use the selected item as a query)
Thanks.
Thanks for the great post, it gives many best-practices screenshots and interaction patterns to learn from.
We put up a free, open-source implementation of an AutoComplete for Solr at GitHub. See this blog post for more: http://www.cominvent.com/2012/01/25/super-flexible-autocomplete-with-solr/
I’d love to improve it with a pretty GUI as well, but that will come later
Sematext: Good question… I used to adopt a very strict definition of auto-complete, referring only to the extension of a query fragment by a candidate completion string (the bit in grey on Google Suggest). But I’ve noticed that most people use the term more broadly to refer to the kind of experiences you see above. So yes, the boundary is somewhat blurred, but I do think there are tangible differences (from a UX PoV) between the simple kind of tasks for which autocomplete is suited and the more open-ended type for which auto-suggest is suited.
Agree also about your observations about Instant results – that IMHO is a more clear cut case where the same framework could have been populated with suggested queries, but they chose instead to match against priducts (and link from those to product pages rather than SERPs).
Am I the only (cognitive psychologist) one bored by auto complete, auto suggest, and instant results in current search technology? Take auto complete: language cognition comes in chunks, phonological and semantic. Auto complete comes on word level, while additional syllable-based and morpheme-based chunks would be more natural auto-complete units of language. I have used this technology for years and it is – of course – better than the Google etc. experience. Take auto suggest: there is a world of useful things one can do with n-grams and semantic chunking. Search string based auto suggest is boring and limiting. And instant results is like trying to jump over a hundred useful ways of supporting thought completion in the false belief that ranking and ‘search resuls’ will always be the final solution to search problems.
Lars: Interesting … can you point to some examples of the kind of thing you’re talking about? I am very sympathetic to the idea of extending auto-suggest, although I’m curious to know whether what you’re alluding to is changing the content vs. changing the UX / design.
On a wider note, I don’t think anyone is suggesting that this type of interaction is *the* solution to all our information seeking behaviours … on the contrary, its usefulness is almost entirely context dependent IMHO (did you see my earlier post on this? https://isquared.wordpress.com/2010/09/29/the-dimensions-of-search-user-experience/)
“the false belief that ranking and ‘search resuls’ will always be the final solution to search problems” I think we’re on the same page here… it’s amazing how many projects I’ve worked on where “fixing the ranking” is seen as the primary (indeed, only) way to design an effective search experience. Sigh…. (for a longer soapbox rant on this topic, see this: https://isquared.wordpress.com/2011/10/11/findability-is-just-so-last-year/)
… for example: if you type ‘timel’ into a search box, it is clear that you have got a compound of time and some other word part. You could mean time-less, time-line, time-ly etc. Thus ‘less’, ‘line’, ‘ly’ would be suggestions for auto-completion. Google suggests ‘timeline’, ‘timline maker’, ‘timeline covers’, ‘timeline template’, highlighting the ‘ine’+ part.It would be more appropriate to stress ‘line’ here, and to give alternatives for compound completion first, before dishing up frequent search strings, because the whole suggestion is nonsense if you are looking for, say, ‘timeless design’. What Google gives you here is mere mind distraction, neither completion support, nor adequate suggestions, because they think in terms of search strings, not thought strings.
Lars, your comments about thought strings vs. search strings sound intriguing, but my own thought strings must be all tangled up because I don’t understand everything you’re saying very clearly. For example:
> It would be more appropriate to stress ‘line’ here
Stressing “line” (and not just “ine…” like Google does) is mostly about UX (and somewhat about having the linguistic knowledge that “line” here is a part of a “timeline” compound. Right?
Google must have this info. Why do you think they are not using this?
> give alternatives for compound completion first, before dishing up frequent
> search strings
Could you give an example of this, please?
Looking at Google’s suggestions for “timel” input I see “timeline” as the first suggestion. What would be a better first suggestion there?
> because the whole suggestion is nonsense if you are looking for, say,
> ‘timeless design’.
Right, but how can Google know you are searching for “timeless design” based on the partial input of “timel”? Google has to pick top N suggestions for any partial input and it must be that more people are searching for “timeline maker|cover|template” than “timeless design”, so I presume that is why Google is not suggesting “timeless design”. What am I missing in this part of your comment? 🙂
Also, a general comment on thought strings vs. search strings — but aren’t search strings, at least the popular ones we see in Google’s AC more or less our thought strings we all collectively enter into Google’s “brain” every day?
Thanks for your thought strings! 🙂
> Google must have this info. Why do you think they are not using this?
Unclear to me.
> Could you give an example of this, please?
> Looking at Google’s suggestions for “timel” input I see “timeline” as the first > suggestion. What would be a better first suggestion there?
Note that timeline here is a suggestion for autocomplete and a suggestion for non-auto-complete mode result page creation. Actually, all suggestions are also possible autocomplete options. But it is very unlikely that you want to autocomplete ‘timeline template’ after entering ‘timel’. Google is mixing up two things here: autocomplete suggestions and browsing suggestions. There are no real alternatives given for autocomplete. Even if ‘timeline’+ is the most popular search string, for all users not thinking about timelines it is a total (and multifold) distraction, not helping in autocompleting the word. It is even worse because sometimes Google gives different compound suggestions so one might be inclined to read on in the list. A two-step or ‘multidimensional’ parallel process would be more appropriate, avoiding information garbage.
> Right, but how can Google know you are searching for “timeless design” based > on the partial input of “timel”? Google has to pick top N suggestions for any
> partial input and it must be that more people are searching for “timeline
> maker|cover|template” than “timeless design”, so I presume that is why Google
> is not suggesting “timeless design”. What am I missing in this part of your
> comment?
As mentioned, autocomplete is about options for autocomplete. Search string suggestions is about having likely search strings that partially match the thought string. I think Google is mistaken here in thinking that you can have only one positive outcome here: the ‘final’ search string. If you understand autocomplete as a multistep process, the cost-benefit tradeoff calculation is totally different, as would be the interaction design. To me, Google’s effort looks shortsighted. Their statistical model is rather clear – and so are its limitations. Maybe they don’t understand that there business is not search, but language-thought-associative information, and information oftentimes does not need a search result page at all.
> Also, a general comment on thought strings vs. search strings — but aren’t
> search strings, at least the popular ones we see in Google’s AC more or less
> our thought strings we all collectively enter into Google’s “brain” every day?
The simple answer is: No. There are huge differences between thought ‘strings’ and search strings. Search users are trained to limit themselves in thought and focus on particular entities. But there would be much to say here …
🙂 Lars
Hey Lars do you know of any examples (or research prototypes) where we can see this kind of thing in action? I understand the principles, but I think it’s effectiveness really comes down to the precise execution (i.e. the detailed interaction design etc.)
BTW, there was a very similar discussion on the merits of incremental query construction vs default auto-suggest on smashing magazine (admittedly using lexical units rather than morphological or syllabic, but I think the principle is analogous):
http://www.smashingmagazine.com/2011/04/27/tap-ahead-design-pattern-mobile-auto-suggest-on-steroids/
Its a rather long read so I’ve taken the liberty of summaring my observations below…. In particular, the idea that google auto-suggest helps us to access the short head (i.e. the most common queries), whereas what you are proposing sounds like support for exploring the long tail:
“One key assumption is that the tap ahead approach saves time over the ‘one shot’ approach. And in the use case provided, that is clearly the case. But we shouldn’t generalise too much from a sample of one. Google (and others) are clearly able to predict queries with some accuracy and would probably argue that what they display by default is already optimised for maximum likelihood of immediate selection (across billions of users and uses cases).
So I think the difference is that tap ahead helps users to access the ‘long tail’ of queries in discrete, one word steps, whereas the default method relies the ‘short head’ as a predictor of user behaviour. In some domains, I think the short head will dominate, in others the converse will be true. But where the dividing line is, and what value there is on the long tail side, I think only Google knows (or someone with an awful lot of data and time to analyse it).”
> Hey Lars do you know of any examples (or research prototypes) where we
> can see this kind of thing in action?
Well, in my own experimental system (www.artificialmemory.net), which is more about knowledge management, however, I use compound splitting in auto-suggest for triple creation. It gets the highlighting right (at least). Have a look on http://www.artificialmemory.net/doc/compound_highlighting.png. There is no magic here, however. Autocomplete is actually but one component of a far wider area of importance: ‘word fields’. How can we move in non-sequential word (thought) fields and how are these to be related to multi-modal/media (non-word) fields. This has a semantic dimension. In my experience, for artificial thought completion (I prefer this term), meaning disambiguation is of utmost importance. During the last years, I have developed some solutions to this problem, but the ideas go far beyond search and would open another discussion. But let it me put it this way: since I have started developing and using my own thought and memory-completion system, I don’t use search that often anymore. It has become far less relevant. So I clearly see the potential for users, and the danger to search engines.
Obviously, Google got the message that ‘search results’ are not always the right answer to search:
http://online.wsj.com/article/SB10001424052702304459804577281842851136290.html?mod=WSJ_Tech_LEFTTopNews
Let’s see how good they are in realizing it. I think they are a bit late at the party. And I don’t think that they have a lot of experience in ‘semantic usability’.
🙂 Lars