BlogmyQuery – BMQ

One of the best patterns for browsing a small collection of featured products is the carousel. Unfortunately, many mobile app implementations do not offer an engaging or satisfying carousel experience and are not effective at driving conversions.

In this article, we’ll use the analogy of a real-world amusement park carousel to explain what makes for an authentically mobile user experience, and we’ll give you the design, the complete source code and a downloadable mini-app, which you can use today to add an enjoyable and effective carousel to your own app on phones and tablets.

How It Works

The carousel is fairly simple. The customer is able to view several images of products across a row, and they can swipe horizontally across the row to navigate to the next set of products. An arrow indicating the direction of the carousel’s movement is usually provided as a clue to how to interact with it. Optionally, the next set of products in the queue may be partially hidden, creating what we call the “teaser,� indicating that more content will be visible by swiping.

Example

One excellent example of this pattern is the Amazon app’s home screen.

The carousel on the home screen of Amazon’s app is excellent. Larger preview.

This implementation of the carousel uses the teaser method to hint at the required interaction, showing only a small tantalizing glimpse of the naked CAT5E Ethernet cable, which is (and I have this from most reliable sources) completely irresistible to Amazon’s more impressionable customers, who can’t help but swipe across to see more of the naked cable and get to more of the content.

When And Where To Use It

The carousel is a fantastic pattern to show off featured items and relevant new arrivals. For example, new items matching the customer’s last search in their local area would be a sure winner.

In fact, consider using a carousel any time you have a small set of products (8 to 20 items) that are easily recognizable from just their picture. Augmenting the mostly visual content with a small amount of overlaid text is also sometimes effective. For example, in the screenshot below of the Pulse app on a 7-inch Android tablet, the carousel’s visual content is augmented with a semi-transparent dark-gray overlay, which provides the date and name of the comic. Without this overlay, the thumbnails of the carousel, especially in the first row, could be easily misinterpreted as belonging to a single comic.

The visual carousel content with semi-transparent overlay helps with comprehension in the Pulse app. Larger preview.

I am a huge fan of semi-transparent layers in mobile design. This example is particularly effective because the overlay on the thumbnails is semi-transparent and thus does not interfere with viewing the thumbnails, all the while augmenting the carousel experience in a way that is both visually appealing and informative. (Well, it does interfere just a bit, but it keeps interference down to a minimum while making best use of the small screen space.) The example also demonstrates that a carousel is an exceptionally great pattern for the large swiping gestures that small and large tablets invite.

Why Use It?

The carousel is an attractive and still fairly underused control for presenting visual information. It takes full advantage of the multi-touch gesture of swiping available on a mobile device. The carousel is easy and intuitive to operate and takes full advantage of the compressed real estate on mobile devices, where few words are needed to support the content.

Other Applications

One of the best features of a carousel is that it works well for a wide variety of device sizes and screen resolutions. This includes the ever-tricky horizontal orientation, for which the carousel works even better than in the vertical orientation.

The carousel adjusts to various screen sizes, and it works even better in a horizontal orientation. Pictured here is Amazon’s app. Larger preview.

Whereas the usefulness of traditional search results is severely hindered by the lack of vertical space, a well-designed carousel shines by showing off even more inventory.

Also noteworthy is the presence of the “See all� link, which points to the featured products.

The “More like this� link in this carousel navigates to a list of search results. Larger preview.

A “More� link is an excellent idea if your carousel has a small subset of items (8 to 20) that fails to meet the customer’s desires but piques their interest. In this case, the entire carousel control serves as advertising of sorts, enticing the customer to explore the relevant area of Amazon’s massive inventory.

Caution

As with any pattern, many implementations of the carousel do not feel quite right. One instance is NewEgg’s “Shell shocker� carousel:

NewEgg’s carousel has a few issues. Larger preview.

Some recommendations based on the UX problems in NewEgg’s implementation might help.

Make the Scrolling Smooth

To begin with, NewEgg’s carousel is structured more like the iTunes cover flow feature on iOS, with a large central element and two partial elements on the periphery of either side.

The cover flow screen in iTunes on iOS emphasizes the central element. Larger preview.

Like Amazon’s carousel, NewEgg’s can be swiped faster to advance more quickly through the list of products. However, NewEgg’s carousel moves very jerkily because of the structure of the central element, making it hard to see the intermediate states while scrolling — a major disadvantage. Seeing the two peripheral elements change is particularly hard — things hop all over the place, instead of smoothly swimming by the way they do in Amazon’s app. Higher-end and traditional carousels accelerate and decelerate smoothly and provide a pleasant, mellow, smooth ride. A carousel should be a high-end visual viewing experience that induces calm in the user, not stress. All parts of the control, including transitions, should behave accordingly and work together smoothly.

Indicate the Scrolling Direction

NewEgg’s carousel appears to be scrollable in both the left and right directions, causing a confusion: Is this carousel meant to represent a circle? Have I seen everything already, or do I need to keep scrolling? Amazon uses Android 4.0’s standard “blue parallax� visual treatment to signal the end of the line, a much better approach.

Amazon uses Android 4.0’s standard “blue parallax� to signal the boundaries of the carousel ride. Larger preview.

Just as a real carousel has papier-mâché horses that point you unambiguously in the right direction (you wouldn’t sit backwards on a horse now, would you?), so must your own carousel show which way the ride goes.

End the Ride Quickly

Good carousel implementations indicate the end of the list with the same parallax treatment seen at the beginning, and they present only 8 to 20 items, after which the ride is over and the customer can get off the carousel. Most importantly, the customer needs to exit the ride with the feeling of still wanting more. By contrast, NewEgg’s carousel seems to go on forever, so the customer does not get off until they feel bored (or, more likely given the jerky transitions, weak in the stomach). A much better approach would be to accompany the last element in the carousel with an obvious built-in “More like this� link, as shown below.

Show a “More like this� tile at the end of the carousel. Larger preview.

A “More like this� link can be used to jump into search results, which are more efficient for scanning large quantities of data and which are more likely to be relevant because of the sheer volume of items. Think of the “More� link as a premium combo ticket that grants admission to all of the remaining delights at the amusement park, conveniently presented after the cheap introductory carousel ride is over. Kind of puts a different spin on the entire carousel pattern, doesn’t it?

Make Sure Your Horses Look Amazing

No matter how smooth the ride is or how far or how fast the carousel goes, the best carousels have the best-looking horses, period. Make sure your horses (i.e. thumbnails) tell the story you want your audience to be told. For example, Amazon’s thumbnails are much better looking than NewEgg’s, although sometimes even the e-commerce giant screws up the ride, dropping thumbnails entirely:

Amazon’s carousel sometimes misses thumbnails. Large preview.

It goes without saying that ghost horses make for a terrible ride, even on Halloween (unless you’re the Headless Horseman). Which brings up my next point: some products are just not that visual, making them poor candidates for inclusion in a carousel. A classic example from my first book, Designing Search: UX Strategies for Ecommerce Success (Wiley 2011), is coffee — Peet’s Coffee to be exact. Even though Berkeley, California-based Peet’s makes some of the world’s most divine premium coffee, all of the thumbnails are identical pictures of a generic coffee bag and some spilled beans.

Some thumbnails, like these coffee bags from Peet’s, are not good candidates for the carousel pattern. Large preview.

Carousels are way more fun when the horses are all different; likewise, these generic bean-bag thumbnails are not good candidates for inclusion in a carousel pattern. A much more interesting horse would have been a close-up photo of a bean variety, or a map of a coffee-growing region, or a Tufte-style diagram of coffee taste attributes such as acidity, earthiness and body.

Even for products that have good thumbnails, presenting enough information can be a challenge. Including the right text in the individual tile is especially important for information scent; this could include key specifications such as processor speed, hard drive capacity and so on for the kind of technical gadgets sold by NewEgg. Picking an image resolution that can handle the amount of detail you are trying to show is also key. For example, can you tell what the item below is by looking at the small thumbnail and truncated description?

A small thumbnail and overly short description lead to “pogo-sticking.� Large preview.

Only by drilling down into the item do we see that it’s actually a screwdriver set. A larger thumbnail and better description would have helped a great deal and reduced the “pogo-sticking� (i.e. the frustrating navigation back and forth between carousel control and details page), which ruins the entire ride.

Having to pogo-stick between the carousel and details page ruins the ride. Large preview.

If the picture tells only half the story and you have to include a great deal of text, then you might find yourself having to increase the size of the individual element to the point that the carousel is no longer the best choice of presentation. For such items, think twice about whether you even really need a carousel, and whether a simple vertical list (more akin to a themed roller coaster) would make for a better experience.

Code

Carousel code can be fairly straightforward. One way to implement an ultra-simple demo using Java is shown below. Plugging cute pictures of puppies into the carousel, you should end up with a mini-app that looks something like this:

Mini-app with a puppy carousel. Large preview.

First, we define how many items to show, and compute the width of the carousel item based on the screen’s width. (You may need to use more sophisticated code that computes a dynamic INTIAL_ITEMS_COUNT if you’d like to accommodate longer carousels for tablet devices.)

/**
* Define the number of items visible when the carousel is first shown.
*/
private static final float INITIAL_ITEMS_COUNT = 3.5F;

// Compute the width of a carousel item based on the screen width and number of initial items.
final DisplayMetrics displayMetrics = new DisplayMetrics();
getWindowManager().getDefaultDisplay().getMetrics(displayMetrics);
final int imageWidth = (int) (displayMetrics.widthPixels / INITIAL_ITEMS_COUNT);

Next, for the purposes of this demo, we will create a static array of pictures. In a real app, this list would come from a database, of course.

// Get the array of puppy resources
final TypedArray puppyResourcesTypedArray = getResources().obtainTypedArray(R.array.puppies_array);

Then, we simply populate the carousel with items in the array and display it by overriding the onPostCreate() function. While onPostCreate() is mostly intended for framework use (according to the documentation), we can use it for this simple demo to simplify things a bit.

// Populate the carousel with items
ImageView imageItem;
for (int i = 0 ; i < puppyResourcesTypedArray.length() ; ++i) {
// Create new ImageView
imageItem = new ImageView(this);

// Set the shadow background
imageItem.setBackgroundResource(R.drawable.shadow);

// Set the image view resource
imageItem.setImageResource(puppyResourcesTypedArray.getResourceId(i, -1));

// Set the size of the image view to the previously computed value
imageItem.setLayoutParams(new LinearLayout.LayoutParams(imageWidth, imageWidth));

/// Add image view to the carousel container
mCarouselContainer.addView(imageItem);
}

This code is provided free of charge and distributed under the GNU General Public License v3. See the README_LICENSE file for details. Download the complete source code for the app.

Try It Out

If you want to see how the carousel app runs, the completed puppy carousel mini-app is available for you to download and try out. To install it, I recommend using an app installer (I use the one made by FunTrigger, which you can get free from the Play market).

Here’s how it works. Connect your Android device to your computer. You should see the Android file-transfer window open automatically. Download the APK source file (download the entire package), and place it in the “App Installer� directory (you may have to create it).

Place the APK file in Android’s file-transfer window. Large preview.

Now you will be able to launch the app installer on your device, navigate to the right directory, and tap the icon for the APK file that you want to install.

Use the app launcher to install the app. Large preview.

After a few customary Android disclaimers, the app will be installed in the normal apps area on your device, and you can launch it from there.

Conclusion

The carousel pattern is a microcosm of mobile design: deceptively simple. It is also a somewhat new Android pattern, and pitfalls abound. Nevertheless, if you take the time to get it right, the carousel is a fantastic pattern for showing off featured items and relevant new arrivals, as well any items that are highly visual. It dovetails perfectly with the local context by showing new items that match the customer’s last search in their local area. Finally, with the right implementation of the carousel, you will be supporting touch gestures on today’s Android devices to the fullest extent, fitting more products on the screen and making them accessible with a natural swiping gesture.

When designing your carousel control, think of it as you would its real-world namesake, the carnival ride. Make sure your horses look amazing; indicate the scrolling direction; make the scrolling smooth; and end the ride quickly, providing an exit to more of your inventory. We’ve provided you with the Java code and a demo implementation of the carousel pattern, so now you have no excuse not to try it!

(al)

© Greg Nudelman for Smashing Magazine, 2013.

Despite a great deal of mobile innovation, many creators of financial apps still copy their interface patterns from the desktop Web, even though these patterns are not as well suited to the mobile space. Small screens, custom controls, divided attention and fat fingers demand different thinking when designing for mobile.

I previously covered mobile wallet UX considerations in my article “Ultimate Guide to Designing NFC Mobile Apps You Won’t be Ashamed Of.� In this article, we will look specifically at simple mobile transfers of funds from checking to savings accounts, taking what works on the Web and converting it into authentically mobile flows using simple, effective design patterns. Similar analyses and design strategies can be applied to many other areas that involve complex forms, such as mobile e-commerce checkout and social network registration.

We will not name any companies in this article. That is deliberate. If you are looking for company bashing, you won’t find it here. But if you want to know how to make mobile banking work, read on.

Let’s begin with the basic building block: selecting an account. It can be accomplished in two primary ways: via a “picker� (called “spinner� in Android) and via a dedicated selection page (also called “table view�).

Picker/Spinner

For system interactions, many app and mobile website designers start by looking at the desktop Web interface pattern: a form with drop-down menus. Here is a common pattern for me-to-me transfers (i.e. transfers between two of your own accounts, such as checking and savings):

Typical me-to-me transfer via Web form.

The drop-down menu works reasonably well on the desktop Web, assuming the customer has between 1 and about 20 or 30 accounts. Each account can be listed in the drop-down menu by its full name, along with the account balance:

Selecting an account via the Web form’s select control.

How does this translate to mobile? Not very well. Blindly copying the desktop Web is a knee-jerk reaction, and it turns out that it’s mostly unsuccessful, resulting in a subpar experience. Here is why. Instead of the 20 or 30 selections that can be displayed in the drop-down menu, the iPhone’s standard picker control shows only 3 full and 2 partial choices:

Selecting an account via iOS’ picker control.

In Android 4.0 (the latest public Android version, named Ice Cream Sandwich), the situation is slightly better. Instead of the picker, the Android OS uses the spinner overlay, which shows 8 options. Unfortunately, the formatting options are quite limited, and the text area in the overlay is about 20% narrower than the main screen because the spinner is not using the full width of the device. This leads to confusing double and triple wrapping of text and numbers:

Selecting an account via Android’s spinner control.

Interestingly, some online banks use this pattern to display a list of accounts. However, by necessity (and to avoid the confusion of wrapping and truncation on older and smaller low-end devices), they use short codes for account names, such as CHK, SAV and CC1. These abbreviations work reasonably well for text banking, where the short-and-sweet mental model (“C U L8R�) reigns supreme. However, code abbreviations are far from the slick world-class UI elements that consumers have come to expect from their smartphones. Rather, they smack of “dim phones,� BlackBerrys, DOS and enterprise software. Having to remember codes to do mobile banking is a far cry from the experience of playing Angry Birds or shopping on Amazon or Gilt. To create a better experience on mobile, we need another design pattern: a dedicated selection page.

Dedicated Selection Page

A slicker and more usable mobile design pattern for listing accounts than pickers and spinners would be a dedicated selection page (also called “table view�) in which 10 or more account options could be listed comfortably. As Apple’s iOS developer guidelines state, “Consider using a table view, instead of a picker, if you need to display a very large number of values. This is because the greater height of a table view makes scrolling faster.�

This is how it looks wireframed using the agile, lightweight, sticky-note methodology (see the “References� at the end of this article):

Selecting an account via a dedicated selection page (wireframe).

The advantages of using a dedicated selection page over a picker or spinner include the following:

• Any font and branding you like;
• A platform-independent experience;
• Use the entire width of the page;
• Text wraps as needed, so multiple device profiles can use the page comfortably;
• Display 10 or more options at a time, with comfortable scrolling.

The bottom line is that, with a dedicated selection page, you can easily display the account’s full name and balance.

How could this pattern be used with a form? One popular pattern is a form with dedicated selection pages. Unfortunately, this often creates very long flows.

Form With Dedicated Selection Pages

The idea behind this pattern is simple: copy the standard desktop Web form but use dedicated selection pages instead of pickers or spinners.

Using this mobile design pattern, our me-to-me transfer flow would look like this:

1. Blank form;
2. Dedicated page to select the “From� account;
3. Back to the form (with the “From� field now filled in);
4. Dedicated page to select the “To� account;
5. Back to the form (with both the “To� and “From� fields now filled in);
6. Fill in the amount, etc., and hit “Continue�;
7. Verification page.

Here is the flow wireframed using the agile lightweight sticky-note methodology:

Me-to-me transfer via a form with dedicated selection pages (wireframe).

While this pattern works, it makes the flow quite long: seven pages. Could it be shortened? Absolutely. One excellent mobile-first pattern is the dedicated wizard flow.

Dedicated Wizard Flow

This is an extreme adaptation of the desktop Web form. This pattern works extremely well for short forms because it dispenses with desktop forms entirely, using a dedicated page for each attribute of the form.

Using this pattern, our me-to-me transfer flow would look like this:

1. Dedicated page to select the “From� account;
2. Dedicated page to select the “To� account;
3. Dedicated page to enter the amount, with a numeric keyboard;
4. Verification page.

And here is the flow using the agile methodology:

Me-to-me transfer via a dedicated wizard flow (wireframe).

This pattern works very well for short forms, and it is a great example of Luke Wroblewski’s mobile-first design thinking. The entire flow is accomplished in only four steps. Note that a verification page (allowing the customer to review the entire transaction before tapping the final “Transfer� button) is recommended with this pattern. Note also the use of the breadcrumb pattern, which shows the customer which step of the workflow they are on and how many steps remain. The breadcrumb enhances this design pattern nicely.

Are we done? Should you create a dedicated wizard for every flow on your mobile banking website? Not so fast.

In mobile, nothing comes for free. That includes the dedicated wizard flow, which completely breaks down in longer forms. The basic idea is to have a dedicated page for each element of the form. But if the form has five or more elements, then the flow starts to get too long. Another issue is the inability of this pattern to distinguish between optional elements (such as “Memo�) and required elements (such as “Amount�). With this pattern, each element gets its own entry page with the appropriate keyboard and is likely to be treated as “required�. Even if the customer understands that they don’t need to enter anything, each element requires the customer to at least look at the page and click “Continue.�

So, is there another pattern for a page with five or more elements and many optional fields? I’m glad you asked. One of the most versatile yet underused patterns is the wizard flow with form. And as a bonus, this pattern dispenses with the need for a separate verification page.

Wizard Flow With Form

The idea here is very simple. Start with a dedicated page to select each account, and then show the rest of the fields in a form.

Using this pattern, our me-to-me flow would look like this:

1. Dedicated page to select the “From� account;
2. Dedicated page to select the “To� account;
3. Continue to the form (with both the “To� and “From� fields now filled in);
4. Fill in the amount, etc., and hit “Continue�.

Here is the wireframe using the agile methodology:

Me-to-me transfer via the wizard flow with form.

This mobile design pattern combines the best features of Web forms, such as the flexibility of having optional fields and multiple input fields, with the vastly improved usability of dedicated, mobile-optimized selection pages. Another boon is the option to dispense completely with the verification page, because the form page itself acts as an editable verification page. Of course, you could always append a separate verification page if you really must.

Editing is also much easier than with most other patterns. Instead of having to go through the entire flow again, the customer only has to edit the fields that need correction. For example, to edit the “Toâ€� account, the customer would tap the corresponding field in the form and be taken to the dedicated “Toâ€� account page, and then immediately back to the form, without having to go through the entire “From� account → “To� account → Amount flow again.

Mobile: Thinking Differently

As we’ve seen now, mobile design itself is usually not complicated. In fact, because people will be using your app with fat meaty pointers (commonly called “fingers�) in a stressful multitasking environment (commonly called “life�), a less complicated design is virtually guaranteed to perform better. However, designing for mobile is one of the most sophisticated exercises any of us is likely to encounter. Simply copying successful desktop patterns is usually the worst choice, yet it is the one many designers naturally gravitate to.

Designing for mobile requires thinking differently. Remember that in mobile, each form field requires at least an extra tap to bring up the keyboard, picker, dedicated page or other element to enter data. Instead of a vertical flow to guide the person to the next field, consider using a horizontal flow instead. Look for options and inputs to eliminate. Whenever possible, minimize the number of pages the person has to go through in order to complete the workflow; this will reduce input errors and increase customer satisfaction. Last but not least, make user testing the core of your mobile design process, and be sure to user test everything you design as early as possible.

References

• Rocket Surgery Made Easy, Steve Krug (New Riders: New York, 2010)
• “How to Make Agile Work for Your Mobile Design Project,â€� (registration required) Greg Nudelman, video from the Mobile Design Essentials Virtual Seminar, DesignCaffeine
• “Ultimate Guide to Designing NFC Mobile Apps You Won’t be Ashamed Of,â€� Greg Nudelman, DesignCaffeine
• “Mobile First,â€� Luke Wroblewski

(al) (da) (il)

© Greg Nudelman for Smashing Magazine, 2012.

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

As John Ferrara wrote in his November 2010 UXMagazine article, “Psychic Search: a quick primer on search suggestions”, 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 Google.com, and a handful of mobile auto-suggest implementations that currently exist come from native mobile apps built by leading online retailers like Amazon and Booking.com.

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

As I wrote in my UXmatters article, “Mobile Search: Turning Limitations into Opportunities”, 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

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

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

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 Amazon.com.

References

• Brittin, Matt. “About Think Data.” Think Quarterly, May 15, 2011. Retrieved May 15, 2011.
• Ferrara, John. “Psychic Search: a quick primer on search suggestions.” UX Magazine, November 23 2010. Retrieved May 15, 2011.
• Kamvar, Sepandar D. et.al. “Anticipated query generation and processing in a search engine.” United States Patent # 20050283468, Google. June 22, 2004.
• Nielsen, Jakob. “Mobile Usability.” Alertbox July 20, 2009. Retrieved May 15, 2011.
• Nudelman, Greg. “Anticipated query generation in a search engine with refinement option.” United States Patent Application # 61477606, April 21, 2011.
• Nudelman, Greg. Designing Search: UX Strategies for Ecommerce Success, Wiley & Sons, 2011.
• Nudelman, Greg. “Mobile Search: Turning Limitations into Opportunities.” UXmatters, March 8, 2010. Retrieved May 15, 2011.
• PricewaterhouseCoopers, LLC. “Technology Forecast: Unleashing enterprise mobility.” Center for Technology and Innovation, issue 1, 2011. Retrieved May 15, 2011.

Related Articles

You might be interested in the following related articles:

• A Study of Trends in Mobile Design
• Designing for iPhone 4 Retina Display: Techniques and Workflow
• How To Build A Mobile Website
• Mobile section on Smashing Magazine.

(il) (vf)

© Greg Nudelman for Smashing Magazine, 2011. | Permalink | Post a comment | Smashing Shop | Smashing Network | About Us
Post tags: auto-suggest, mobile, tap-ahead