Anything that slows down customers or gets in their way after they download your app is a bad thing. That includes sign-up/sign-in forms that show up even before potential customers can figure out if the app is actually worth using.

It’s a simple UX equation

This antipattern seems to be going away more and more as companies are beginning to figure out the following simple UX equation:

Long sign-up form before you can use the app = Delete app

However, a fair number of apps still force customers to sign up, sign in, or perform some other useless action before they can use the app.

Example

The application SitOrSquat is a brilliant little piece of social engineering software that enables people to find bathrooms on the go, when they gotta go. Obviously, the basic use case implies a, shall we say, certain sense of urgency. This urgency is all but unfelt by the company that acquired the app, Procter and Gamble (P&G), as it would appear for the express purposes of marketing the Charmin brand of toilet paper. (It’s truly a match made in heaven—but I digress.)

Not content with the business of simply “Squeezing the Charmin” (that is, simple advertising), P&G executives decided for some unfathomable reason to force people to sign up for the app in multiple ways. First, as you can see in Figure 1, the app forces the customer (who is urgently looking for a place to relieve himself, let’s not forget) to use the awkward picker control to select his birthday to allegedly find out if he has been “potty trained.” This requirement would be torture on a normal day, but—I think you’ll agree—it’s excruciating when you really gotta go.

Figure 1: Registration Torture: Sign Up/Sign In antipattern in SitOrSquat app.

But the fun does not stop there—if (and only if) the customer manages to use the picker to select the month and year of his birth correctly (how exactly does the app know it’s correct?), he then sees the EULA (Figure 2), which, as discussed in the previous article, End User License Agreement (EULA) Presentation (Boxes and Arrows January 2nd, 2013), is an antipattern all to itself.

Figure 2: Reading the EULA while wanting to pee should be an Olympic sport.

SitOrSquat’s EULA is long, complex, and written in such tiny font that reading it while waiting to go to the bathroom should be considered an Olympic sport, to be performed only once every four years. Assuming the customer gets through the EULA, P&G presents yet another sign-up screen, offering the user the option to sign in with Facebook, as shown in Figure 3.

Figure 3: Finally! Sharing my bathroom habits on Facebook has never been easier!

I guess no one told the P&G execs that the Twitter message “pooping” is actually a prank. They must have legitimately thought that they could transfer some sort of social engineering information about the person’s bathroom habits to “achieve and maintain synergistic Facebook connectivity.” I would have to struggle hard to find monumental absurdities from social networking experiments that are equal to this. I can’t imagine that anyone thinks “Finally! Sharing my bathroom habits on Facebook has never been easier!”

Assuming that the user is a legitimate customer looking to use the bathroom for its intended purpose, and not a coprophiliac Facebook exhibitionist, we may hope that he will naturally dismiss the Facebook sign-in screen and come to the next jewel: the Tutorial, shown in Figure 4.

Figure 4: Tutorial is a sub-par Welcome experience pattern. Here it is another impediment to progress.

SitOrSquat tutorial is an extra screen that provides very little value, other than impeding the use of the app for its intended purpose. (If you need a tutorial, I recommend a much more effective contextual Watermark pattern, which I discuss in Chapter 5 of the Android Design Patterns book.)

50 Taps and 7 Screens of Antipatterns

Note that the entire app outside of registration consists of basically four screens (if you count the functionality to add bathrooms!). However, if you include all the sign-up antipattern screens (including my initial failure to prove that my potty training certificate is up to date, as referred to in Figure 1), it takes seven screens of the “preliminary” garbage before the content you are looking for finally shows up (refer to Figure 5). If you count the number of taps necessary to enter my birthday, that becomes almost 50 taps!

Figure 5: The Glory of 50 taps needed to get through the Sign Up/Sign In antipattern in SitOrSquat app.

One of my favorite UX people, Tamara Adlin (who coauthored The Persona Lifecycle: Keeping People in Mind During Product Design with John Pruitt) wrote brilliantly: “For Heaven’s Sakes, Let Them Pee.” I believe that never before has this line been so appropriate. In the absurd pursuit of social media “exposure” coupled with endless sign-up screens, with heavy-handed “lawyering up,” P&G executives completely lost sight of the primary use case: letting their customer SitOrSquat.

Long sign-up screens detract from the key mobile use case: quick, simple information access on the go. Overly invasive sign-up/sign-in screens presented up front and without due cause will cause your customers to delete the app.

There is no reason to force anyone to register for anything

When deciding whether to force the customer to perform an action, consider this: If this were a web app, would you force the customer to do this? If you have Internet connection, you can save everything the customer does and connect it back to his device using a simple session token and a guest account. And even if you don’t (for example, while riding in a subway, using airplane mode, and so on), today’s smartphones have plenty of on-board storage you can use for later syncing with your servers when the mobile network eventually becomes available.

This means there is simply no reason to force anyone to register for anything, other than if they want to share the data from their phone with other devices. As a general rule, rather than forcing registration upon download or at the first opportunity, it is much better to allow the customer to save a piece of information locally on the phone without requiring that he log in. Wait until the customer asks for something that requires registration, such as sharing the information with another device or accessing information already saved in his account; at that point completing the registration makes perfect sense.

For example, imagine how absurd the Amazon.com shopping experience would be if the app asked you for your home address, billing address, and credit card upfront—before allowing you to see a single item for sale! Yet entering the home address (where would you like to have the items shipped?) and credit card (how would you like to pay for this?) makes perfect sense during the checkout, after the customer selects a few items and indicates she would like to complete the purchase.

Finally, remember that “Forms suck,” as brilliantly quipped by Luke Wroblewski in his book Web Form Design (Rosenfeld Media, 2008). Only ask for what you strictly need to proceed to the next step and omit extraneous information. (Effective mobile data entry controls and forms is a huge topic to which I devote chapters 10-12 of my upcoming Android Design Patterns book (Wiley March 11, 2013), now available on Amazon.com).

The first thing your customers see when they download and open your app is the welcome mat you roll out for them. Unfortunately, this welcome mat commonly contains unfriendly impediments to progress and engagement: End User License Agreements (EULAs). Like the overzealous zombie cross-breed between a lawyer and a customs agent, this antipattern requires multiple forms to be filled out in triplicate, while keeping the customers from enjoying the app they have so laboriously invested time and flash memory space to download. This article exposes the culprit and suggests a friendlier welcome strategy for your mobile apps.

Antipattern: End User License Agreements (EULAs)

When customers open a mobile website, they can often engage immediately. Ironically, the same information accessed through apps frequently requires agreeing to various EULAs, often accompanied by ingenious strategies that force customers to slow down. EULA is an antipattern.

When and Where It Shows Up

EULAs are typically shown to the customer when the application is first launched and before the person can use the app. Unfortunately, when they do show up, EULAs are also frequently accompanied by various interface devices designed to slow people down. Some EULAs require people to scroll or paginate to the end of a 20-page document of incomprehensible lawyer-speak before they allow access. Others purposefully slow people down with confirmation screens that require extra taps. Truly, things in a torture department have evolved nicely since the days of Spanish Inquisition!

Example

Financial giant Chase provides a good example of a EULA. As shown in figure 1, when customers first download the Chase app, they are faced with having to accept a EULA even before they can log in.

Figure 1: EULA antipattern in Chase app.

What makes this example interesting, is that the same information is accessible on the mobile phone without needing to accept the EULA first: through the mobile web browser, as shown in Figure 2.

Figure 2: There is no EULA on the Chase mobile website.

Why Avoid It

The remarkable thing is not that the EULA is required. Lawyers want to eat, too, so the EULAs are an important component of today’s modern litigious society. Dealing with a first-world bank in the “New Normal” pretty much guarantees that you’ll be faced with signing some sort of a legal agreement at some point in the relationship. The issue is not the EULA itself—it is the thoughtlessness of the timing of the EULA’s appearance.

The app has no idea if you have turned on the mobile access on or have your password set up properly. (Most people have at least a few issues with this.) Therefore, the app has no idea if the bank can serve you on this device. However, already, the bank managed to warn you that doing business on the mobile device is dangerous and foolhardy and, should you choose to be reckless enough to continue, the bank thereby has no reasonable choice but to relinquish any and all responsibility for the future of your money. This is hardly an excellent way to start a mature brand relationship.

What should happen instead? Well, the mobile website provides a clue. First, it shows what a customer can do without logging in, such as finding a local branch or an ATM. Next, the mobile site enables the customer to log in. Then the system determines the state of the EULA that’s on file. If (to paraphrase Eric Clapton in “The Tales of Brave Ulysses”) the customers’ “naked ears were tortured by the EULA’s sweetly singing” at some point in the past, great—no need to repeat the sheer awesomeness of the experience. If not, well, it’s Lawyer Time. Consequently, if customers do not have Bill Pay turned on, for example, they don’t need to sign a Bill Pay EULA at all, now do they? The point is that the first page customers get when they first launch your app is your welcome mat. Make sure yours actually says “Welcome.”

Additional Considerations

Has anyone bothered asking, “How many relationships (that end well) begin with a EULA anyway?” How would Internet feel if every website you navigated to first asked you to agree to a EULA, even before you could see what the site was about? That just does not happen. You navigate to a website and see awesome welcome content immediately. (Otherwise, you’d be out of there before you could spell E-U-L-A.) When you use a site to purchase something, you get a simple Agree and Proceed button with a nearby link to a EULA agreement (not that anyone ever bothers to read those things anyway, especially on mobile) and merely proceed on your way.

If you can surf the web happily, taking for granted the awesomeness of the smorgasbord of information on the mobile and desktop, without ever giving a second thought to the EULAs, why do you need to tolerate a welcome mat of thoughtless invasive agreements on a mobile app platform?

Additional Information

You can find 70 essential mobile and tablet design ideas and antipatterns in my new book, Android Design Patterns: Interaction Design Solutions for Developers (Wiley, 2013) now available for pre-order at http://AndroidDesignBook.com where you can also sign up for the next free monthly Android Design Question and Answer session.

Transitions as design elements

Since the 1980s, designers have been drawing wireframes to represent web pages and device interfaces.¹ In the beginning, wireframes were static schematics that showed a single state of the page. With the emergence of dHTML in the 1990s, it became necessary to draw different states of specific dynamic page elements, so the designers adapted the wireframe methodology to document the beginning and end states of the dynamic elements. Still, designers and engineers had little or no control over what happened in between the beginning and end states — the browser or the operating system handled all transitions.

More recently, sophisticated mobile touch frameworks like iPhone, Android, Palm and Windows Mobile allowed unprecedented control over the speed and structure of the transitions, giving designers more tools with which to create a better experience in a confined mobile space.² Simultaneously, on the web, dynamic platforms like Flash and Flex gained tremendous ground, making it possible for designers to think about and document transitions because those were now part of the customer experience.

With the release of the Apple iPad, the Age of Transition has come to its full potential. On the iPad, Apple takes full advantage of some of the principles and ideas the company previously explored and perfected using the iPhone. On the bigger iPad screen, transitions achieve a new level of detail and sophistication, making the device come alive, and become a powerful, integral part of the experience.

Transitions Require Thinking Differently

As Jonathan Follett writes in his article “Interfaces That Flow: Transitions as Design Elements”:http://www.uxmatters.com/mt/archives/2007/04/interfaces-that-flow-transitions-as-design-elements.php, ³ many UX designers approach projects from a combination of information architecture and interaction design. These disciplines involve thinking that is quite different from constructing the continuous linear narratives required to design and document transitions. Nevertheless, by borrowing freely from the lessons of early animators, it is quite possible to adopt the existing wireframes methodology to convey the structure and rhythm of a user interface transition.

The task consists of wireframing each of the important changes (or “key frames”) that occur during the transition and stringing a bunch of wireframes together in a storyboard. By documenting the key aspects of the transition, it is possible to share them with the larger team and try out different transitions designs. Documenting the transitions also allows us to step back and consider them in a larger context of a specific use case or overall goal of progressive engagement and immersion.

Understanding iPad Transitions

In order to be able to design and document transitions using storyboards, we have to first understand design principles that designers of transitions use to convey the desired meaning. Let’s take a look at the Apple, Inc. video in Figure 1 showing selected transitions from what is arguably the most popular iPad application today: iTunes. Although many different transitions are shown in the video, we will be specifically looking at the two of them: “opening the iTunes application” (0:17-0:20 min) and “opening album details” (0:30 -0:36 min).



Figure 1: Video of iTunes transitions on the iPad ["View larger version on YouTube":http://www.youtube.com/watch?v=Z03PR_4Ln90]

Borrowing from Chet and Guy’s excellent Devoxx presentation “Animation Rules!”:http://www.parleys.com/#st=5&sl=1&id=1578,⁴ we can identify seven key principles that specifically apply to the animated transitions on the iPad:
# Component Relationship (background-foreground)
# Illusion (motion perception and perceptual constancy)
# Exaggeration (highlighting states, actions, and changes in state)
# Staging (camera view, lighting, focus)
# Acceleration and Deceleration (slow in and out)
# Metaphors (using real-world analogies to convey complex digital events)
# Simplicity (avoiding noise)

To understand how the seven principles above apply combine to make the transition work its magic, let’s do a step-by-step breakdown of the “opening the iTunes application” transition, shown in Figure 2.



Figure 2: Opening iTunes Application Step-by-Step

Using our seven key principles:
Component Relationship (background-foreground)

This transition is essentially the process by which the iTunes application comes into the foreground, while the rest of the apps recede into the background. In the first row, the transition starts out with the home screen and apps icons firmly in the foreground. By the end of the row, we can see that the home screen recedes and darkens, while the iTunes app (represented by a white square) slowly comes into the foreground. By the second row, the background-foreground transition is essentially complete – we can see only the loading iTunes app against the black background.

Illusion (motion perception and perceptual constancy)

This transition creates its magic via an illusion of “flying into” the device, and eventually meeting the white square that represents the iTunes app. To accomplish this, the animation shows us “flying” through the layer of the apps icons on the home screen. The other app icons begin to “fly” to the sides of the screen in a circular pattern, as shown in row 1. The most interesting part of the illusion is the kind of “bait-and-switch”. If you look carefully, you’ll see that the app icons never make it off screen. Just before we “pass through the icons layer” and “witness” the icons “flying off screen”, the background goes completely black, and our attention is focused on the white rectangle. The illusion is complete.

Exaggeration (highlighting states, actions, and changes in state)
In this transition, the lighting effects are used to exaggerate the switch between the background and foreground. In the second row, the background goes completely black, to highlight the change in state. Exaggeration can also be used to warp the shape of an object to emphasize movement, as in is used more in the “genie” effects and transitions.

Staging (camera view, lighting, focus)

Subtle but powerful lighting is used throughout the transition as the primary means for focusing our attention on the foreground of the opening window of the iTunes app through subtle darkening of the background (principle 1). Lighting is also used to accomplish the bait-and-switch in the Illusion principle.

Acceleration and Deceleration (slow in and out)

Our brains know from experience that objects do not start running at top speed or “stop on the dime”. To make the movement more life-like, the animation accelerates into the movement very slowly, picking up pace in later screenshots, as evidenced by the increasing “smudginess” of the icons in the first row. Not surprisingly, the bait-and-switch happens in the fastest moment of the transition to pull of the illusion that the homepage icons actually “fly off screen”. The transition then slows down again in the last row to smoothly fade in the iTunes content elements, deliberately giving the auxiliary page elements and pictures time to “catch up” and making the page load appear smoother.

Metaphors (using real-world analogies to convey complex digital events)

The most effective transitions use real-life elements to provide a frame of reference which makes the animation more realistic. In this case, the icons on the home screen are moving to the sides, creating an overall illusion of moving through space, or deeper “into” the device itself to convey a digital event of opening an application inside the device.

Simplicity (avoiding noise)
The overriding theme of this transition is its apparent simplicity. During the transition, iTunes is not doing anything particularly complicated or earth-shattering. The magic comes not from one particular element, but through carefully blending and combining the lighting and movement to create a smooth cohesive digital dance, perfectly orchestrated from beginning to the end.

Storyboarding iPad Transitions

The key to successfully designing and storyboarding the transitions is understanding and applying the seven animation principles we discussed above. To demonstrate how this can be done, let’s use a slightly more complex transition: the iTunes “opening album details”, shown in Figure 3.



Figure 3: Opening iTunes Album Details Step-by-Step

Here again, we see the seven principles at work:
Component Relationship (background-foreground)

This entire transition can be viewed as bringing the selected album cover into the foreground, while the rest of the iTunes application recedes slightly into the background.

Illusion (motion perception and perceptual constancy)

The animation shows us the illusion of the album flying forward on the screen while flipping 180 degrees. The most interesting part of the illusion is the switch from darker gray “back” of the album to a while loading screen (midway through the second row). This sleigh of hand changes the focus to the white cover to make the transition believable.

Exaggeration (highlighting states, actions, and changes in state)

In this transition again, the lighting effects are used to exaggerate the switch between the background and foreground. Midway through the second row the album turns completely white against the slightly darker background.

Staging (camera view, lighting, focus)

In the beginning the iTunes application darkens gradually, and reaches its full saturation about half-way through the second row to create the background against which the album will be staged. The album, on the other hand, switches first from color to darker gray, then to solid white to jump to the foreground.

Acceleration and Deceleration (slow in and out)

The animation starts slowly, and achieves top speed half-way through the second row to quickly switch from the dark gray flipping rectangle to a solid white loading page. Just as in the previously discussed “opening iTunes” transition, this transition also slows down in the last row to smoothly fade in the iTunes album cover content elements.

Metaphors (using real-world analogies to convey complex digital events)

This transition invokes the magical feeling of opening picking the old LP album off the shelf and flipping it over to see the back cover by creating the illusion of the album jumping off the page and flipping 180 degrees horizontally around the middle.

Simplicity (avoiding noise)

While a bit more complex than the “opening iTunes application”, this transition can nevertheless be adequately described by looking at only 12 screenshots.

Once the transition design principles are understood, the process of drawing the storyboard becomes fairly straightforward. I use the same method that Galileo Galilei used four centuries ago when he first diagrammed the step-by-step movement of the sun spots in 1613.⁵ The basic transition storyboard for the “Opening iTunes Details” transition is shown in Figure 4.



Figure 4: Storyboarding iPad Transitions Using Post-it Notes ["See larger version":/files/banda/storyboarding-ipad/figure4_ipadtransitions_postitnotes_large.png]

Now Start Making Your Own Transitions

As you try your own hand in transition storyboarding, here are a few points to keep in mind:

Use appropriate materials


To diagram transitions, I prefer to use medium-size post-it notes that measure 3-inch square. I draw each of the steps in the transition using a soft retractable pencil with a good eraser. This allows me to quickly diagram portrait and landscape transitions, and everything in between. Because the iPad is a rectangle, not a square, I leave the extra space left on the right of the post-it note (on the bottom for landscape) to write the additional explanation for each step or simply leave it blank.

Simplify shading


As I said above, on the iPad the lighting is foundation to expressing Component Relationship, Exaggeration, and Staging principles, so it makes sense to take a disciplined approach to drawing various shades of light and dark in your storyboard. I find that the easiest approach is to draw shading on top of the picture as light lines at a 45 degree angle. As you can see in the last three post-its, I use tighter line spacing to indicate progressively darker shading.

Get the basics down first


When I first approach the transition design, I make only the post-its necessary to convey the overall movement of the various elements and basic component relationship. I sketch quickly using very rough strokes, and use a ruler and templates whenever possible to make my job easier.

Stick to 6-8 post-its


As you can see in Figure 4, it is not necessary to draw all 12 original key frames we saw in figure 3. To convey the basic structure of a transition, I typically try to use only 6-8 post-it notes. Using fewer steps keeps me focused on the principle of simplicity: if it takes me more than 8 post-it notes to describe the transition, it is probably too complex and I immediately look for unnecessary elements or animation that needs to be eliminated or scaled back.

Ignore Acceleration and Deceleration


Above we spoke at length about the Acceleration and Deceleration principle. This idea is essential to creating effective, believable transitions. However, when drawing a rough storyboard of 6-8 post-its, this is the one principle that I found can be safely ignored. Once people understand this principle, most folks can extrapolate from your rough drawings to imagine the complete smooth transition “in their mind’s eye”. As long as you make it clear to your team that this is only a rough storyboard that the end result will in fact follow the principle, you can safely ignore the subject and concentrate on the relationship, movement and shading of screen elements.

Draw the complete story


Transitions do not happen in isolation – they are an integral part of the overall customer experience. Thus, when I storyboard transitions, I typically do it in the context of the entire use case. This helps me make sure that the particular transition makes sense in the complete context and in combination with other transitions. For example, when I use the “flip” transition to show the search results on the map, and then use the “slide back” transition to go back to the list of search results, the storyboard will quickly reveal the inconsistency in the mental model of the interface I am trying to create and the problem transition will feel awkward when walking through the use entire storyboard.

Sketch a few different transition designs


When I approach a given transition, I usually try out 3-4 different design approaches to see which transition creates the effect I am seeking. Sometimes I find that I need to create 10 or more sets of ideas for more complex and critical interactions. The point of this initial sketching is not to create the complete and final blueprint, but to help you visualize how a given transition design option would feel with the rest of the app interactions. Doing the transition with post-it notes allows me to quickly add a new transition or re-position the existing post-its to create and try out several different scenarios, often while engaging in the active team discussion. I recommend you make copies or take photos of your boards periodically to preserve promising design directions before repositioning the post-it notes and changing the transition layout again.

Obtain Initial Stakeholder Approval


In addition to helping you find the best design approach, a rough storyboard is also a fantastic tool for conveying various design options to your team for joint discussion and brainstorming as well as for obtaining initial stakeholder buy-in. It’s a lot easier to discuss the merits of a particular transition movement and information architecture when everyone is quite literally on the same page looking at your complete use case storyboard.

Creating the Final Transition Blueprint

When you obtain the initial stakeholder approval using your rough storyboard drawing, you will need to document the final storyboard design that the engineers to actually create. Here you have a couple of options.

One approach is to use Flash to create the transition with the final high-fidelity look and feel. This is certainly a valid option. However, I found Flash to be more useful for higher-fidelity usability testing and final stakeholder approval than for describing transitions to engineers. Here is why: most developers do not read Flash code and most transitions are simply too fast for the eye to understand in detail the subtleties of acceleration and shading simply by looking at a running a Flash file. I have had several instances of getting not exactly what I specified or else getting something completely different, only to have the engineers claim that “this is exactly what the Flash looked like”. This is especially a big problem with distributed multi-lingual teams where communication is an issue.

The method that I found to work well is to specify (e.g. create a wireframe for) each of the frames at regular intervals of every 50-100 milliseconds for the entire duration of the transition. Most transitions are between 0.5 – 1.2 seconds, so you will need to create anywhere between 5-24 wireframes in your favorite wireframing tool such as Fireworks, OmniGraffle or Visio. Stringing these frames together in document pages will create a short movie that will comprise the complete blueprint that will describe the position, shading, and movement of each element that will communicate clearly and exactly so the engineers can create the exact transition you envisioned.

While this seems at first like a lot of work, after a bit of practice the wireframing goes fairly quickly, as the difference between the each new page and the one before it is only a slight change in position and shading. As long as we firmly keep in mind the principles by which iPad transitions work, we can easily diagram relevant steps for rich, expressive transitions.

To continue this conversation, add a comment below or reach out to Greg at “@designcaffeine”:http://twitter.com/designcaffeine or through his website, “DesignCaffeine.com”:http://www.DesignCaffeine.com.

Interested in more UX sketching techniques? Join us Saturday, May 28th, 2011 at UX SketchCamp ["SketchCamp.com":http://www.sketchcamp.com or "@sketchcamp":http://twitter.com/sketchcamp on Twitter] in San Francisco for a chance to learn from the experts, practice UX sketching and share what you know with others.

References

1. “Wireframing Marathon Starts”:http://ciohappyhour.com/wireframing-marathon-starts/; CIO Happy Hour, September 2010

2. See my article “Designing Mobile Search: Turning Limitations into Opportunities”:http://www.uxmatters.com/mt/archives/2010/03/designing-mobile-search-turning-limitations-into-opportunities.php; UX Matters, March 2010.

3. Jonathan Follett; “Interfaces That Flow: Transitions as Design Elements”:http://www.uxmatters.com/mt/archives/2007/04/interfaces-that-flow-transitions-as-design-elements.php; UX Matters, July 2007

4. Chet Haase and Romain Guy; “Animation Rules!”:http://www.parleys.com/#st=5&sl=1&id=1578; Devoxx ’09

5. Galileo documented the movement of the sun spots in his triumphant “Istoria e Dimostrazioni Intorno Alle Macchie Solari e Loro Accidenti Rome”:http://physics.ship.edu/~mrc/pfs/110/inside_out/vu1/Galileo/Things/g_sunspots.html (History and Demonstrations Concerning Sunspots and their Properties); 1613.

In this article, I propose the Integrated Faceted Breadcrumb (IFB) design that integrates the power of faceted refinement with the intuitive query expansion afforded by browse. Although other breadcrumb-based finding interfaces currently exist, they fall short of expectations by ignoring design best practices. At best, the breadcrumb is stuck in a role of a side-kick, forced to eke out meager screen real estate along-side more powerful finding controls.

In contrast, breadcrumb is the superhero of the IFB design, dealing a decisive blow to many usability issues that plague today’s finding interfaces. To prove this point, I did what we do best – I tested my hypothesis. Twelve evaluators found IFB to be easy to use, intuitive and resourceful for solving complex finding tasks which would be difficult to accomplish using more conventional faceted search interfaces.

The Challenge of Integrated Finding

In his recent UIE webinar, Peter Morville lauded the advantages of integrated finding: “Browse and Search work best in tandem… the best finding interfaces achieve a balance, letting users move fluidly between browsing and searching.”¹

Unfortunately, most sites today do not integrate faceted search and browse effectively. For example, Walmart.com approaches browse and search using two different interfaces creating a jumble of duplicate controls that overwhelm the customer, making the site more difficult to use, as shown in Figure 1.

Figure 1. Disjointed finding mechanisms for faceted search and browse on Walmart.com

A veritable cornucopia of filters, links and options on Walmart.com make it unlikely that the customers will be able to duplicate the search successfully or efficiently discover related items and content. Duplicate finding methods also create a problem for natural search, because each finding page exists only within the context of the specific session.

Achieving “flexible navigation, seamless integration of browsing with directed (keyword) search, fluid alternation between refining and expanding, avoidance of empty results sets, and at all times allowing the user to retain a feeling of control and understanding” are “overarching design goals” of faceted finding, says Marti Hearst in Chapter 8 of her Search User Interfaces book.²

Integrated Faceted Breadcrumb (IFB) Design

To meet the search and browse integration challenges, I propose the Integrated Faceted Breadcrumb (IFB) design solution. A wireframe of the recommended Walmart.com UI redesign that uses the Integrated Faceted Breadcrumb is shown in Figure 2.

Figure 2. Wireframe of Walmart.com redesigned using Integrated Faceted Breadcrumb (IFB)

Breadcrumbs are simple, intuitive, flexible and resourceful. As Jacob Nielsen, states in his 2007 Alertbox, Breadcrumb Navigation Increasingly Useful: “Breadcrumbs show people their current location relative to higher-level concepts, helping them understand where they are in relation to the rest of the site. Breadcrumbs afford one-click access to higher site levels and thus rescue users who parachute into very specific but inappropriate destinations through search or deep links. Breadcrumbs never cause problems in user testing… people… never misinterpret breadcrumb trails or have trouble operating them.”³

Preliminary Usability Evaluation of the Integrated Faceted Breadcrumb

Findings from the early usability testing of the Integrated Faceted Breadcrumb design using a linked HTML prototype are very promising. Using a simple, 8-page HTML prototype, I tested several variations of this design with 12 current users of popular e-commerce interfaces, people of various genders, ages and backgrounds.

Evaluators were able to quickly grasp the range of possible interactions and use the interface effectively to solve complex finding tasks which would be difficult to accomplish with the existing faceted search interface. Most evaluators found IFB design intuitive because it makes liberal use of the existing mental models for breadcrumbs and faceted search. 

The participants’ confidence and ability to accurately predict system behavior was also observed to be very high after just 1-2 simple tasks; this indicates a fairly short learning curve for IFB design. Although no formal studies comparing the performance of someone using IFB vs. existing faceted finding solutions have yet been conducted, IFB design was strongly preferred by the participants when compared with the existing Walmart.com faceted search design for certain kinds of finding tasks.

Early usability tests show that Integrated Faceted Breadcrumb (IFB) design provides many benefits over most conventional faceted search designs:

1. Short learning curve: familiar links and drop-downs make this control fairly intuitive. People who previously used a breadcrumb can operate IFB effectively.
2. Efficiency: combining breadcrumb and facets into one control makes very efficient use of limited screen real estate and greatly reduces clutter caused by duplication of controls.
3. Unlimited Access: Combined search and browse allow unrestricted access to any page that pertains to the current query.
4. Integration: fully integrates landing pages, brand catalogs and category pages into the faceted search hierarchy. There is one prominent place on the screen to see where you are and access all the navigation tools right where they are needed.
5. Flexibility: customers can switch from search to browse and back again as best fits their needs at each stage of the finding process.
6. Resourcefulness: provides opportunities to widen the search and access complimentary products and services related to the current query.

What makes Integrated Faceted Breadcrumb (IFB) different

In his 2009 UIE webinar, Faceted Search: Designing Your Content, Navigation, and User Interface ⁴, Daniel Tunkelang stated that most breadcrumb-based finding interfaces are not intuitive, nor easy to use. What makes Integrated Faceted Breadcrumb (IFB) design different? I believe Integrated Finding Breadcrumb design is more intuitive and resourceful than other faceted breadcrumb solutions due to the following key design recommendations made based on several years of designing and researching finding interfaces:

1. Combine hierarchical Location & Attribute breadcrumbs
2. Use Change instead of Set-Remove-Set
3. Automatically retain relevant query information
4. Label breadcrumb aspects
5. Make it clear how to start a new search
6. Allow direct keyword manipulation.

In the following sections, I discuss these design recommendations and explain how Integrated Faceted Breadcrumb compares with some existing faceted breadcrumb solutions. Whether or not the reader decides to adopt all or some part of IFB in their own finding interface designs, I hope the following sections will prove to be a good resource for discussion and further exploration of integrated finding UI designs.

1. Combine Hierarchical Location & Attribute breadcrumbs

In 2002, information architect Keith Instone cataloged the three types of breadcrumbs in his 3rd Annual IA Summit poster with a revealing title: Location, Path & Attribute breadcrumbs.⁵ In faceted search interfaces, Attribute breadcrumbs commonly convey applied facet values such as price, category, style and brand. Most commonly, Attribute breadcrumbs are Path breadcrumbs, displaying facet values in the order they were applied by the customer to reach the current set of search results. Attribute-Path breadcrumb UI on the Ariba Discovery Network is shown in Figure 3.

Figure 3. Attribute-Path breadcrumb in the Ariba Discovery Network UI

Unfortunately, Attribute-Path breadcrumb is not resourceful from the standpoint of integrating search and browse and helping people find related content:

1. Temporal breadcrumb cannot be used to effectively link and anchor categories, landing pages, brand catalogs and other browse pages, precisely because it is carrying all of the attribute history instead.
2. Temporal breadcrumb cannot be used to effectively show the customer where they can go because instead it is busy showing them where they’ve been.
3. Pages with Temporal breadcrumbs cannot be effectively linked by natural search, because people creating different URLs each time the content is accessed.
4. When the query changes, attributes appear to “randomly” jump around on the breadcrumb.

In contrast, Location breadcrumbs are hierarchical: they do not deal with where the person has been, only with where within the site’s organization they are right now. Hierarchies are very helpful in a wide range of finding and navigating tasks and provide an intuitive way to manage complexity and access resources.

How do we determine the hierarchy of Attributes? My research led me to believe that most people find it intuitive when the Attribute-Location breadcrumb simply replicates the order in which un-selected facets are presented (most typically in the left nav bar). Replicating the order in which un-selected facets appear also provides an effective way to integrate search and browse by treating the Category as just another Attribute in the breadcrumb. In vast majority of finding interfaces, Category appears first in the left nav bar, which places any applied “browse” Category Attributes in front of the applied faceted search values.

Figure 4. Un-selected facets in the left nav bar on Amazon.com

Most of the people found the Integrated Faceted Breadcrumb hierarchy straightforward and intuitive and were able to confidently and accurately predict the expected system behavior for complex filtering tasks that involved applying, removing and changing filter values, after spending only a few minutes working with the system.

2. Use Change instead of Set-Remove-Set

Figure 5. Overstock set-remove-set implemented via checkboxes

Applied aspects are removed from the breadcrumb by un-checking the checkbox next to the applied aspect in the breadcrumb. For most people, set-remove-set interaction conflicts with their mental model. As one of my evaluators stated: “This feels like having to turn off the radio every time I want to change the station.”

Instead of removing Canon in order to select Nikon, most people think in terms of simply changing Canon to Nikon, which can be accomplished most readily with a drop-down control. The drop-down is more intuitive than a typical remove mechanism, as it allows the user to discover all of the navigation options available from the parent facet or category. This idea was first introduced by Luke Wroblewski in his excellent book Site Seeing: a Visual Approach to Web Usability.⁶ One of the sites that implement drop down in the breadcrumb is Edmunds.com, shown in Figure 6.

Figure 6. Edmunds breadcrumb with drop down options

In my testing, vast majority of people preferred this design to a more common set-remove-set paradigm and found it very intuitive and effective.

3. Automatically retain relevant query information

In my research, I found that people seldom want to start the query over completely from scratch, unless they specifically indicated this action. Instead, they wanted to retain as much of the query as possible with every change of the facet values, and expect the system to help them construct a query that “makes sense”, gracefully dropping facet selections that no longer apply to their new query.

Unfortunately, few sites today implement this function well. For example, changing the model from Mustang to Fusion does not retain the year selection of 2005, as most people would expect. Instead, as shown in Figure 7, Edmunds.com resets the model year to the current year, 2010, which simply disappears from the breadcrumb.

Figure 7. Changing aspect values drops useful query information on Edmunds.com

I found that a more resourceful system behavior is to retain any relevant attribute values that apply to the new query, preferably in way that always produces some search results.

Figure 8 shows how Integrated Faceted Breadcrumb design handles the change in the Product Type from Digital Cameras to Lenses, retaining the Brand and Keywords aspect, while dropping the Camera Resolution aspect (as it does not apply to Lenses).

Figure 8. Integrated Faceted Breadcrumb retains relevant query information

Retaining aspects that apply to the updated query allows the customer to concentrate on their finding goals, while the system takes care of the details.

What if the person really wanted to browse just the Lenses Product Type? My testing showed that most people found it very intuitive to click the Lenses link in order to navigate to the Lenses Product Type landing page. The result of combining drop-down control functionality with the existing breadcrumb link interaction gives us a powerful, intuitive, flexible finding control.

What if instead of browsing, someone wanted to remove a single applied aspect from a breadcrumb, leaving the rest of the query intact? My research showed that most people found it easy and intuitive to navigate to the drop down and select “See All” option Integrated Faceted Breadcrumb design provides at the #1 position in the drop-down, as shown in Figure 9.

Figure 9. Integrated Faceted Breadcrumb makes aspect removal intuitive

4. Label Breadcrumb Aspects

In Design Cop-out #2: Breadcrumbs⁷, Jared Spool mentions that the biggest problem with breadcrumbs is “the lack of scent” and that “the wording of the individual trail elements becomes very important.”

While most applications simply display the applied aspects in the breadcrumb, my research shows that labeling each of the applied aspects with the aspects name adds a great deal of information scent. The resulting IFB “breadcrumb tiles” (shown in Figure 9) display relevant aspect labels which help customers make sense of their queries and orient themselves quickly if they find the page through natural search.

5. Make it clear how to start a new search

Ariba interface in Figure 3 has a single search box which retains the original keywords, in a manner similar to Google. Unfortunately, any keyword change drops all of the applied aspects and filters launching a new keyword-only search. This is obviously not very resourceful, as we are trying to retain as much of the query as possible for reasons explained above.

In contrast, Integrated Faceted Breadcrumb (IFB) provides a dedicated “New Search” button on the Home breadcrumb tile. As shown in Figure 10, clicking the “New Search” button removes all aspects and keywords, resetting the breadcrumb to the full-screen text box, reminding many evaluators of the simplicity of the Google search.

Figure 10. “New Search” in the Integrated Faceted Breadcrumb (IFB) interface

Resetting is accomplished via an HTML layer or similar device so that the rest of the content on the page does not change. This way, the search box can reset almost instantaneously, perhaps even with an elegant animated transition.

6. Allow Direct Keyword Manipulation

Many faceted search interfaces like Overstock.com pictured in Figure 11, have two search boxes: one to “search within” the existing query, and one to start over with a new keyword-only search. Having two search boxes takes up precious screen real estate and increases the potential for confusion. Worse yet, the customer can not directly modify their keyword query after the search is executed, because the system converts all the keywords into an aspect which cannot be modified, only removed in its entirety.

Figure 11. Overstock.com does not allow direct manipulation of the keyword query

In his seminal book, Designing the user interface: Strategies for effective human-computer interaction⁸, Ben Shneiderman describes direct manipulation is one of the key HCI design principles. Integrated Faceted Breadcrumb (IFB) provides direct keyword query manipulation with the dynamic editable Keywords Aspect shown in Figure 12.

Figure 12. Direct query keyword manipulation in IFB

At the start of a finding session, the search box starts out fully expanded across the entire width of the page. When the customer types in some keywords, they are retained in the search box for easy editing or keyword addition, as shown in Figure 12-A. If the customer selects one or more facets, they are always added according to their respective hierarchy in front of the search box. As more aspects are added, the keyword box gets progressively smaller, until it reaches some reasonable minimum size as shown in Figure 12-B.

If sill more facets are applied at this point, a scroll arrow appears immediately after the Home facet, allowing customers to scroll only the applied aspects in the manner of a carousel control, without ever hiding the Home facet or the search box, as shown in Figure 12-C. IFB dynamic editable Keywords Aspect design proved to be very successful with our evaluators who found it intuitive, resourceful and easy to use.

Conclusion

Bruce Sterling, in his brilliant and entertaining book Shaping Things⁹, mentions Raymond Lowey and his very useful acronym MAYA. Faceted breadcrumb designs have only recently began to move out of being Most Advanced (the domain of academics and computer geeks) and toward becoming Acceptable to the general internet public.

Faceted breadcrumb holds in my opinion the promise to become the key component in the next generation of intuitive finding interfaces that fully integrate the best of faceted search and browse capabilities. I hope this article will assist anyone designing a faceted finding interface and helps move faceted breadcrumb designs, like the Integrated Faceted Breadcrumb, one step closer to the edge of MAYA, helping make resourceful integrated finding a commonplace reality. I look forward to continuing the discussion of IFB in the article comments thread and on Twitter “@DesignCaffeine”:http://twitter.com/designcaffeine.

References

¹ “Search UI Patterns”:http://www.slideshare.net/UIEpreviews/search-discovery-patterns-a-uie-virtual-seminar

² “Search User Interfaces”:http://searchuserinterfaces.com/book/sui_ch8_navigation_and_search.html book.

³“Alertbox, Breadcrumb Navigation Increasingly Useful”:http://www.useit.com/alertbox/breadcrumbs.html

⁴ 2009 UIE webinar “Faceted Search: Designing Your Content, Navigation, and User Interface”:http://www.uie.com/events/virtual_seminars/facets/

⁵ “Location, Path & Attribute breadcrumbs”:http://instone.org/files/KEI-Breadcrumbs-IAS.pdf

⁶“Site Seeing: a Visual Approach to Web Usability”:http://www.lukew.com/resources/site_seeing.asp

⁷“Design Cop-out #2: Breadcrumbs”:http://www.uie.com/articles/breadcrumbs

⁸ “Designing the user interface: Strategies for effective human-computer interaction”:http://www.aw-bc.com/dtui/

⁹ “Shaping Things”:http://mitpress.mit.edu/catalog/item/default.asp?tid=10603&ttype=2