Skip navigation
Help

Mobile Web

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

By Dominique Hazaël-Massieux: People used to stare at me and laugh, back in 2005 when W3C launched its Mobile Web Initiative to advocate the importance of the web to the mobile world. Now I am the one smiling much of the time, as I did most recently during the 2013 edition of the Mobile World Congress (MWC) in Barcelona, one of the largest events to focus on mobile devices and networks.

This year W3C had a huge HTML5 logo splashed across its booth to emphasize the impact of the Open Web Platform across industries and devices. But the real adoption story was told by the HTML5 logos prominent at many, many other booths. The web has gained real visibility on mobile, and we should all be smiling because we are all getting closer to a platform for reaching more people on more devices at lower cost.

MWC 2013 also confirmed that HTML5 has broken out of the browser. We are seeing more and more HTML5-based development platforms, such as PhoneGap, Windows 8, Blackberry, and Tizen. Mozilla’s big announcement at MWC 2013 centered on FirefoxOS, Mozilla’s mobile operating system entirely based on web technologies. W3C and Intel partnered to create a T-shirt that says “I See HTML5 Everywhere.” And indeed, I do.

The challenge of mobile

Not only has the web a big role to play on mobile, mobile has also a key role to play for the web. As more and more of our connected interactions start or end on mobile devices, we must ensure that the web platform adapts to our mobile lives. I believe this is critical for the future of the web.

For many years W3C has designed technology to make the experience of web users on mobile ever more rich, adapted, and integrated. For example, CSS media queries provide the basis for responsive web design. There is already a lot for mobile, and a lot more is coming. To help people follow all the activity, every quarter I publish an overview of web technologies that are most relevant to mobile.

These technologies are the tools designers can rely on to build the user experience they need. But technologies are only a small piece of the puzzle when it comes to making the web user experience work on mobile devices. The number of A List Apart articles about mobile development provides a clear sign that this challenge is driving creativity in the design community. Responsive web design, mobile first, future friendly, and just-in-time interactions are some of the trends that have resonated with me over the years. The creativity is fantastic, but we still want our lives to be easier. Where web technologies do not yet provide the hooks you need to practice your craft, please let us know. Feel free to write me directly: dom@w3.org.

Closing the gap

Another challenge that we, the web community, face on mobile is the amazing energy devoted to native development.

The web has displaced a lot of the native software development on traditional computers; on mobile, the reverse trend has happened. Content that users had enjoyed on the web for years started to migrate to native applications: newspapers, social networking, media sharing, government services, to name a few. And to add insult to injury, a number of these content providers are pushing their users away from their website toward their native application, with obtrusive banners or pop-ups.

It is unclear where the world is going on mobile: some statistics and reports show a strong push toward moving back to the web (e.g., the recent Kendo UI survey), while others argue the opposite. What is clear to me, though, is that we cannot afford to let mobile become a native-entrenched ecosystem.

What has made the web unique and popular in so many hearts is not the technology (some great, some terrible) nor even the ubiquity (since interoperability can reduce it). I believe the much more fundamental importance of the web comes from its structural openness: anyone can publish the content they see fit and anyone can participate in defining the future of the web as a platform.

Native ecosystems on mobile have historically been very closed ecosystems, under the control of single commercial entities. A world where the majority of our information and infrastructure would be trapped inside these ecosystems is not something we should accept lightly. Mind you, I appreciate the innovations spawned by these platforms, but we need to encourage the cycle where innovations become standards, and those standards prime the platform for the next innovations.

Of course the best way to shift the balance to the web is to make the web the best platform for mobile. Achieving this will require ideas and energy from many people, and web developers and designers play a critical role in shaping the next generation of web user experiences. I am leading a focused effort in W3C to assess what we can and should do to make the web more competitive on mobile, and welcome feedback and ideas on what the missing pieces in the puzzle are.

Beyond mobile

I believe a key part in making the web the “king of mobile” is to realize that mobile devices are a means to an end. In our connected world—computers, phones, tablets, TVs, cars, glasses, watches, refrigerators, lightbulbs, sensors and more to come—mobile phones will most likely remain the hub for while. The only platform that can realistically be made available on all these devices is the web.

We have a unique opportunity to make the Open Web Platform a success. I realize getting it right will not be trivial. Building user experiences that scale from mobile (or watches!) to TV is complex. Building user experiences that adapt to these very different type of interactions will be hard. Matching the needs from users in a growing diversity of contexts will make us cringe. Creating user experiences that abolish the devices barrier (as I explored some months ago) is guaranteed to create more than a few headaches.

But there is unprecedented momentum to create an open platform for the planet. And that has me smiling a lot.

0
Your rating: None

You have five minutes while waiting for a friend to meet you for lunch, so you find yourself shopping for a new pair of shoes. When your friend arrives, you put the phone away, but leave the web page open to help you remember what you found when you get home.

While you’re at work, you read a restaurant review for a new place you think sounds tasty. Come dinnertime, you grab your phone to pull up the address and location.

One night on your tablet, you’re browsing articles for a report you’re writing at work. Back at your desk the next day, you struggle in vain to remember what you searched for to find those articles. Why can’t you find them again?

Sound familiar? If you’re like most people, it probably does. Research from Google (PDF) shows that 90 percent of people start a task using one device, then pick it up later on another device—most commonly, people start a task on smartphone, and then complete it on the desktop. As you might expect, people regularly do this kind of device switching for the most common activities, like browsing the internet (81 percent) or social networking (72 percent). Certain categories like retail (67 percent), financial services (46 percent), and travel (43 percent) also seem to support this kind of sequential use of different devices.

Dual-screen or multi-screen use of devices gets a lot of attention, but we tend to focus on simultaneous usage—say, using tablets or smartphones while watching TV. Publishers, advertisers, and social networks are all actively trying to figure out how to deliver a good experience to users as they shift their attention between two screens at the same time. Sequential usage is every bit as common, but we rarely acknowledge this behavior or try to optimize for this experience.

When people start a task on one device and then complete it on another, they don’t want different content or less content, tailored for the device. They want the same content, presented so they can find it, navigate it, and read it. They imagine that their devices are different-sized windows on the same content, not entirely different containers.

What should we do to provide a good experience for users who want to complete the same task across more than one device?

Content parity

Let’s make device-switching the final nail in the coffin for the argument that mobile websites should offer a subset of the content on the “real” website. Everyone’s had the frustrating experience of trying to find content they’ve seen on the desktop that isn’t accessible from a phone. But the reverse is also a problem: users who start a task from a smartphone during a bit of free time shouldn’t be cut off from options they’d find back at their desktop.

Consistent navigation labels

When picking up a task on a second device, about half of users say they navigate directly to the website to find the desired information again. Users who are trying to locate the same information across a mobile site (or app) and a desktop site can’t rely on the same visual and spatial cues to help them find what they’re looking for. As much as possible, make it easy for them by keeping navigation categories and hierarchy exactly the same. There aren’t that many cases where we truly need to provide different navigation options on mobile. Most desktop navigation systems have been extensively tested—we know those categories and labels work, so keep them consistent.

Consistent search

About 60 percent of users say they’d use search to continue a task on another device. Businesses wondering whether “mobile SEO” is necessary should keep in mind that user tasks and goals don’t necessarily change based on the device—in fact, it’s often the identical user searching for the exact information that very same day. It’s frustrating to get totally different results from different devices when you know what you’re looking for.

Handy tools

Users have taught themselves tricks to make their transition between devices go more smoothly—about half of users report that they send themselves a link. Sites that don’t offer consistent URLs are guaranteed to frustrate users, sending them off on a quest to figure out where that link lives. Responsive design would solve this problem, but so would tools that explicitly allow users to save their progress when logged in, or email a link to the desktop or mobile version of a page.

Improved analytics

Mobile analytics is still in the dark ages. Tracking users between devices is challenging—or impossible—which means businesses don’t have a clear picture of how this kind of multi-device usage is affecting their sales. While true multi-channel analytics may be a ways off, organizations can’t afford to ignore this behavior. Don’t wait for more data to “prove” that customers are moving between devices to complete a task. Customers are already doing it.

It’s time to stop imagining that smartphones, tablets, and desktops are containers that each hold their own content, optimized for a particular browsing or reading experience. Users don’t think of it that way. Instead, users imagine that each device is its own window onto the web.

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.

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

  

Mobile users and mobile usage are growing. With more users doing more on mobile, the spotlight is on how to improve the individual elements that together create the mobile user experience.

The mobile user experience encompasses the user’s perceptions and feelings before, during and after their interaction with your mobile presence — be it through a browser or an app — using a mobile device that could lie anywhere on the continuum from low-end feature phone to high-definition tablet.

Creating mobile user experiences that delight users forces us to rethink a lot of what we have taken for granted so far with desktop design. It is complicated in part by mobile-specific considerations that go hand in hand with small screens, wide variations in device features, constraints in usage and connectivity, and the hard-to-identify-but-ever-changing mobile context.

Dissecting the mobile user experience into its key components gives us a conceptual framework for building and evaluating good mobile experiences, within the context of a user-centered approach to designing for mobile. These components shape the mobile user experience — including functionality, context, user input, content and marketing, among others.

The elements of mobile user experience

The relevance of these elements will change depending on the type of device (feature phone versus smartphone versus tablet) and the presentation interface (app versus Web). This article briefly describes each of these elements and elaborates on each with selected guidelines.

Functionality

This has to do with tools and features that enable users to complete tasks and achieve their goals.

Guidelines

  • Prioritize and present core features from other channels that have especial relevance in a mobile environment. For an airline, this includes flight statuses and flight check-ins. For cosmetic chain Sephora, it includes supporting in-store shopping via easy access to product reviews on mobile devices.
  • Offer relevant mobile-only functionality (like barcode scanning and image recognition), and enhance functionality using the capabilities of mobile devices where possible to engage and delight users. Old Navy’s app serves up surprise games or savings when users snap the logo in a store.
  • Ensure that fundamental features and content are optimized for mobile. For example, make sure the store locator shows the nearest stores based on the device’s location, and make the phone numbers click-to-call.
  • Include features that are relevant to the business category. For retail websites and apps, this would include product search, order status and shopping cart.
  • Offer key capabilities across all channels. Users who sign in should see their personalized settings, irrespective of the device or channel being used. If certain functionality is not offered on mobile, then direct users to the appropriate channel, as TripIt does to set up a personal network.

    TripIt directs users to the website for setting up a network

Additional Reading

Information Architecture

This has to do with arranging the functionality and content into a logical structure to help users find information and complete tasks. This includes navigation, search and labeling.

Guidelines

  • Present links to the main features and content on the landing page, prioritized according to the user’s needs. Mobile Design Pattern Gallery has examples of primary and secondary navigation patterns for mobile, many of which are vertical instead of horizontal as on desktop websites.
  • Enable mobile users to navigate to the most important content and functionality in as few taps or key presses as possible. Navigation optimized for small screens is usually broad and shallow instead of deep. While three clicks (or taps) is not the magic number, users need to be able to recognize that each tap is helping them complete their task. Every additional level also means more taps, more waiting for a page to load and more bandwidth consumed.
  • Address the navigation needs of both touchscreen and non-touchscreen users. When designing for touch, make sure the tap size of the navigation item is at least 30 pixels wide or tall. Provide keypad shortcuts for feature phones, so that users can enter, say, a number (0 to 9) to quickly access a link:

    Cater to feature phone users, as CNN does with access keys, not as Delta does by making the first action to be nine key presses downs
    Cater to feature phone users, as CNN does with access keys (left), not as Delta does by making the first action to be nine key presses downs (middle and right).

  • Provide navigational cues to let users know where they are, how to get back and how to jump back to the start. Mobile breadcrumbs are often implemented by replacing the “Back” button with a label showing users the section or category that they came from. For mobile websites, use standard conventions, such as a home icon that links back to the start screen, especially when navigation is not repeated on every screen.
  • Use concise, clear, consistent and descriptive labels for navigation items and links. While always a good practice, it becomes even more important on tiny mobile devices.

Additional Reading

Content

Otherwise known as “the stuff on your website” (as Lou Rosenfeld and Peter Morville refer to it in Information Architecture for the World Wide Web), content is the various types of material in different formats, such as text, images and video, that provide information to the user.

Guidelines

  • Present an appropriate and balanced mix of content to users (product information, social content, instructional and support content, marketing content).
  • Use multimedia when it supports the user’s tasks in a mobile context, adds value to the content or supports the goals of the website. Most of the time, multimedia content is best provided when the user is looking for distraction or entertainment (such as news or funny clips) or when it has instructional value (for example, how to use an app or new feature).
  • Always give the user control over multimedia content by not auto-starting video or sound, by allowing the user to skip or stop multimedia content and by being mindful of the bandwidth it takes up.
  • Ensure that content is mobile appropriate. Just as we had chunking guidelines when going from print to Web, copy should be written for shorter attention spans on mobile devices. Optimize images and media for the device; this means scaling down for smaller devices and making sure images are sharp enough for the new iPad.
  • Ensure that primary content is presented in a format supported on the target device. Even now, websites such as Volkswagen’s ask iOS users to download Flash.

    VW asks iPad users to download an unsupported Flash plugin

Additional Reading

Design

This has to do with the visual presentation and interactive experience of mobile, including graphic design, branding and layout.

Guidelines

  • Remember the sayings “Mobilize, don’t miniaturize” (popularized by Barbara Ballard) and “Don’t shrink, rethink” (of Nokia). Both make the point that mobile design should not just rehash the desktop design.
  • Design for glanceability and quick scanning. Glanceability refers to how quickly and easily the visual design conveys information.
  • Maintain visual consistency with other touchpoints and experiences (mobile, app, Web, print and real world) through the use of color, typography and personality. Identifying Amazon in the stack below is easy even though the brand name is not visible.

    Amazon's visual design is easily recognizable

  • Guide users from the initial and most prominent element of the design to other elements to help them complete their tasks. This is known as visual flow. A good design brings together visual elements as well as information architecture, content and functionality to convey the brand’s identity and guide the user.
  • Consider both portrait and landscape orientations in the design process. Devices increasingly support multiple orientations and automatically adjust to match their physical orientation. Maintain the user’s location on the page when they change orientation. Indicate additional or different functionality in the new orientation if applicable, as shown by ING:

    The ING app informs users about additional features in the landscape mode

Additional Reading

User Input

This has to do with the effort required to enter data, which should be minimized on mobile devices and not require the use of both hands.

Guidelines

  • Limit input to essential fields. Or, as Luke Wroblewski says in his book Mobile First, “When it comes to mobile forms, be brutally efficient and trim, trim, trim.” Limit registration forms to the minimum fields required, and use shorter alternatives where possible, such as a ZIP code instead of city and state. My favorite offender of this guideline is Volkswagen’s form to schedule a test drive; the mobile form has more required fields than the desktop version (the extra fields are highlighted below):

    Volkswagen's mobile form to schedule a test drive is more tedious than the desktop version

  • Display default values wherever possible. This could be the last item selected by the user (such as an airport or train station) or the most frequently selected item (such as today’s date when checking a flight’s status):

    United and NJ Transit use defaults to simplify user input

  • Offer alternate input mechanisms based on the device’s capabilities where possible. Apps take advantage of quite a few input mechanisms built into devices, including motion, camera, gyroscope and voice, but mobile websites are just starting to use some of these features, particularly geolocation.
  • Use the appropriate input mechanism and display the appropriate touch keyboard to save users from having to navigate their keyboard screens to enter data. Keep in mind that inputting data is more tedious on feature phones that have only a numeric keypad. For non-sensitive applications, allow users to stay signed in on their mobile device; and save information such as email address and user name because mobile phones tend to be personal devices, unlike tablets, which tend to be shared between multiple people.

    Use appropriate keyboard; examples from the iOS Developer Library

  • Consider offering auto-completion, spellcheck suggestions and prediction technology to reduce the effort required to input data and to reduce errors — with the ability to revert as needed. Disable features such as CAPTCHA where not appropriate.

Additional Reading

Mobile Context

A mobile device can be used at anytime, anywhere. The mobile context is about the environment and circumstances of usage — anything that affects the interaction between the user and the interface, which is especially important for mobile because the context can change constantly and rapidly. While we often focus on distractions, multitasking, motion, low lighting conditions and poor connectivity, it also includes the other extreme — think using a tablet in a relaxed setting over a fast Wi-Fi connection.

 The Context of Mobile Interaction
The Context of Mobile Interaction,” Nadav Savio

Guidelines

  • Use device features and capabilities to anticipate and support the user’s context of use. The iCookbook app allows users to walk through a recipe using voice commands — a nice feature when your hands are covered in batter!
  • Accommodate for changes in context based on the time of day and when the user is using the app. The Navfree GPS app automatically switches from day to night mode, showing low-glare maps for safer nighttime driving.

    GPS app sensing context

  • Use location to identify where the user is and to display relevant nearby content and offers. A Google search for “movies” on a mobile device brings up movies playing nearby and that day’s showtimes, with links to buy tickets online if available.
  • Leverage information that the user has provided, and respect their preferences and settings. After the first leg of a multi-leg flight, TripIt showed me the flight and gate information for my next flight, as well as how much time I had to kill. United’s app did no such thing, even though it knew much more about me. It could have shown me how to get from my current plane to the connecting flight and highlighted the location of the United Club along the way, where I could comfortably spend my two-hour wait, since it knew I was a member.
  • Default to the user experience most appropriate for the device (i.e. a mobile experience for small screens, and perhaps a desktop-like experience for tablets), but give users the option to have enhanced features. A big discussion on how to present this to the user recently took place, with Jakob Nielsen recommending a separate mobile website and Josh Clark arguing instead for a responsive design; yet others believe that Nielsen and Clark are both wrong.

Additional Reading

Usability

This is the overall measure of how well the information architecture, design, content and other elements work together to enable users to accomplish their goals.

Guidelines

  • Make it clear to the user what can be selected, tapped or swiped (this is known as affordance), especially on touchscreen devices. One of the big findings of Nielsen Norman Group’s usability studies of the iPad was that users didn’t know what was touchable or tappable. Another issue was swipe ambiguity: when the same swipe gesture means different things in different areas of a screen. Ensure that touchability is clear and that items such as links, icons and buttons are visibly tappable.
  • For touchscreen devices, ensure that touch targets are appropriately sized and well spaced to avoid selection errors. Also, place touch targets in the appropriate screen zones; for example, put destructive actions such as those for deletion in the “Reach” zone, as shown by Luke Wroblewski in his book Mobile First:

    Zones showing ease of access for right handed touch-screen use from Mobile First

  • Follow conventions and patterns to reduce the learning curve for users and to make the mobile experience more intuitive. Dedicated apps should follow platform-specific standards and guidelines. A comprehensive collection of links to official UI and UX guidelines is available in the article “UI Guidelines for Mobile and Tablet Web App Design” on Breaking the Mobile Web.
  • Ensure usability in variable conditions, including for daylight glare and changed angle of viewing and orientation, by paying attention to design elements like contrast, color, typography and font size.
  • Do not rely on technology that is not universally supported by your audience’s devices, including Java, JavaScript, cookies, Flash, frames, pop-ups and auto-refreshing. When opening new windows or transitioning from an app to the browser, warn users to avoid overwriting already open tabs.

Additional Reading

Trustworthiness

This relates to the level of confidence, trust and comfort that users feel when using a mobile website or app. According to a 2011 study by Truste and Harris Interactive, privacy and security are the top two concerns among smartphone users:

Privacy and security are the top two concerns among smartphone users

Guidelines

  • Do not collect or use personal information (such as location and contact list) from mobile devices without the explicit permission of the user. The first few months of this year have seen numerous reports of apps secretly copying smartphone address books, with watchdogs up in arms and users retaliating.
  • Make it easy for users to control how their personal information is shared in a mobile app by asking before collecting their location data and by allowing them to opt out of targeted advertising.
  • Clearly state your business practices (including for privacy, security and returns), and present them contextually (such as by displaying links to your privacy and security policies on the registration screen). The policies themselves should be accessible in a secondary section of the mobile user experience (such as the footer or a “More” tab). Reinforce credibility by displaying trusted badges, especially when users need to trust you with their personal or financial information.
  • Present policies appropriately on mobile devices by offering a concise summary and an option to email the entire policy. Privacy and security policies tend to be notoriously long and full of boring legalese that users often blindly click through to continue what they really want to do, so make it easy for users who are interested in the fine print.
  • Don’t break the user’s workflow when displaying legalese. Take them back to where they were before being interrupted, instead of making them start all over.

Additional Reading

Feedback

This has to do with the methods for attracting the user’s attention and displaying important information.

Guidelines

  • Minimize the number of alerts the app displays, and ensure that each alert offers critical information and useful choices. For a smile, look at Chris Crutchfield’s video on notification and alert overload.
  • Keep alerts brief and clear, explaining what caused the alert and what the user can do, along with clearly labeled buttons.
  • Notifications should be brief and informative, not interfere with anything the user is doing, and be easy to act on or dismiss.
  • Provide feedback and confirmation on screen without disrupting the user’s workflow.
  • If your app displays badges and status bar notifications, keep the badges updated and clear them only when the user has attended to the new information. Chase clears the notifications badge for its mobile app the moment the user visits the notification section, even before the user has seen which of their multiple accounts triggered the badge, forcing them to hunt through each account to see what triggered it.

Additional Reading

Help

This relates to the options, products and services that are available to assist the user in using the website or app.

Guidelines

  • Make it easy for users to access help and support options. Users commonly look for help in the footer of a mobile website and in the toolbar or tab bar of an app.
  • Offer multiple ways to get support, including options relevant in a mobile context, such as self-serve FAQs, live support via click-to-call, and near-real-time Direct Message tweets. Two financial service companies that actively offer support via Twitter are American Express and Citibank.
  • Present a quick introduction and short tutorial on using the app when it first launches, with options for the user to skip and view later.
  • When introducing new or unique functionality (such as when check depositing via mobile apps was first introduced), offer contextual help and tips to guide users the first time, and as a refresher for infrequently used functionality.
  • Offer help videos when appropriate, but allow the user to start, pause, stop and control the volume as they wish, and keep in mind the multimedia guidelines mentioned in the “Content” section above.

Additional Reading

Social

This relates to content and features that create a sense of social participation, that enable user interaction and that facilitate sharing on established social networks.

Guidelines

  • Create and maintain a presence on social networks (for example, a Facebook page) and local services (for example, a profile page on services such as Google Places, Bing Business Portal and Yahoo Local). These will be highlighted in search results and on location-based social networking services. In addition to your business’ name, include your physical address, phone number, URL and hours of operation.
  • Incorporate your social presence and activity into your website’s mobile experience by showing your recent activity and offering an easy way to follow or like you on these networks.
  • Integrate social networking features into your website’s mobile experience to make it easy for users to connect with their own social networks. This could be as simple as using APIs to enable social sharing, bookmarking, tagging, liking and commenting.
  • Invite users to generate content featuring your brand, product or service from their mobile device, offering some incentive in return. For example, the burger chain Red Robin could invite the user to share a picture of their child reading a school book at one of its locations to get a free milkshake.
  • Provide mobile offers that can be shared and go viral. American Express currently offers savings and discounts to users who sync their profiles on networks such as Facebook, Twitter and Foursquare to their credit card.
  • Apps that rely on social contributions from users should look at ways to seed content in a way that is useful and, eventually, self-sustaining. For example, the My TSA app has a user-contributed feature that shows the wait times at security checkpoints, but it often shows outdated information, even though airport staff post physical signs of wait times at some airports.

Additional Reading

Marketing

This has to do with the methods by which a user finds a website or app and the factors that encourage repeated usage.

Guidelines

  • Ensure findability by optimizing for mobile search and discovery, such as by keeping URLs short. If you have a separate mobile website, follow URL naming conventions (m.site.com or mobile.site.com). In mobile search results, provide quick access to location-based content (e.g. directions from one’s current location) and device-formatted options (e.g. click to call).

    Mobile optimized formatted information for UPS, but partially missing for Fedex
    Mobile-formatted information is optimized for UPS (left), but partially missing for FedEx (right).

  • “Quick response” (QR) codes should lead to a mobile-optimized landing page, instead of a traditional page that requires zooming or, worse still, to the website’s home page, from where the user has to hunt for information. As a side note, QR codes painted on buildings should be big and clear enough to be recognized and deciphered by mobile devices.
  • Email campaigns should include a link to view the message in a mobile-friendly format, which itself links to the relevant offer page formatted for mobile — unlike CVS/pharmacy, which takes users to its mobile home page.
  • Promote your app in other channels where possible (TV, print and in-store advertising), and offer incentives to download and use the app, usually in the form of discounts and savings. If your app has a price tag, attract users to buy it in an overcrowded market by offering a limited-time promotional price. Another option is to promote the app through the Free App A Day marketplace.
  • Prompt users to rate and review your app or to share it on social networks after they have used it, but give them the option to postpone or stop these prompts. This will not only generate word of mouth, but give you insight into what users like and don’t like about the app. “Taking Control of Your Reviews” by smalltech discusses the strategy of encouraging happy customers to post reviews and unhappy customers to email you feedback.

Additional Reading

Conclusion

Mobile user experience is still a developing field, and opportunities for improvement continue to emerge. We’ve presented an overview of the key elements of the mobile user experience, along with some guidelines to get started in each. Focusing on these individual elements will help us create great overall mobile user experiences for our users.

(al)

© Lyndon Cerejo for Smashing Magazine, 2012.

0
Your rating: None



This Q&A is part of a biweekly series of posts highlighting common questions encountered by technophiles and answered by users at Stack Exchange, a free, community-powered network of 80+ Q&A sites.

Alfredo O asks:

I'm in the early stages of developing an application geared toward business use, but I'm unsure whether I should develop a web-based app or a native mobile app.

Developing a separate mobile app seems to mean more maintenance—any time a change goes through online, I'll have to make sure the update carries over to the app. But I know only native apps can utilize certain features such as GPS and digital rights management, and native apps don't require an Internet connection.

Ultimately, what is the best way to go?

Read the rest of this article...

Read the comments on this post

0
Your rating: None

I've been an eBay user since 1999, and I still frequent eBay as both buyer and seller. In that time, eBay has transformed from a place where geeks sell broken laser pointers to each other, into a global marketplace where businesses sell anything and everything to customers. If you're looking for strange or obscure items, things almost nobody sells new any more, or grey market items for cheap, eBay is still not a bad place to look.

At least for me, eBay still basically works, after all these years. But one thing hasn't changed: the eBay website has always been difficult to use and navigate. They've updated the website recently to remove some of the more egregious cruft, but it's still way too complicated. I guess I had kind of accepted old, complex websites as the status quo, because I didn't realize how bad it had gotten until I compared the experience on the eBay website with the experience of the eBay apps for mobile and tablet.

eBay Website

Ebay-web

eBay Mobile App

Ebay-iphone-app

eBay Tablet App

Ebay-ipad-app

Unless you're some kind of super advanced eBay user, you should probably avoid the website. The tablet and mobile eBay apps are just plain simpler, easier, and faster to use than the eBay website itself. I know this intuitively from using eBay on my devices and computers, but there's also usability studies with data to prove it, too. To be fair, eBay is struggling under the massive accumulated design debt of a website originally conceived in the late 90s, whereas their mobile and tablet app experiences are recent inventions. It's not so much that the eBay apps are great, but that the eBay website is so very, very bad.

The implied lesson here is to embrace constraints. Having a limited, fixed palette of UI controls and screen space is a strength. A strength we used to have in early Mac and Windows apps, but seem to have lost somewhere along the way as applications got more powerful and complicated. And it's endemic on the web as well, where the eBay website has been slowly accreting more and more functionality since 1999. The nearly unlimited freedom that you get in a modern web browser to build whatever UI you can dream up, and assume as large or as small a page as you like, often ends up being harmful to users. It certainly is in the case of eBay.

If you're starting from scratch, you should always design the UI first, but now that we have such great mobile and tablet device options, consider designing your site for the devices that have the strictest constraints first, too. This is the thinking that led to mobile first design strategy. It helps you stay focused on a simple and uncluttered UI that you can scale up to bigger and beefier devices. Maybe eBay is just going in the wrong direction here; design simple things that scale up; not complicated things you need to scale down.

Above all else, simplify! But why stop there? If building the mobile and tablet apps first for a web property produces a better user experience – why do we need the website, again? Do great tablet and phone applications make websites obsolete?

Why are apps better than websites?

  1. They can be faster.
    No browser overhead of CSS and HTML and JavaScript hacks, just pure native UI elements retrieving precisely the data they need to display what the user requests.
  2. They use simple, native UI controls.
    Rather than imagineering whatever UI designers and programmers can dream up, why not pick from a well understood palette of built-in UI controls on that tablet or phone, all built for optimal utility and affordance on that particular device?

  3. They make better use of screen space.
    Because designers have to fit just the important things on 4 inch diagonal mobile screens, or 10 inch diagonal tablet screens, they're less likely to fill the display up with a bunch of irrelevant noise or design flourishes (or, uh, advertisements). Just the important stuff, thanks!

  4. They work better on the go and even offline.
    In a mobile world, you can't assume that the user has a super fast, totally reliable Internet connection. So you learn to design apps that download just the data they need at the time they need to display it, and have sane strategies for loading partial content and images as they arrive. That's assuming they arrive at all. You probably also build in some sort of offline mode, too, when you're on the go and you don't have connectivity.

Why are websites better than apps?

  1. They work on any device with a browser.
    Websites are as close to universal as we may ever get in the world of software. Provided you have a HTML5 compliant browser, you can run an entire universe of "apps" on your device from day zero, just by visiting a link, exactly the same way everyone has on the Internet since 1995. You don't have to hope and pray a development community emerges and is willing to build whatever app your users need.

  2. They don't have to be installed.
    Applications, unlike websites, can't be visited. They aren't indexed by Google. Nor do applications magically appear on your device; they must be explicitly installed. Even if installation is a one-click affair, your users will have to discover the app before they can even begin to install it. And once installed, they'll have to manage all those applications like so many Pokemon.

  3. They don't have to be updated.
    Websites are always on the infinite version. But once you have an application installed on your device, how do you update it to add features or fix bugs? How do users even know if your app is out of date or needs updating? And why should they need to care in the first place?

  4. They offer a common experience.
    If your app and the website behave radically differently, you're forcing users to learn two different interfaces. How many different devices and apps do you plan to build, and how consistent will they be? You now have a community divided among many different experiences, fragmenting your user base. But with a website that has a decent mobile experience baked in, you can deliver a consistent, and hopefully consistently great, experience across all devices to all your users.

I don't think there's a clear winner, only pros and cons. But apps will always need websites, if for nothing else other than a source of data, as a mothership to phone home to, and a place to host the application downloads for various devices.

And if you're obliged to build a website, why not build it out so it offers a reasonable experience on a mobile or tablet web browser, too? I have nothing against a premium experience optimized to a particular device, but shouldn't all your users have a premium experience? eBay's problem here isn't mobile or tablets per se, but that they've let their core web experience atrophy so badly. I understand that there's a lot of inertia around legacy eBay tools and long time users, so it's easy for me to propose radical changes to the website here on the outside. Maybe the only way eBay can redesign at all is on new platforms.

Will mobile and tablet apps kill websites? A few, certainly. But only the websites stupid enough to let them.

[advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you.

0
Your rating: None

Make the logo smaller. Photo: Ariel Zambelich/Wired.com

Web usability guru Jakob Nielsen has come under fire for his latest suggestions on building mobile websites. Nielsen’s controversial advice can be distilled down to this nugget: “good mobile user experience requires a different design than what’s needed to satisfy desktop users. Two designs, two sites, and cross-linking to make it all work.”

Among the many negative responses to Nielsen’s latest Alertbox post is that of web developer and mobile specialist Josh Clarke, who calls Nielsen’s questionable advice “180-degrees backward.”

Indeed, much of Nielsen’s advice may seem like a shockingly bad idea not just to developers, but to anyone who uses a mobile device to browse the web.

This isn’t the first time Nielsen has taken a contrarian stand about mobile websites. Last year he suggested that a mobile-first approach to design was wrong because “PCs will remain important,” which is, at best, a false dilemma since a mobile-first design doesn’t mean ignoring the desktop. Just because you’re focused on the future doesn’t mean you’re ignoring the past.

Nielsen’s latest advice has similar false dichotomies. For example much of Nielsen’s advice rests on the premise that a single site cannot serve the wants and needs of both mobile and desktop users. In fact you don’t need to choose between mobile and desktop, the page can adapt and serve the needs of both users. There are plenty of examples of sites that do just that with responsive designs. To be sure there are plenty of websites that claim to be mobile-friendly and obviously aren’t. But that doesn’t mean the solution is to toss out the whole idea of responsive design and go back to separate websites for every device.

In fact what Nielsen considers one of the “main guidelines” for a successful mobile website is something that many people would probably consider the most irritating thing about mobile sites: “If mobile users arrive at your full site’s URL, auto-redirect them to your mobile site” (emphasis in original).

The problem with this advice is that, as Clark puts it, “Nielsen is confusing device context with user intent.” In other words, just because someone visits your site on a small screen doesn’t mean they won’t want access to all the same things they would see on a slightly larger screen. It may be necessary to rearrange elements for smaller screens, but hiding them is a bad idea.

“All that we can really know about mobile users is that they’re on a small screen, and we can’t divine user intent from that,” writes Clark.

Nielsen, however, does just that, divining that — because a user has a small screen — they will want to do less on your site. He suggests you serve up a limited site and then offer a link to the full site “for those (few) users who need special features that are found only on the full site.”

We suggest you don’t do that. You can do better than that.

You can use responsive design patterns to make sure that the same content is always available, but that the experience is tailored to the device at hand. In other words, responsive design means your site works just as well on mobile as it does on the desktop. If it doesn’t that means something is wrong with your site, not the whole approach. Sure, there will be times when a separate mobile site is the right way to go, but those times will likely be few and far between.

Nielsen’s argument is based on copious research and we have no doubt he found plenty of horribly designed websites that completely fail on mobile devices to justify his recommendations. But just because Nielsen is finding a lot of poorly made mobile websites does not, as Clark writes, “mean we should punt on creating great, full-featured mobile experiences.”

0
Your rating: None