Menu Search
Jump to the content X X
SmashingConf London Avatar

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf London, dedicated to all things web performance.

Mobile Auto-Suggest on Steroids: Tap-Ahead Design Pattern

In contrast to desktop Web search, auto-suggest on mobile devices is subject to two additional limitations: typing avoidance and slower bandwidth. The new patent-pending design pattern, Tap-Ahead, uses continuous refinement to create an intuitive, authentically mobile auto-suggest solution.

This helps dramatically reduce the amount of typing needed to enter queries, and utilizes slower mobile bandwidth in the most efficient manner. Using this novel design pattern, your customers can quickly access thousands of popular search term combinations by typing just a few initial characters.

Auto-Suggest: Mobile vs. Desktop Web Link

As John Ferrara wrote in his November 2010 UXMagazine article, “Psychic Search: a quick primer on search suggestions”1, today auto-suggest is practically ubiquitous in desktop Web search. In contrast to desktop Web, auto-suggest on mobile is (at least for now) fairly rare. The only mobile Website that currently implements auto-suggest is, and a handful of mobile auto-suggest implementations that currently exist come from native mobile apps built by leading online retailers like Amazon and

Mobile auto-suggest is non-trivial and quite expensive to implement, but even a large investment does not guarantee a good experience on the mobile device. In many cases, it is not enough to simply transfer the existing successful desktop Web implementation of the auto-suggest to mobile space. Why not? Our recent study revealed that mobile space is subject to two unique limitations that affect customers’ expectations and their use of the auto-suggest feature:

  • Typing Avoidance
    Typing on the mobile keyboard is much harder and more error prone than typing on the full-size desktop Web keyboard. Most people prefer to search using only a few characters — the fewer, the better.
  • Slower Bandwidth
    Mobile signal strength is unpredictable, as is the speed of the Internet connection. Yet the customer expectation is often shaped by their broadband desktop Web experience. Mobile auto-suggest interface must be optimized for slower bandwidth.

The Limitations of the Typical Mobile Auto-Suggest Flow Link

As I wrote in my UXmatters article, “Mobile Search: Turning Limitations into Opportunities”2, mobile phones are notoriously difficult to type on and their Internet connection is often spotty at best. This is especially true in the mobile context of use — that is when the customer is being jostled and bounced around in the moving taxi or metro. In a July 2009 blog post on Alertbox, Jakob Nielsen called the mobile experience “miserable” and reported, “Text entry is particularly slow and littered with typos, even on devices with dedicated mini-keyboards.”

Although 3G networks are finally becoming more commonplace, the average speeds US users experience on mobile devices are sometimes as low as one-quarter of the average speeds advertised, according to the Federal Communication Commission (FCC). This implies download speeds of 100-500 Kbps or lower, compared to the speeds of 1 to 1.5Mbs under ideal conditions.

As shown in Figure 1 below, the difficulty of typing coupled with frequently spotty download speeds of mobile context of use introduce some challenges into the typical auto-suggest process:

Figure 1. Multi-step auto-suggest search on Amazon iPhone app.

In the example above, the customer (let’s call her Anna) is looking for a book called “Harry Potter and The Chamber of Secrets”. To begin the search process, Anna types in the first two letters “ha”. Using these first letters of the query, the auto-suggest function performs a call to the keywords server, retrieving most frequently used keywords that begin with “ha”. The keywords server then quickly returns with a populated auto-suggest layer shown in 1-A, that helpfully suggests “Harry Potter”, along with nine other likely queries.

Although the “Harry Potter” does not completely match the query Anna is looking for, it gets her part of the way there and saves a lot of typing. Thus, Anna selects the system recommendation, causing her original query “ha” to be replaced by “Harry Potter”. The system then performs a search against the product server, returning up to 50 actual products along with product descriptions, thumbnails, and other pertinent information, as shown in 1-B.

With a fast Internet connection available on the desktop Web, the difference between hitting the keyword server and the products server is negligible — both come back almost as quickly. On the slower mobile connection, however, the difference is not only noticeable, but actually quite annoying because Anna never actually wanted to view “Harry Potter” products, but instead used this auto-suggest query as an interstitial search page — a jumping off point on the way from “ha” to “Harry Potter and The Chamber of Secrets”. The only reason why the interstitial search results page shown in 1-B was loaded was to avoid typing the full query on the mobile device.

After the products finally load, Anna again taps the search box to recall the keyboard and adds the letters “ch” to the query, creating the new query “Harry Potter ch”. The auto-suggest again goes to work, this time serving up as a suggestion what looks like the entire query Anna is actually looking for, “Harry Potter and The Chamber of Secr…” as shown in 1-C. Anna taps the suggestion, and the system finally serves up the second search results page, 1-D — the search results page she was originally looking for.

The first search results page is not just annoying and unnecessary — it distorts and pollutes an important asset, the frequently used queries database. The increased frequency with which the query “Harry Potter” is executed in fact helps push it to the top of the most frequently used query list again and again, creating a negative feedback loop in the frequently used queries server. The more something is selected as a jumping off page, the more the interstitial query (and it’s accompanied search results) appears to rise in popularity. Avoidance of typing in conjunction with a slower bandwidth available on mobile devices results in an overall sub-par experience.

Fortunately, there is a better way: Tap-Ahead Auto-Suggest design pattern that avoids the need to load the interstitial results page and all of the associated problems. I created Tap-Ahead based on my user research specifically to handle typing avoidance and slower bandwidth and optimize the search experience for the way customers use auto-suggest on mobile devices.

Tap-Ahead: A Novel Way of Resolving Typing Avoidance and Slower Bandwidth Link

Typing avoidance and slower bandwidth are two limitations inherent in mobile devices. Together, these two forces shape how people behave when they search. Tap-Ahead design pattern converts these mobile limitations into opportunities to create a better experience by minimizing the amount of typing and maximizing the use of the limited bandwidth.

The idea for the tap-ahead is simple: avoid serving the interstitial search results page by giving customers a way to narrow their search query using popular keywords without typing. To implement the additional narrow down functionality, I used the established iOS “more actions” icon — a blue circle with an arrow that was familiar to most iPhone users because of its prominence in the Contacts application, shown in Figure 2:

Figure 2. Blue circle with an arrow is used to indicate “more actions” in the iPhone Contacts app.

Of course, the same pattern can be applied on other platforms such as Android, Palm, BlackBerry and Windows 7 Mobile, by replacing the blue iOS arrow with the native platform’s standard “more actions” icon. Figure 3 shows what an implementation of the Tap-Ahead on Android might look like:

Figure 3: One Possible Andorid Tap-Ahead implementation.

Let me show you how this feature works in the context of auto-suggest. In this example, the customer (let’s call him Ben) is again looking for “Harry Potter and The Chamber of Secrets”, but in contrast to Anna who we followed in the example above, Ben is using the Tap-Ahead auto-suggest interface. Figure 4 shows how this search would proceed using the Tap-Ahead design pattern instead:

Figure 4: Auto-Suggest Search Process Optimized with Tap-Ahead.

To begin the search process, Ben also types in “ha” as shown in 4-A. Using the first two letters of the query, the auto-suggest function performs a call to the keywords server, retrieving 10 most frequently used keywords that begin with “ha”, among which is “Harry Potter”. Auto-suggestion “Harry Potter” does not completely match “Harry Potter and The Chamber of Secrets”, so instead of selecting the “Harry Potter” suggestion as Anna did in the example above, Ben hits the blue “narrow query” arrow.

This searches through the keyword server for popular queries that contain the keywords “Harry Potter”, serving up the next auto-suggest layer, which contains “Harry Potter and The Chamber of S…”, along with nine other suggestions, as shown in 4-B. This is the query Ben is looking for, so he taps this suggestion and the system serves up the search results page as shown in 4-C — the actual search results page Ben was originally seeking.

Allowing Ben to narrow down the initial auto-suggestion directly using the blue circle with an arrow offers several key user experience benefits:

  • Faster Search
    As we discussed above, hitting the product server to retrieve interstitial search results is expensive, slow and unnecessary. By tapping the blue circle with an arrow, Ben bypassed the useless interstitial search results page and executed his second query, “Harry Potter” against the keyword sever — a much faster process, which also returned useful search suggestions. Ben only had to hit the product server once, when he had the right search query.
  • Less Typing
    Ben did not need to type in “ch” to find the popular auto-suggestion that contained his second query, “Harry Potter and The Chamber of Secrets”. Although this is not always going to be the case, quickly serving up the popular keyword suggestions upfront, without forcing the customer to type anything, increases the chances of being able to select the desired query faster.
  • Seamless Flow
    Instead of jumping between the auto-suggest list and search results, the system maintained flow by serving pertinent keywords quickly and remaining in the auto-suggest mode until the entire desired query has been entered. This optimized user’s attention on task and maintained flow.
  • Flexibility
    At any point, the customer retained the ability to select the keyword suggestions in a traditional manner or type into the search box or exit the auto-suggest flow. The new mechanism of tapping the blue circle with an arrow to narrow down the search is merely an optional feature that provided additional functionality, allowing the customer to enter his desired query faster and easier.
  • Database Integrity
    Because the interstitial query “Harry Potter” was never actually executed against the product server, it did not “accidentally” count toward the popularity of this query. “Harry Potter and The Chamber of Secrets” was the only query executed against the product server and therefore the only one that counted as a legitimate hit, preserving the integrity of the keyword popularity database.

In our quick usability testing, we found the technique of tap-ahead to be both intuitive and useful. I theorized that this was in part because tap-ahead takes advantage of how people already use the auto-suggest functionality on the mobile device, so the entire process seemed natural and intuitive to our participants. Also, many people remarked that tap-ahead design pattern seemed somehow already familiar. This was because it did not require people to learn anything new: the design uses the established iOS “more actions” icon that most iPhone users already tap several times a day when they use the Contacts application.

Although tap-ahead is very useful when combined with the traditional auto-suggest database, its real power comes from redefining the way auto-suggest is used in the context of a mobile device.

Tap-Ahead: From One-Shot to Step-Wise Refinement Link

Typical auto-suggest on the desktop Web is structured around a one-shot approach: when the customer types in the query, the auto-suggest server attempts to bring back the one exact match to the query the customer is trying to type in. Clicking the auto-suggestion replaces the query the user was typing with the one the system recommended. It’s meant to be a one-shot deal: one goal, one query, one suggestion, and one set of results. While this is a decent initial model, in practice, we now know that this is not how people really search. As I describe in my book, “Designing Search: UX Strategies for Ecommerce Success” (Wiley, 2011), modern-day search is a multi-step process that takes place in multiple contexts, with the customer moving fluidly between keyword searching and browsing, multiple devices, locations, Web sites and social networks.

One-shot refinement is ill suited to this multi-faceted search paradigm, but after long practice, people on the desktop Web have learned to satisfice. It helps that the Internet connection is often blazingly fast and feedback in the form of suggestions and results is nearly immediate. Additionally on the desktop Web, it’s really not that difficult to type in the query again or delete some parts of the query auto-suggest has over-delivered using the mouse and keyboard after the interstitial search results page is loaded.

In contrast, on mobile, things are very different. Connection speeds are slower and more sporadic. Also, editing a query string on touch phones is quite a bit harder than doing it on the desktop: for example, on the iPhone, the user must tap and hold the finger on one of the query’s keywords, then scroll the tiny handles left and right to select just the right number of letters — not a trivial exercise while bouncing around in the moving vehicle or multi-tasking. Android, Palm and BlackBerry mobile devices require similarly awkward query editing acrobatics.

A more usable way of implementing auto-suggest on the mobile device is through step-wise refinement implemented through the Tap-Ahead interface. Instead of trying to guess the entire query the customer is trying to type in and offer the best one-shot replacement, Tap-Ahead design pattern guides the auto-suggest interface through the guessing process one word at a time — a much more natural, flexible and robust auto-suggest method, optimized to solve low bandwidth and fat finger issues people experience on mobile devices.

This is how the step-wise refinement Tap-Ahead interface works. Suppose our two customers, Anna and Ben, are both searching for “Harry Connick Jr.” Anna is using a one-shot auto-suggest flow for this query, shown in Figure 5. Ben, on the other hand, is using the new step-wise tap-ahead refinement alternative as shown in Figure 6:

Figure 5: Anna enters “Harry Connick Jr.” using the traditional one-shot auto-suggest flow.

Figure 6: Ben enters “Harry Connick” using a step-wise tap-ahead refinement design pattern.

When Anna types in “ha”, the interface suggests “harry potter”, “hard drive”, “halo reach”, “harry potter and the deathly” and a rather redundant “harry potter and the deathly…” as shown in Figure 5-A. On the other hand, Ben, who is using a step-wise refinement sees a much more humble top 10 one-word suggestions such as “harry”, “hard”, “halo”, “hair” and “hat” shown in Figure 6-A.

Because none of the query terms match the desired query “Harry Connick Jr.” exactly, Anna, who is using the traditional one-shot interface, is forced to keep typing the word “harry”. In contrast, Ben can tap the blue circle with an arrow next to the suggestion “harry”, filling in the entire keyword with one tap.

Once both customers enter the keyword “harry”, Anna again sees one-shot auto-suggestions which include “harry potter”, several variations of the “harry potter and the deathly…”, “harry potter dvd”, “harry potter wand” and many other “harry potter” variations, as shown in Figure 5-B. Unfortunately, the set does not include a “harry connick jr.” suggestion, so Anna is again forced to keep typing “c” in order to get the full one-shot auto-suggestion of “harry connick jr.”, shown in Figure 5-C.

In contrast, Ben receives only single keyword suggestions, so his second set of suggestions includes only a single instance of the keyword “potter”, which successfully covers all of the variations of the query “harry potter”, which had to be listed individually in Anna’s one-shot interface. Thus instead of 10 variations of the “harry potter” query, Ben’s single-word auto-suggestions include a rich set of 10 one-word complements of “harry”: “potter”, “connick”, “truman”, “smith”, “houdini”, “harrison”, “dent”, “david”, “eastwood” and “hendersons”, as shown in Figure 6-B. A one-tap selection selects “connick” which yields the query “harry connick” that is sufficiently close to the desired query “harry connick jr.”. Note that although in this case it was not needed, the addition of the word “jr.” can be easily accomplished with one more tap on the blue “narrow down” arrow.

To summarize this comparison, after both Anna and Ben typed in the initial “ha”, Ben was able to finish entering the entire query in only 2 easy key-strokes — by selecting two successive auto-suggestions, whereas Anna had to type in the additional “rry c” and select one auto-suggestion, a total of 6 keystrokes. In this quick demo task, tap-ahead interface provided a huge improvement, given how hard and error-prone typing has proven to be on the mobile device.

The advantage of the tap-ahead step-wise refinement interface is that the refinement keywords can be loaded asynchronously for each of the 10 auto-suggestions even while the customer is making the selection of the first keyword. Given that most queries are between two and three keywords long, and each successive auto-suggest layer offers 10 additional keyword suggestions, tap-ahead with step-wise refinement allows customers to reach between 100 (10 * 10) and 1,000 (10 * 10 * 10) of the top keywords through typing only a few initial characters. Tap-ahead allows the mobile auto-suggest interface to maintain flow and increase speed and responsiveness on tiny screens that is simply not possible to currently achieve with the traditional one-shot auto-suggestion interface.

In Conclusion Link

I want to close out with this quote from Google, the company that invented the original auto-suggest design pattern, which clearly inspired my tap-ahead design:

“At Google, we often think that speed is the forgotten ‘killer application’ — the ingredient that can differentiate winners from the rest. We know that the faster we deliver results, the more useful people find our service.”

— Matt Brittin, Managing Director, UK & Ireland Operations, Google

I hope that you find the Tap-Ahead design pattern useful in improving the speed and responsiveness of your own auto-suggest mobile interface and that Tap-Ahead contributes to further experimentation and evolution of search design patterns. For more mobile search design ideas, check out my book, “Designing Search: UX Strategies for Ecommerce Success” currently available for pre-order from Wiley and

References Link

You might be interested in the following related articles:

(il) (vf)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17

↑ Back to top Tweet itShare on Facebook

Greg is a UX strategist for Fortune 500 firms. His 4th book, The $1 Prototype and the new Lean Mobile UX blog can be found at

  1. 1

    A strong article and a perfect case study for the importance of user interaction as the foundation of good design. I am excited about applications where a step back was taken to evaluate the process at each point, rather than just jumping to the final destination.

  2. 2

    The only problem I see with this is that at first glance, I assumed that the arrow icon would do the search instantly, where as simply clicking on the suggestion would place the text into the input box.

    Perhaps i’m different since i’m not a regular user of an iPhone, but certainly on a browser if you click the suggestion it usually goes into the search box and an arrow usually denotes a call to action to perform the search.

    I’m happy to be proven wrong, since you said you’ve conducted “user research” in order to create this.

    But safe to say my first impressions are that the icon should be clicked to actually perform the search and i’d become quickly confused and annoyed when clicking the suggestion performed the search instead. At the very least it would be a learning curve.

    • 3

      Chris Brandhorst

      April 27, 2011 6:00 am

      On the iPhone, the interaction is just opposite of what you describe. On that device, the little blue arrow denotes something along the lines of “more of this”, “give me details”, etc. Touching the actual item in the list takes care of actually selecting the item (in this case: searching for that text).

      Given that, using the blue arrow to dive into the possible autocompletions makes perfect sense imo.

      Seems like a great idea to me.

      • 4

        I also thought that the blue arrow would go to the search results. You can interpret search results also as ‘more details’ and in that way the opposite makes also sense. And I have an iPhone…

        Maybe another icon would be more obvious?

        • 5

          What about using “tokens” (a pill-shaped box around the word) to denote that “these strings are forming your query”? That seems to work great in keyword-based interfaces like Tumblr, Mac OS apps, and There’s a few apps that use this that are not well refined, like Evernote. Clearly the details matter tremendously.

          A token-type representation might help users grasp that their query is being built incrementally.

      • 7

        Even as an iPhone user, I would have thought the same thing as Rob. I wouldn’t know at first whether I wanted to hit the blue circle or tap the words, nor whether they even do different things. With no indication as to what will happen when I tap the circle, I would be left to trial and error. I might figure it out eventually or I might just learn to type out my full query or use the interstitial searching method.

    • 8

      I had the same thoughts, although on browsers clicking the “auto-completed” phrase still normally searches for it.

      I think you’d need an arrow pointing up, or a plus symbol, or something that clearly indicates the phrase next to it will be “moved” into the search box above.

      • 9

        In terms of browsers I was merely thinking of when the browser has remembered the data you entered previously.

        Obviously custom auto complete scripts all vary, (non educated) users never have any idea when its the browser or a custom script, unfortunately that means that there’s no consistency.

        Personally, as said, I would have expected it to work the other way, for others, this is the most logical way for it to work.

        At the very least i’d say the biggest thing to click should cause the least amount of work, since it’s easy to accidentally click on it. For that reason alone I think the larger suggestion should simply replace the text in the input, rather than load another page, then you can always press the submit if you wanted to search directly for it.

    • 10

      This is easily enough fixed by just replacing the arrow icon with something more appropriate such as a button with 3 dots in it [ … ] :-)

  3. 11

    That’s a nice idea, would love to see it implemented. Very long description and rationale for a fairly straightforward solution though. Could’ve maybe have been summarized to something more like “add a button to each inline search result to use it as a query” ;)

    In the iOS case btw, wouldn’t it make more sense to use something like a plus button (and maybe a nice little transition where the string moves to the search field?) instead of the arrow, which is typically used to “dig”, i.e. open a new sub-view for a specific list item, which is not how it’s used here.

    This is btw very similar to how predictive texting was done in the days of button phones (I hear there are still some around). There the suggestions were only one word though. Pick up for example a SonyEricsson with 12 key pad and T9 and start writing ‘Ha’. A box appears with a list like “Harry, Harris, Hare”. Navigate with the joystick down to “Hare” and type “b” and you’ll get “Harebrained” (assuming that’s in the dictionary ofcourse).

  4. 12

    cancel bubble

    April 27, 2011 6:18 am

    “The new patent-pending design pattern,”

    What does this mean for someone who wants to use this pattern?

    “In our quick usability testing, we found the technique of tap-ahead to be both intuitive and useful.”

    Is this actually implemented in functioning code or did you just test on flat jpgs? Did you test more than Harry Potter/Conick.

  5. 13

    The idea is neat, but not thought out very well.
    I would have thought that the blue arrow actually shows the search results, too and instinctively tapped on the word to autocomplete. Since the arrow indicates an action. And the word indicates a word. Its just more logically related to auto completion.

    Also, I would completely get rid of the blue buttons. It just confuses users, as we see now (just read the posts above). Leave the interface as it is. Just copy the word, a user tapped on into the textbox on top. Leave the search action where it belongs to: the blue button in the lower right corner of the keyboard, labeled “go”. And everything is fine.
    If a user taps on an item and realizes that nothing happens but to copy the text to the top box, then the logically next action one will make to execute his search is hitting the “go” button. There you go. Everythings fine.

    This way, you would copy the autocompletion from desktop computers in a perfect way. If I type there and select an item, it just copies to my textbox. No form is submitted, no action taken. I don’t understand why they aren’t using this common pattern right now on mobile devices. And there would have been nothing to patent, too.

    • 14

      Ay definitely agree the best solution is just to avoid the go apart all together, it prevents the extra load when mis-tapping the one above or below as well. There’s no need for all this extra jiggery pokery.

    • 15

      Christopher Fahey

      May 1, 2011 5:23 am

      I thought the same thing, too. Desktop lookahead permits users to select lookahead items without executing the search.

      The problem, however, is that iPhone has already established the convention, for several years and millions of users, that choosing the lookahead executes the search. This obstacle — momentum and familiarity — might very well be surmountable, however. For one thing, there are plenty of search interfaces on iPhone where there is no lookahead at all, and where the Go button is the only method of executing the search. Which is to say, hitting “Go” isn’t unfamiliar to users.

      It’d be worth testing to see if users select the lookahead suggestions but get confused or frustrated that the search didn’t immediately happen… and then to see if the users figure out to just use the Go button.

      Greg, great analysis, and great comments, too. Hardcore hands-on IxD FTW.

  6. 16


    April 27, 2011 7:31 am

    How i miss t9 on my cellphone, talking about speedtyping.

  7. 17

    Mike Jongbloet

    April 27, 2011 7:50 am

    I think the author needs to respond to some of the good comments made.

    Its a great solution to cut out users performing extra steps, but as many have mentioned needs to be better thought out.

    You talk about the solution being tested, could we see more detailed results.

    With regards to the article, I found I only read about six lines, most of it was over-explained. Detailing user testing and results would have been a better use of space. This article could do with the “remove half the content, and remove half of it again” rule!

    Conclusion: Good idea, needs more UX thought, not a great write up

    • 18

      I thought the write-up was good overall. The next step is testing on a prototype. Those details are hard to express, and have to be experienced to be refined properly.

  8. 19

    Greg Nudelman

    April 27, 2011 9:52 am

    Wow, thanks everyone for your great comments – this is certainly a tough audience to please! :-)

    Let me respond to some of the common themes I saw in the comments above:

    > “How did you do your UX testing?”
    Five participants, all iPhone owners for 3-14 months, ages 20-35, 3 males/2 females. Tested using a picture only prototype of Tap-Ahead (using the screenshots from the article) vs. live Amazon iPhone app. To avoid recency bias, 2 of the participants started with the original Amazon auto-completion interface, and 3 with the Tap-Ahead screenshots. There were two tasks described in the article:
    a) “Find Harry Potter and the Chamber of Secrets” products.
    b) “Find Harry Connick Jr.” products.
    All of the participants preferred the new Tap-ahead interface and many stated that they “wanted this functionality on my iPhone right now” and that “it made my search easier” and “there is less typing” and that it’s “very convenient”. Most people usually find this information boring to read, so I did not include it.

    > ”you need to use a “go”, +, ^, #, $, %, etc.”
    Please feel free to try this out with a different button if you like that better. However, you should be aware that Apple Human Interface Guidelines call out this pattern specifically, as it is used in the iOS Contacts application. The Blue icon with a white “greater than” sign means “more actions”.

    > “What does ‘Patent Pending’ mean for someone who wants to use this pattern?”
    It means we should get together and talk about licensing. Please visit to get in touch with me.

    > ” I would have thought that the blue arrow actually shows the search results, too and instinctively tapped on the word to autocomplete”
    This is interesting, as there are multiple forces in play:
    a) Embracing the Existing Learned Interaction: the Tap-Ahead works exactly the same as auto-completion works currently. There is nothing new to learn, just a new button to play with. If you disregard the blue button, the feature works the “old” way.
    b) Embracing the Existing Mental Model: in the cases where the existing mental model is strong, any new feature has to completely *blow away* the old ways to justify re-learning. In this case, tapping “Harry” gives you products with the keyword “Harry” in them. This is perfectly in keeping with the current mental model of the auto-suggest mode.
    c) Larger Primary button: the primary action is still “give me products with the word ‘Harry’ in them”, so tapping “Harry” is the primary, larger button. The “Narrow Down/More Actions” button is the smaller, secondary action, which, if missed, does not jeopardize the use of the interface. If people never find the secondary button, the interface remains completely usable (in fact, it’s used that way currently).
    d) Avoiding “Endless Narrow”: as I describe in my book, “Designing Search”, when the primary call to action (tapping “Harry”) narrows down more, people end up narrowing *endlessly* until they get zero results or run out of patience. This is confusing. Tap-Ahead avoids this confusion by making the “Narrow Down” secondary, optional action (blue arrow).
    e) Embracing the Standards: as I already mentioned, Tap-Ahead is the standard approach per Apple HIG.

    > “needs to be better thought out”/“It just confuses users”
    I am sure some people will be confused by any new functionality. I did not find that to be the case with Tap-Ahead because it does not *require* learning any new interactions. In fact the traditional smartphone tap-ahead implementation works exactly as before – there is simply a new button added to enhance convenience and fit better with how people already search. Observing people using auto-complete “in the wild” on Bart and while multi-tasking was the inspiration for Tap-Ahead.

    > “remove half the content, and remove half of it again”
    That is always a very good guideline. By necessity, design articles are aimed at a diverse audience. Some readers of the Smashing Magazine audience are experts and was able to grok the topic instantly – I am very impressed, and gratified so many people found the article useful and though provoking. Obviously, there is a lot more to be said and learned on the topic, as your comments show.

    Great comments everyone – thank you again!

    • 20

      I don’t really have much to say in response to all of that, you’ve clearly taken on board what was said, maybe there is no right answer, certainly alot of design and usability is open to interpretation.

      But i’d just like to take the time to say thanks alot for the detailed reply and reading the comments, it’s eternally frustrating when people put alot of effort into an article but don’t follow up the discussion afterwards, it kind of defeats the point. I’m sure you’ll agree that having a tough audience is one of the best kinds of audience you can have, much more effective than “thanks alot, +1”

      For what it’s worth I disagree with the people criticising your write up, I thought it was really good, you get alot of laymen on SM and I wish some of the stuff that I don’t understand was written up in this way. Although I do understand how frustrating it can be to read this kind of article when you already consider yourself an expert :D You can’t please everyone I suppose. Use of bullet points and strong opening paragraphs under sub headings to outline your point simply before repeating yourself in more detail is usually a good approach to take :)

  9. 21

    Swype on Android saves all that tap tapping. It is really fast when you turn off the help features.

  10. 22

    ‘patent pending’ – ha! People like you really scare me.
    So you sit down for a few hours or days and refine a process that was invented a long time ago. In my opinion this is just one of several variations of the auto-completion pattern everybody knows. And i guess that a few websites out there are already using exactly this or a very similar variation. It should be hard for you to prove that you are really the very first smartass who came up with that idea.
    I think that it is really cool that people like you are trying out new things and are looking deeper into the matter to find out how things work best. And I think that it is very good to share such things with a community. You probably have to admit that you are dependent on the design community yourself.

  11. 23

    Greg Nudelman

    April 27, 2011 2:52 pm

    Thank you, Rob — I appreciate it!
    Tobi — I stand on the shoulders of giants! As I said in my conclusion that Google’s original auto-suggest design pattern “clearly inspired my tap-ahead design” and expressed hope that Tap-Ahead “contributes to further experimentation and evolution of search design patterns”. This whole topic of exploration was inspired by Luke Wroblewski’s comment about the iPhone Contacts app at Design4Mobile conference where I had the priviledge to present last year. I’m sure there are many perfectly splendid auto-suggest implementations out there. If you come up with something good, I want to encourage you to apply for a patent at It’s not that hard actually… I have 3 granted patents so far, and would like to get to 20 in my lifetime. How about you?

    • 24

      A question on that – my understanding is that the mechanics (the code) for how you implement that idea is patentable (implementation), but not necessarily the concept of tap-ahead query building (which itself, in my opinion, builds on other ideas from the desktop).

      US Patent law is anachronistic, and seems more out of touch every day with the new marketplace of ideas and software.

      To the haters in the thread: it seems that his very approach of sharing (in great detail) the behavior of this tap-ahead pattern reinforces this point (implementation is patentable, the concept isn’t). Thoughts?

  12. 25

    Patent pending? Not interested at all.

    (And invalid anyhow in Europe. Thanks God!)

  13. 26


  14. 27

    In general I am opposed to the practice of software patents in the us. How can a small freelancer like me, with a bunch of simple ideas, be sure to not violate somebody else’s patent – beeing sued as soon as my litte company grows a bit more? From that perspective I can understand your patent-eagerness – you are just frightened and consequently applying for a patent for each of your ideas.
    If patents like your pending one would have been around a thousand years ago, you would not be able to bind you shoelaces without asking somebody for legal permission. Especially in this fast growing business like software development 20 years of validity for a patent is way to long in my opinion. Thankfully I am living and working in Europe, where we don’t have those kind of trivial patents yet.

  15. 28

    I’ll have to jump on board and say “Patent pending?”.
    Seriously a patent on a searchresult pattern? Next thing you know we’ll be seeing patents on how people mow their lawn …

    Gtfo seriously

    Apart from that this is a great and interesting article, but as it is patented it renders itself kind of useless doesn’t it? I’d actually get the impression this was posted with the intention of someone copying it so you could go ahead and rip them off.

  16. 29

    It seems to me that if google had patented the type ahead concept, you, Greg, would not be able to stand so firmly, ‘on the shoulders of Giants’, as you put it.

  17. 30

    I agree with John about the standing on the shoulders of giants thing. The big idea is the suggestions which isn’t new. The only thing you are doing is formatting the results. So to patent this is more like standing on the shoulders of giants and kicking them in the head.

  18. 31

    Paul Sprangers

    April 28, 2011 6:41 am

    Great idea. This should have always been possible in any search query. I wished for it to be available many times. Typing “Lor” for example and already seeing “Lord of the Rings” in the results and tapping it just to go to the results page. The flow you first described has probably already cost me about half an hour.

  19. 32

    Douglas Bonneville

    April 28, 2011 2:12 pm

    Let’s not make this a thread about patents, or birth certificates (long or short form). Moving on…

    I’d use tap-ahead today if I had it. Period.

    Number one place for usefulness = App Store on iPhone.

    Great article.

    • 33

      No, it is exactly a thread about software patents, if he’s claiming that like in the first paragraph. If he’s claiming that AT ALL! Software patents are the grave of the IT industry, what Bill Gates also said. However some people (including Microsoft) think, they should digg it.

      You cannot patent thoughts, you cannot patent genetics. Patents are for inventors, not for philosophers and not for manipulators. And every software patent is a restrictive abuse of the law; because in opposite to inventions, for generic implementions, there is no alternative possible.

      Thanks God Europe prohibites software patents, so once those stupid of you people in the US managed to totally freeze your IT industry, we invite the rest of you to come and start up in Europe.

      • 34

        Douglas Bonneville

        May 17, 2011 10:37 am

        Patent or no patent, the idea is pretty good, but this article still isn’t about patents :)

  20. 35

    I’ve been Struggling with this just the other day.
    My preffered solution would be as simple as this:

    currently If you touch a suggestion it will: select + search.

    I would opt for:
    touch the suggestion will: fill the complete suggestion into the search box.
    The filter will be changed (narrowed).

    If the user wants to start the search she can press [search]. this button must be added behind the search box, also the text ‘GO’ should be changed into ‘search’.

  21. 36

    Christopher Fahey

    May 1, 2011 5:29 am

    Can you call it a “pattern” if it is patented?

    “Patterns” can be freely used by others. “Patents” cannot.

    • 37

      Greg Nudelman

      May 1, 2011 1:00 pm

      Hi Christopher,

      With all due respect, I disagree – auto-suggest itself is a design pattern (as called out by Peter Morville and many others) yet Google holds the patent to it. I for one, don’t see where the conflict comes in. Apple has multiple mobile phone patents, yet spawned the entire smartphone industry. And we all know what happened to Nokia.

  22. 38

    Nice Post
    Thanks for sharing

  23. 39

    Tony Russell-Rose

    July 19, 2011 10:02 am

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

  24. 40

    patent-pending = douche bag.


  25. 41

    Luca Candela

    March 4, 2013 5:45 pm

    This pattern is already applied (very elegantly) in the UI of the Playstation 3 store. Also, the Android stock keyboard applies the same pattern: selecting one of the options fills in the word and lets you keep searching. I argue you don’t need to add a button to every suggestion (ham-fisted) but you can simply change the behavior of search where tapping one item fills in the text field and only a touch on “search” triggers the actual search.


↑ Back to top