Skip navigation
Help

search history

warning: Creating default object from empty value in /var/www/vhosts/sayforward.com/subdomains/recorder/httpdocs/modules/taxonomy/taxonomy.pages.inc on line 33.

We are pleased to present you with this excerpt from Chapter 1 of Content Strategy for Mobile by Karen McGrane, now available from A Book Apart. —Ed.

When we talk about how to create products and services for mobile, the conversation tends to focus on design and development challenges. How does our design aesthetic change when we’re dealing with a smaller (or higher-resolution) screen? How do we employ (and teach) new gestural interactions that take advantage of touchscreen capabilities? How (and who) will write the code for all these different platforms—and how will we maintain all of them?

Great questions, every one. But focusing just on the design and development questions leaves out one important subject: how are we going to get our content to render appropriately on mobile devices?

The good news is that the answer to this question will help you, regardless of operating system, device capabilities, or screen resolution. If you take the time to figure out the right way to get your content out there, you’ll have the freedom (and the flexibility) to get it everywhere. You can go back to thinking about the right design and development approaches for each platform, because you’ll already have a reusable base of content to work from.

The bad news is that this isn’t a superficial problem. Solving it isn’t something you can do in isolation, by sandboxing off a subset of your content in a stripped-down mobile website or app. The solution requires you to look closely at your content management system, your editorial workflow, even your organizational structure. You may need different tools, different processes, different ways of communicating.

Don’t despair. There’s even better news at the end of this rainbow. By taking the time now to examine your content and structure it for maximum flexibility and reuse, you’ll be (better) prepared the next time a new gadget rolls around. You’ll have cleared out all the dead wood, by pruning outdated, badly written, and irrelevant content, which means all your users will have a better experience. You’ll have revised and updated your processes and tools for managing and maintaining content, which means all the content you create in every channel—print, desktop, mobile, TV, social—will be more closely governed.

Mobile is not the “lite” version

It looks like you're on a train. Would you like me to show you the insultingly simplified mobile site?

—Cennydd Bowles (http://bkaprt.com/csm/15)

If people want to do something on the internet, they will want to do it using their mobile device. Period.

The boundaries between “desktop tasks” and “mobile tasks” are fluid, driven as much by the device’s convenience as they are by the ease of the task. Have you ever tried to quickly look up a bit of information from your tablet, simply because you’re too lazy to walk over to your computer? Typed in a lengthy email on your BlackBerry while sitting at your desk, temporarily forgetting your keyboard exists? Discovered that the process to book a ticket from your mobile was easier than using the desktop (looking at you, Amtrak!) because all the extra clutter was stripped away?

Have you noticed that the device you choose for a given activity does not necessarily imply your context of use?

People use every device in every location, in every context. They use mobile handsets in restaurants and on the sofa. They use tablets with a focused determination in meetings and in a lazy Sunday morning haze in bed. They use laptops with fat pipes of employer-provided connectivity and with a thin trickle of data siphoned through expensive hotel Wi-Fi. They use desktop workstations on the beach—okay, they really only use traditional desktop machines at desks. You’ve got me on that one.

Knowing the type of device the user is holding doesn’t tell you anything about the user’s intent. Knowing someone’s location doesn’t tell you anything about her goals. You can’t make assumptions about what the user wants to do simply because she has a smaller screen. In fact, all you really know is: she has a smaller screen.

The immobile context

Users have always accessed our content from a variety of screen sizes and resolutions. Data reported by SecureCube shows that in January 2000, the majority of users visited from a browser with an 800×600 resolution, but a significant minority (twenty-nine percent) accessed the site at 1024×768 or higher, with a smaller percentage (eleven percent) viewing the site at 640×480 (http://bkaprt.com/csm/16; fig 1.1). At that time, decisions about how best to present content were seen as design challenges, and developers sought to provide a good reading experience for users at all resolutions, discussing appropriate ways to adjust column widths and screen layouts as content reflowed from smaller to larger screens.

Figure 1.1

Fig 1.1: We have plenty of experience delivering content to a variety of screen resolutions. Why do we assume that mobile screens necessarily indicate a different context?

What you didn’t hear designers talking about was the “640×480 context” and how it differed from the “1024×768 context.” No one tried to intuit which tasks would be more important to users browsing at 800×600, so less important options could be hidden from them. No one assumed that people’s mindset, tasks, and goals would be different, simply because they had a different-sized monitor.

Why do we assume that mobile is any different?

Mobile tasks, mobile content

I recently departed Austin, Texas, traveling with three friends. Since we arrived at the airport a bit early, I wanted to lounge in the comfort of the United Club, away from the teeming masses. I felt it would be rude to abandon my friends to a similar fate outside, and so I wanted to know how many guests I could bring with me to the club.

A simple Google search should clear up this problem. Sure enough, I quickly found a link that seemed promising (fig 1.2).

Figure 1.2

Fig 1.2: Searching for “United Club Membership” shows that the content exists on the desktop site. But because the mobile website redirects the URL, users wind up on the homepage of the mobile site.

Alas, following the link to United Club Membership just took me to the homepage for mobile.united.com. When users search from a mobile device, United automatically redirects links from Google to its mobile website—without checking to see if the content is available on mobile. If the content doesn’t exist on mobile, the user gets unceremoniously dumped on the homepage of the mobile website. Mobile redirects that break search—how is that ever a good user experience?

Sure, there’s a link to the full desktop site, but that too just dumped me on the desktop homepage. I could try to use United’s internal site search, but I’d wind up pinching and zooming my way through several search result screens formatted for the desktop. And honestly: why should I have to? An answer that should take me one tap from the Google search results should not require searching and tapping through several pages on both the mobile and the desktop sites.

I went and asked the representative at the desk. (Correct answer: two guests.)

I don’t bring this up just because I want to shame United for wantonly redirecting links to a mobile URL when the content isn’t available on its mobile website. (That’s a terrible thing to do, but it comes after a long list of other bad things I’d like to shame United Airlines for doing.) No, I use this example to illustrate a common misconception about mobile devices: that they should deliver only task-based functionality, rather than information-seeking content.

Information seeking is a task

Luke Wroblewski, in his book Mobile First, tells us that Southwest Airlines is doing the right thing by focusing only on travel tasks (fig 1.3):

The mobile experience…has a laser-like focus on what customers need and what Southwest does: book travel, check in, check flight status, check miles, and get alerts. No room for anything else. Only what matters most.

Figure 1.3

Fig 1.3: The Southwest Airlines iPhone application only has room for what actually matters…if what matters doesn’t involve looking up information.

Mobile experts and airline app designers don’t get to decide what “actually matters.” What matters is what matters to the user. And that’s just as likely to be finding a piece of information as it is to be completing a task.

Eighty-six percent of smartphone owners have used their phone in the previous month to look up information—whether to solve a problem, settle an argument, get up-to-the minute information such as traffic or sports scores, or to decide whether to visit a business like a restaurant (http://bkaprt.com/csm/27). Don’t believe me? Look at your own search history on your mobile device—you’ve probably tried to answer all sorts of questions by looking up information on your phone.

The Southwest Airlines desktop website includes information about their baggage policies, including policies for checked bags, carry-ons, and pets, as well as lost and found, delayed baggage, and a variety of other traveler information, such as what to do if you lose your ticket, need to rebook, or your flight is overbooked. It even includes information for parents looking to book travel for unaccompanied minors, and how Southwest accommodates disabled flyers and the elderly.

The mobile experience does not. Who are we to say that this content doesn’t actually matter?

It’s fine to optimize the mobile experience for the most common tasks. But that doesn’t mean that you should exclude valuable content.

Mobile is social

Have you ever clicked on a link from Facebook or Twitter on your phone? How about a link someone sent you in an email?

Figure 1.4

Fig 1.4: “No mobile content found. Would you like to visit the desktop version of the site?” asks The Guardian. Can you guess the answer?

Of course you have. Sharing content with our friends and colleagues is one of the bedrock ways we communicate these days. Users don’t distinguish between accessing email, Facebook, Twitter, or other social services on the desktop or on mobile—they choose them fluidly, depending on which device they’re closest to at the time. In fact, as of June 2012, nearly twenty percent of Facebook members use it exclusively on mobile (http://bkaprt.com/csm/28).

If your content isn’t available on mobile—or provides a bad reading experience—you’re missing out on one of the most compelling ways to get people to read it. Is your site littered with icons trying to get people to share your content? If your readers just get an error message when they tap on shared content, all the effort you put into encouraging social sharing is wasted (fig 1.4).

Designing for context

“Context” is the buzzword everyone throws around when talking about mobile. At the South by Southwest Interactive conference in 2011, the panel called “Designing for context” was the number one must-see session, according to .net Magazine (http://bkaprt.com/csm/29).

The dream is that you can tailor your content for the user’s context—location, time of day, social environment, personal preferences. Based on what you know about the user, you can dynamically personalize the experience so it adapts to meet her needs.

Today, we use “designing for the mobile context” as an excuse to make mobile an inferior experience. Businesses want to invest the least possible time and effort into mobile until they can demonstrate return on investment. Designers believe they can guess what subset of information or functionality users want. Everyone argues that they’re designing for the “mobile use case.”

Beware of personalized interfaces

Presuming that the “designer knows best” when choosing how to deliver personalized content or functionality is risky. We’re notoriously bad about predicting what someone will want. Even armed with real data, we’re likely to make incorrect assumptions when we decide to show some things and hide others.

Microsoft Office tried this strategy in the late 1990s. Office 97 offered many new features and enhancements, which made the user interface more complex. Long menus and dense toolbars gave the impression that the interface was “bloated” (http://bkaprt.com/csm/30). (Sound like any desktop websites you know?)

In response, Microsoft developed “personalized menus” and “rafted toolbars” which showed the most popular items first (fig 1.5). Although Microsoft had good data and a powerful algorithm to help determine which items should be presented first, it turned out that users didn’t like being second-guessed. People found it more frustrating to go through a two-stage process, hunting through multiple menus to find what they were looking for. Personalized menus violated one of the core principles of usable design: put the user in control.

Figure 1.5

Fig 1.5: Personalized menus in Office 97 attempted to prioritize only the options Microsoft thought users wanted. They were a failure.

Now imagine that instead of clicking a chevron at the bottom of the menu to expand it, the user has to click a link to “full desktop website” and then hunt around in the navigation while squinting at a tiny screen. If your website’s mobile version only offers a subset of your content, you’re giving your users the same frustrating experience. Only much worse.

You don’t have good data

Microsoft had a ton of data about which options people used most frequently. They developed a complex algorithm to present the default “short” menu based on the items people were most likely to want, based on years of history and research with multiple iterations of their product. And they still made mistakes.

The choices you make about which subset of content you want to deliver probably aren’t backed up by good data. They might not be backed up by any research at all, just a gut feeling about which options you imagine will be most important to the mythical on-the-go user.

Even if you do have analytics data about which content people are looking for on mobile, it’s not likely you’re getting an accurate picture of what people really want. Today’s crippled mobile experiences are inadequate testing grounds for evaluating what people wish they could do on mobile. As Jason Grigsby, Cofounder of CloudFour.com and MobilePortland.com, says:

We cannot predict future behavior from a current experience that sucks (http://bkaprt.com/csm/31).

If your vision for mobile is designing for context, then the first step you need to take is getting all your content onto mobile devices.

All of it? Really?

Really. Your content strategy for mobile should not be to develop a satellite to your desktop site, showing only the subset of content you’ve decided a mobile user will need. That’s not going to work because:

  • People move fluidly between devices, often choosing a mobile device even when they have access to a desktop computer. Don’t assume you can design for “the on-the-go user” because people use their mobile devices anywhere and everywhere.
  • Mobile-only users want and need to look at your content too! Don’t treat them like second-class citizens just because they never or rarely use the desktop. Even if you think of them as “mobile-mostly” users, remember that you don’t get to decide which device they use to access your content. They do.
  • Mobile supports reading content just as well as it supports functional tasks. Don’t pat yourself on the back just because you’ve mobile-ized some key features—there’s more work to do with your content.
  • Context is a cop out. Don’t use context as a rationale to withhold content unless you have real research and data about what users need in a given situation or environment. Unless you have that, you’re going to guess wrong. (And even if you do have that—given the crappy experiences most users get on mobile today, you’ll still probably guess wrong.)

Never force users to go to the desktop website for content they’re seeking on a mobile device. Instead, aim for content parity between your desktop and your mobile experiences—maybe not exactly the same content presented exactly the same way, but essentially the same experience.

It is your mission to get your content out, on whichever platform, in whichever format your audience wants to consume it. Your users get to decide how, when, and where they want to read your content. It is your challenge and your responsibility to deliver a good experience to them.

RSS readers: Don't forget to join the discussion!

0
Your rating: None

We are pleased to present you with this excerpt from Chapter 1 of Content Strategy for Mobile by Karen McGrane, now available from A Book Apart. —Ed.

When we talk about how to create products and services for mobile, the conversation tends to focus on design and development challenges. How does our design aesthetic change when we’re dealing with a smaller (or higher-resolution) screen? How do we employ (and teach) new gestural interactions that take advantage of touchscreen capabilities? How (and who) will write the code for all these different platforms—and how will we maintain all of them?

Great questions, every one. But focusing just on the design and development questions leaves out one important subject: how are we going to get our content to render appropriately on mobile devices?

The good news is that the answer to this question will help you, regardless of operating system, device capabilities, or screen resolution. If you take the time to figure out the right way to get your content out there, you’ll have the freedom (and the flexibility) to get it everywhere. You can go back to thinking about the right design and development approaches for each platform, because you’ll already have a reusable base of content to work from.

The bad news is that this isn’t a superficial problem. Solving it isn’t something you can do in isolation, by sandboxing off a subset of your content in a stripped-down mobile website or app. The solution requires you to look closely at your content management system, your editorial workflow, even your organizational structure. You may need different tools, different processes, different ways of communicating.

Don’t despair. There’s even better news at the end of this rainbow. By taking the time now to examine your content and structure it for maximum flexibility and reuse, you’ll be (better) prepared the next time a new gadget rolls around. You’ll have cleared out all the dead wood, by pruning outdated, badly written, and irrelevant content, which means all your users will have a better experience. You’ll have revised and updated your processes and tools for managing and maintaining content, which means all the content you create in every channel—print, desktop, mobile, TV, social—will be more closely governed.

Mobile is not the “lite” version

It looks like you're on a train. Would you like me to show you the insultingly simplified mobile site?

—Cennydd Bowles (http://bkaprt.com/csm/15)

If people want to do something on the internet, they will want to do it using their mobile device. Period.

The boundaries between “desktop tasks” and “mobile tasks” are fluid, driven as much by the device’s convenience as they are by the ease of the task. Have you ever tried to quickly look up a bit of information from your tablet, simply because you’re too lazy to walk over to your computer? Typed in a lengthy email on your BlackBerry while sitting at your desk, temporarily forgetting your keyboard exists? Discovered that the process to book a ticket from your mobile was easier than using the desktop (looking at you, Amtrak!) because all the extra clutter was stripped away?

Have you noticed that the device you choose for a given activity does not necessarily imply your context of use?

People use every device in every location, in every context. They use mobile handsets in restaurants and on the sofa. They use tablets with a focused determination in meetings and in a lazy Sunday morning haze in bed. They use laptops with fat pipes of employer-provided connectivity and with a thin trickle of data siphoned through expensive hotel Wi-Fi. They use desktop workstations on the beach—okay, they really only use traditional desktop machines at desks. You’ve got me on that one.

Knowing the type of device the user is holding doesn’t tell you anything about the user’s intent. Knowing someone’s location doesn’t tell you anything about her goals. You can’t make assumptions about what the user wants to do simply because she has a smaller screen. In fact, all you really know is: she has a smaller screen.

The immobile context

Users have always accessed our content from a variety of screen sizes and resolutions. Data reported by SecureCube shows that in January 2000, the majority of users visited from a browser with an 800×600 resolution, but a significant minority (twenty-nine percent) accessed the site at 1024×768 or higher, with a smaller percentage (eleven percent) viewing the site at 640×480 (http://bkaprt.com/csm/16; fig 1.1). At that time, decisions about how best to present content were seen as design challenges, and developers sought to provide a good reading experience for users at all resolutions, discussing appropriate ways to adjust column widths and screen layouts as content reflowed from smaller to larger screens.

Figure 1.1

Fig 1.1: We have plenty of experience delivering content to a variety of screen resolutions. Why do we assume that mobile screens necessarily indicate a different context?

What you didn’t hear designers talking about was the “640×480 context” and how it differed from the “1024×768 context.” No one tried to intuit which tasks would be more important to users browsing at 800×600, so less important options could be hidden from them. No one assumed that people’s mindset, tasks, and goals would be different, simply because they had a different-sized monitor.

Why do we assume that mobile is any different?

Mobile tasks, mobile content

I recently departed Austin, Texas, traveling with three friends. Since we arrived at the airport a bit early, I wanted to lounge in the comfort of the United Club, away from the teeming masses. I felt it would be rude to abandon my friends to a similar fate outside, and so I wanted to know how many guests I could bring with me to the club.

A simple Google search should clear up this problem. Sure enough, I quickly found a link that seemed promising (fig 1.2).

Figure 1.2

Fig 1.2: Searching for “United Club Membership” shows that the content exists on the desktop site. But because the mobile website redirects the URL, users wind up on the homepage of the mobile site.

Alas, following the link to United Club Membership just took me to the homepage for mobile.united.com. When users search from a mobile device, United automatically redirects links from Google to its mobile website—without checking to see if the content is available on mobile. If the content doesn’t exist on mobile, the user gets unceremoniously dumped on the homepage of the mobile website. Mobile redirects that break search—how is that ever a good user experience?

Sure, there’s a link to the full desktop site, but that too just dumped me on the desktop homepage. I could try to use United’s internal site search, but I’d wind up pinching and zooming my way through several search result screens formatted for the desktop. And honestly: why should I have to? An answer that should take me one tap from the Google search results should not require searching and tapping through several pages on both the mobile and the desktop sites.

I went and asked the representative at the desk. (Correct answer: two guests.)

I don’t bring this up just because I want to shame United for wantonly redirecting links to a mobile URL when the content isn’t available on its mobile website. (That’s a terrible thing to do, but it comes after a long list of other bad things I’d like to shame United Airlines for doing.) No, I use this example to illustrate a common misconception about mobile devices: that they should deliver only task-based functionality, rather than information-seeking content.

Information seeking is a task

Luke Wroblewski, in his book Mobile First, tells us that Southwest Airlines is doing the right thing by focusing only on travel tasks (fig 1.3):

The mobile experience…has a laser-like focus on what customers need and what Southwest does: book travel, check in, check flight status, check miles, and get alerts. No room for anything else. Only what matters most.

Figure 1.3

Fig 1.3: The Southwest Airlines iPhone application only has room for what actually matters…if what matters doesn’t involve looking up information.

Mobile experts and airline app designers don’t get to decide what “actually matters.” What matters is what matters to the user. And that’s just as likely to be finding a piece of information as it is to be completing a task.

Eighty-six percent of smartphone owners have used their phone in the previous month to look up information—whether to solve a problem, settle an argument, get up-to-the minute information such as traffic or sports scores, or to decide whether to visit a business like a restaurant (http://bkaprt.com/csm/27). Don’t believe me? Look at your own search history on your mobile device—you’ve probably tried to answer all sorts of questions by looking up information on your phone.

The Southwest Airlines desktop website includes information about their baggage policies, including policies for checked bags, carry-ons, and pets, as well as lost and found, delayed baggage, and a variety of other traveler information, such as what to do if you lose your ticket, need to rebook, or your flight is overbooked. It even includes information for parents looking to book travel for unaccompanied minors, and how Southwest accommodates disabled flyers and the elderly.

The mobile experience does not. Who are we to say that this content doesn’t actually matter?

It’s fine to optimize the mobile experience for the most common tasks. But that doesn’t mean that you should exclude valuable content.

Mobile is social

Have you ever clicked on a link from Facebook or Twitter on your phone? How about a link someone sent you in an email?

Figure 1.4

Fig 1.4: “No mobile content found. Would you like to visit the desktop version of the site?” asks The Guardian. Can you guess the answer?

Of course you have. Sharing content with our friends and colleagues is one of the bedrock ways we communicate these days. Users don’t distinguish between accessing email, Facebook, Twitter, or other social services on the desktop or on mobile—they choose them fluidly, depending on which device they’re closest to at the time. In fact, as of June 2012, nearly twenty percent of Facebook members use it exclusively on mobile (http://bkaprt.com/csm/28).

If your content isn’t available on mobile—or provides a bad reading experience—you’re missing out on one of the most compelling ways to get people to read it. Is your site littered with icons trying to get people to share your content? If your readers just get an error message when they tap on shared content, all the effort you put into encouraging social sharing is wasted (fig 1.4).

Designing for context

“Context” is the buzzword everyone throws around when talking about mobile. At the South by Southwest Interactive conference in 2011, the panel called “Designing for context” was the number one must-see session, according to .net Magazine (http://bkaprt.com/csm/29).

The dream is that you can tailor your content for the user’s context—location, time of day, social environment, personal preferences. Based on what you know about the user, you can dynamically personalize the experience so it adapts to meet her needs.

Today, we use “designing for the mobile context” as an excuse to make mobile an inferior experience. Businesses want to invest the least possible time and effort into mobile until they can demonstrate return on investment. Designers believe they can guess what subset of information or functionality users want. Everyone argues that they’re designing for the “mobile use case.”

Beware of personalized interfaces

Presuming that the “designer knows best” when choosing how to deliver personalized content or functionality is risky. We’re notoriously bad about predicting what someone will want. Even armed with real data, we’re likely to make incorrect assumptions when we decide to show some things and hide others.

Microsoft Office tried this strategy in the late 1990s. Office 97 offered many new features and enhancements, which made the user interface more complex. Long menus and dense toolbars gave the impression that the interface was “bloated” (http://bkaprt.com/csm/30). (Sound like any desktop websites you know?)

In response, Microsoft developed “personalized menus” and “rafted toolbars” which showed the most popular items first (fig 1.5). Although Microsoft had good data and a powerful algorithm to help determine which items should be presented first, it turned out that users didn’t like being second-guessed. People found it more frustrating to go through a two-stage process, hunting through multiple menus to find what they were looking for. Personalized menus violated one of the core principles of usable design: put the user in control.

Figure 1.5

Fig 1.5: Personalized menus in Office 97 attempted to prioritize only the options Microsoft thought users wanted. They were a failure.

Now imagine that instead of clicking a chevron at the bottom of the menu to expand it, the user has to click a link to “full desktop website” and then hunt around in the navigation while squinting at a tiny screen. If your website’s mobile version only offers a subset of your content, you’re giving your users the same frustrating experience. Only much worse.

You don’t have good data

Microsoft had a ton of data about which options people used most frequently. They developed a complex algorithm to present the default “short” menu based on the items people were most likely to want, based on years of history and research with multiple iterations of their product. And they still made mistakes.

The choices you make about which subset of content you want to deliver probably aren’t backed up by good data. They might not be backed up by any research at all, just a gut feeling about which options you imagine will be most important to the mythical on-the-go user.

Even if you do have analytics data about which content people are looking for on mobile, it’s not likely you’re getting an accurate picture of what people really want. Today’s crippled mobile experiences are inadequate testing grounds for evaluating what people wish they could do on mobile. As Jason Grigsby, Cofounder of CloudFour.com and MobilePortland.com, says:

We cannot predict future behavior from a current experience that sucks (http://bkaprt.com/csm/31).

If your vision for mobile is designing for context, then the first step you need to take is getting all your content onto mobile devices.

All of it? Really?

Really. Your content strategy for mobile should not be to develop a satellite to your desktop site, showing only the subset of content you’ve decided a mobile user will need. That’s not going to work because:

  • People move fluidly between devices, often choosing a mobile device even when they have access to a desktop computer. Don’t assume you can design for “the on-the-go user” because people use their mobile devices anywhere and everywhere.
  • Mobile-only users want and need to look at your content too! Don’t treat them like second-class citizens just because they never or rarely use the desktop. Even if you think of them as “mobile-mostly” users, remember that you don’t get to decide which device they use to access your content. They do.
  • Mobile supports reading content just as well as it supports functional tasks. Don’t pat yourself on the back just because you’ve mobile-ized some key features—there’s more work to do with your content.
  • Context is a cop out. Don’t use context as a rationale to withhold content unless you have real research and data about what users need in a given situation or environment. Unless you have that, you’re going to guess wrong. (And even if you do have that—given the crappy experiences most users get on mobile today, you’ll still probably guess wrong.)

Never force users to go to the desktop website for content they’re seeking on a mobile device. Instead, aim for content parity between your desktop and your mobile experiences—maybe not exactly the same content presented exactly the same way, but essentially the same experience.

It is your mission to get your content out, on whichever platform, in whichever format your audience wants to consume it. Your users get to decide how, when, and where they want to read your content. It is your challenge and your responsibility to deliver a good experience to them.

0
Your rating: None

  

Editor’s Note: Smashing Magazine is happy to present this sample chapter from Theresa Neil’s new book Mobile Design Pattern Gallery: UI Patterns for iOS, Android and More, which provides solutions to common design challenges. We’re certain you’ll find the information useful for your next mobile project.

As I was waiting for a table at a local restaurant the other day, I flipped through a couple of the free classified papers. I was shocked to realize how dependent I’ve grown on three simple features that just aren’t available in the analog world: search, sort and filter.

AutoDirect and some of the other freebies are organized by category (like trucks, vans, SUVs) but others, like Greensheet, just list page after page of items for sale. I would actually have to read every single ad in the paper to find what I wanted. No thank you, I’ll use Craigslist on my phone instead.

But after taking a look at Craigslist mobile, it became obvious we could all benefit from some best practices around mobile search, sort and filter UI design. This chapter explores a dozen different ways to surface and refine the data your customers want.

Search Patterns

Before you ever try to design a search interface for any platform, buy and read these two books: Search Patterns: Design for Discovery by Peter Morevill and Jeffery Callendar, and Designing Search: UX Strategies for eCommerce Success by Greg Nudelman.

Then take a look at these search patterns specific to mobile applications:

  • Explicit Search
  • Auto-Complete
  • Dynamic Search
  • Scoped Search
  • Saved & Recent
  • Search Form
  • Search Results

Explicit Search

Explicit search relies on an explicit action to perform the search and view results. That action might be to tap a search button on the screen, like Walmart, or on the keyboard, like Target. The results are typically displayed in the area below the search bar. Consider pairing an explicit search pattern with the auto-complete pattern.


Walmart uses a search button (Go) on the screen, Target uses the Search on the keyboard.


Target loading and then displaying search results.

Offer a clear button in the field and an option to cancel the search. Use feedback to show the search is being performed.

Auto-Complete

Probably the most useful search pattern that emerged in Web 2.0 is auto-complete. Typing will immediately surface a set of possible results, just tap on one to selected it and the search will be performed. Or continue typing your own criteria and then tap the explicit search button.


Android Marketplace (Google Play) and Netflix both use auto-complete

Ideally the results will be displayed immediately, but a progress indicator (searching…) should be used for system feedback. Netflix (above) uses an indicator in the search field, whereas Fidelity (below) displays one where the results will eventually be displayed.


Fidelity shows feedback while loading the auto-complete options.

TripAdvisor provides an enhanced auto-complete, grouping the results by popular destinations, hotels, restaurants. LinkedIn does something similar by showing direct connections first, then other people in LinkedIn.


TripAdvisor and LinkedIn group the suggested options.

Provide feedback if there could be a delay in displaying the results. Consider emphasizing the matching search text in the search results.

Dynamic Search

This pattern may also be called dynamic filtering. Entering text in the search field will dynamically (onkeypress) filter the data on the screen. Note, the examples may look similar to auto-complete but there is a different interation model. The dynamic search pattern is used to refine or whittle down a existing and visible list of objects. In these examples from BlackBerry App World and WorldMate on Android, apps and hotels, respectively, were already displayed on the page.


BlackBerry App World and WorldMate offer dynamic search for refining a big list of results.

Works well for refining constrained data sets, like an address book or personal media library, but may be impractical for searching large data sets from multiple sources.

Scoped Search

Sometimes it is easier (and faster) to get to the desired result by scoping the search criteria before performing the search. Google and Photobucket use different designs to the same end.


Google uses an overlay to present scope options, whereas Photobucket uses a dialog.

AllRecipes also lets you select criteria (or filters) before submitting the search. Dropbox defaults the initial scope to All, but you can switch it to Files or Folders before or after tapping the search button.


AllRecipes pushes the limit of scoping options, Dropbox keeps it simple with just 3.

Offer reasonable scoping options based on the data set. Three to six scoping options are plenty, consider a search form for advanced searching capabilities.

Saved & Recent

Successful mobile interfaces follow a basic usability maxim: respect the users effort. Saved and recent searches do this by making it easy to select from previous searches, instead of retyping the same keywords or search criteria.


eBay lets customers explicity save searches. Both eBay and Walmart implicity save customers’ most recent searches.

Other options to respect the users’ effort involve location based searching options like Trulia, and bar code searching, like PriceCheck by Amazon.


Trulia offers location based searching, Amazon offers 4 ways to search.


Google Shopper offers scan and speak search options and a full search history grouped by search date.

Saved searches typically require additional steps to name a search for later use, whereas recent searches are implicitly saved and surfaced. Consider which one will best serve your customers’ needs.

Search Form

This pattern is characterized by a separate form for entering search criteria, and an explicit search button.


Search forms on WorldMate and airbnb.


WholeFood’s recipe search allows customers to add multiple criteria, course, category, special diets and keywords.

Minimize the number of input fields. Implement OS specific input controls properly. Follow form design best practices (alignment, labels, size).

Search Results

Once a search is performed the results can be displayed in the same screen or on a dedicate results screen. Results may be displayed in a table or list, on a map or satellite, or as thumbnail images. Multiple view options can be used depending on the type of results and user preferences.


Kayak and Foursquare (webOS) show the results in a table.


airbnb shows the results in a list and offers a map view toggle.


Zappos offers a list view and alternate carousel view for browsing search results.

Lazy loading is a common technique to use so that some results will be displayed while the rest are being loaded. Many applications offer either a button to explicitly “view more results” or will automatically load more results when the screen is flicked.


eBay Motors and Best Buy.

Label the results with the number returned. Use lazy loading instead of paging. Apply a reasonable default sort order. Avoid paging tables, they break the natural interaction model for viewing information on a mobile device.

Sort

It is important to choose a reasonable default sort for displaying search results. A little common sense plus user validation is the best way to choose the default sort order. These patterns offer options for changing the default sort:

  • Onscreen Sort
  • Sort Selector
  • Sort Form

Onscreen Sort

When there are only a few sort options, an onscreen sort can provide a simple one tap solution. Placing the sort toggle at the top or bottom of the screen will depend on the other screen elements.

Target provides four sort options with a three toggle button. For the price sort option, they offer two choices: sort by price ascending and sort by price descending.


Expedia (older version) and Target iOS use onscreen sort.

Clearly show which option is selected or “on”. Consider the Sort Order Selector pattern if the option labels don’t fit nicely in a toggle button bar.

Sort Order Selector

The selector pattern is a good alternative to the onscreen sort. There are a number of different UI controls that can be used for selection, but consider the design guidelines for the OS you are designing for (ex. the menu is common for Android app, and the picker and actionsheet are common in iOS apps).


Walmart on Android uses the common menu control.

The option titles can be longer (more explicit) and more options can be displayed. Walmart places the sort button in proximity with the search field, wheras Kayak offers sort and filter options at the bottom of the screen.


Kayak on iOS uses the standard selector control.

OS neutral solutions include a simple combobox, like Target on Android, or an overlay menu, like Awesome Note.


Target on Android just uses a combobox. AwesomeNote uses an overlay.

Follow OS design conventions for choosing the selector control, or choose an OS neutral implementation. Clearly show which sort option is applied.

Sort Form

Some applications have consolidated the sort and filter options into one screen, typically titled “Refine”. This is the most effort intensive sort pattern requiring the user to open the form, select an option, and then apply the selection (by tapping “done” or “apply”).


Cars.com and eBay Classifieds.

Consider the more efficient sort option toggle or sort order selector patterns before choosing this design.

Filter

Large sets of data can require additional filtering, also called refining. Filtering relies on the user selecting criteria by which to refine the set of search results or a large set of objects. Common filtering patterns include:

  • Onscreen Filter
  • Filter Drawer
  • Filter Dialog
  • Filter Form

Also see the earlier search pattern, Scoped Search, for an optional pre-filtering technique.

Onscreen filter

Similar to the onscreen sort, the onscreen filter is displayed with the results or list of objects. With one tap, the filter is applied. HeyZap uses the standard toggle button bar, whereas Google uses vertical tabs.


HeyZap and Google.

CBS News and the ACL Festival app uses a scrolling filter bar as a way to let users quickly hone in on certain types of articles and bands, respectively.


CBS News (single filter bar) and Austin City Limits Music Festival (double filter bar).

Don’t use this filter pattern for primary navigation within your app, but instead use it to group and filter related content.

SXSW offers a filter button bar combined with a second row of filtering options. Feed a Fever news reader uses a super simple stylized set of comboboxes for filtering news feeds.


SXSW Conference app and Feed a Fever.

Filter options should be clearly worded and easy to understand. Show the filters that are applied or “on”.

Filter Drawer

Almost as efficient as the onscreen filter, a drawer can be used to reveal filter options. Flicking or tapping a handle will open the drawer. Audible’s drawer reveals a simple filter toggle bar, whereas Sam’s offers a host of filter options that can be applied to the map of club locations. A better design for Sam’s would be to leave the map visible and allow for dynamic filtering instead of the explicit “filter” button.


Audible and Sam’s Club.


Expedia’s new filter drawer.

Filter Dialog

Like a pop-up on in a web app, the filter dialog is modal in nature. It requires the user to select a filter option, or cancel the action. TripAdvisor on iOS has a custom filter dialog, whereas USPS Mobile on Android relies on the default selector control.


TripAdvisor and Due Today Lite.

While the Filter Dialog may get the job done, the first two patterns provide more freedom for users to experiment with and apply filters directly in context.

Keep the options list short, avoid scrolling. Consider a Filter Form for lengthier or multi-select filter options.

Filter Form

Large data sets can benefit from more advanced filter/refinement options. For example, WorldMate uses a form to filter hotels based on price, brand and stars. Zappos uses a similar approach, using the iOS standard drill down for selection, and the clear/done buttons in the title bar.


WorldMate’s filter form (looks very similar to Kayak’s design) and Zappos filter form for iOS.

Freetime uses custom controls in their filter form. First you pick the filter category, then choose the filter criteria, then apply the filter to the calendar.


Free-Time filter form.

Conditional filters, also called predicate editors or expression builders, are an advanced filtering feature typically found in reporting tools. Here’s the standard layout used on the web and desktop.


Predicate editor in the Wufoo web application.

Creating a conditional filtering a mobile application can be challenging in a mobile form factor but Roambi has accomplished it.


Roambi’s predicate editor.

Don’t over-design the filters, a simple onscreen filter or drawer will usually suffice. If a filter form is necessary, follow form design best practices.

More Resources

Learn more about designing usable and effective mobile apps in Mobile Design Pattern Gallery: UI Patterns for iOS, Android, and More:

  • Navigation
  • Forms
  • Tables
  • Tools
  • Charts
  • Invitations
  • Feedback & Affordance
  • Help

Also check out the Mobile Design Pattern Gallery website, blog and Flickr photostream with +600 screenshots.

(fi)

© Theresa Neil for Smashing Magazine, 2012.

0
Your rating: None



Today's the day Google's broad new privacy policy goes into effect. European regulators are claiming it violates data protection laws, but it's here and it may be here to stay.

There are some not-completely-foolproof ways to hide from Google, but first let's talk about what's changed. Prior to today, Google had more than 70 privacy policies for its various products. But with the company trying to create a seamless experience across search, Gmail, Google+, Google Docs, Picasa, and much more, Google is consolidating the majority of its policies down into just one document covering most of its products. This will make it easier for Google to track users for the purpose of serving up personalized ads.

Read the rest of this article...

Read the comments on this post

0
Your rating: None