Mobile Usability
Jakob Nielsen and Raluca Budiu New Riders 1249 Eighth Street Berkeley, CA 94710 Find us on the Web at www.newriders.com To report errors, please send a note to errata@peachpit.com New Riders is an imprint of Peachpit, a division of Pearson Education. Copyright © 2013 by The Nielsen Norman Group Senior Editor: Susan Rimerman Copy Editor: Anne Marie Walker Proofer: Emily K. Wolman Indexer: James Minkin Production Editor: Tracey Croom Composition: Danielle Foster Cover Design: Peachpit Press Notice of Rights All rights reserved. No part of this book may be reproduced or transmitted in any form by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher. For information on getting permission for reprints and excerpts, contact permissions@peachpit.com. Notice of Liability The information in this book is distributed on an “As Is” basis, without warranty. While every precaution has been taken in the preparation of the book, neither the authors nor Peachpit shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the instructions contained in this book or by the computer software and hardware products described in it.

Trademarks Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and Peachpit was aware of a trademark claim, the designations appear as requested by the owner of the trademark. All other product names and services identified throughout this book are used in editorial fashion only and for the benefit of such companies with no intention of infringement of the trademark. No such use, or the use of any trade name, is intended to convey endorsement or other affiliation with this book. ISBN-13: 978-0-321-88448-0 ISBN-10: 0-321-88448-5 987654321 Printed and bound in the United States of America

For Hannah. —Jakob For Matei and Mihai, with love. —Raluca

Acknowledgments
We have drawn from several Nielsen Norman Group projects in writing this book. Janelle Estes ran studies of how users read from mobile devices, and Marieke McCloskey ran studies on how people read from tablets and e-readers, and also helped with some of the logistics for our Dutch study. Hoa Loranger, Kara McCain, Amy Schade, and Kathryn Whitenton helped with several of our usability studies, and Kara McCain also redesigned several screens that are shown in this book as examples of improved usability. Luice Hwang set up facilities for a large number of studies in other states and countries. Susan Pernice managed participant recruiting for studies in Australia and Netherlands. And the rest of the Nielsen Norman Group, including Jen Cardello, Susan Farrell, Garrett Godlfield, Don Norman, Kara Pernice, and Bruce Tognazzini, shared with us their personal stories and insights about mobile apps and websites. The visioneering concepts shown in Chapter 6 were created by a team that included Bruce Tognazzini, Amy Gallaher, and Shuli Gilutz. Marc Ramsay ran our WAP phones studies in 2000. Scott Butler and the Ovo Studios generously provided us with a mobile device camera that we used for some of our studies. Hannah Kain, Aaron Katske, and Brandon Marugg helped with facilities for many of our research studies in California. Cristian Lupsa and the magazine Decât o revista ˘ let us use their location and amenities during our study in Romania, and Eric Chow recruited participants for our Hong Kong study. Mihai Budiu lent us his phone for our Windows Phone 7 studies, kindly offered technical support and advice, and contributed additional insights. And finally, a special thanks to our editors Susan Rimerman, Anne Marie Walker, and Tracey Croom for all their hard work with the manuscript.

Acknowledgments

iii

About the Authors
Jakob Nielsen

Jakob Nielsen, Ph.D., is a principal of Nielsen Norman Group. He is the founder of the “discount usability engineering” movement, which emphasizes fast and efficient methods for improving the quality of user interfaces. Nielsen, noted as “the world’s leading expert on Web usability” by U.S. News and World Report and “the next best thing to a true time machine” by USA Today, is the author of the best-selling book Designing Web Usability:The Practice of Simplicity (New Riders Publishing, 2000), which has sold more than a quarter of a million copies in 22 languages. His other books include Usability Engineering (Morgan Kaufmann, 1993); with Robert L. Mack, Usability Inspection Methods (Wiley, 1994); Multimedia and Hypertext:The Internet and Beyond (Morgan Kaufmann, 1995); International User Interfaces (Wiley, 1996); with Marie Tahir, Homepage Usability: 50 Websites Deconstructed (New Riders Publishing, 2001); with Hoa Loranger, Prioritizing Web Usability (New Riders Publishing, 2006); and with Kara Pernice, Eyetracking Web Usability (New Riders Publishing, 2010). Nielsen’s Alertbox column on Web usability at www.useit.com has been published on the Internet since 1995 and has approximately 200,000 readers. From 1994 to 1998, Nielsen was a Sun Microsystems Distinguished Engineer. His previous affiliations include Bell Communications Research, the Technical University of Denmark, and the IBM User Interface Institute. He has been awarded 80 United States patents, mainly on ways of making the Internet easier to use. Nielsen holds a Ph.D. in human-computer interaction from the Technical University of Denmark.

iv

Mobile Usability

Raluca Budiu

Raluca Budiu, Ph.D., is a user-experience specialist with Nielsen Norman Group. There she conducts usability research; consults with large companies from a variety of industries; and presents tutorials on mobile usability, usability of touch devices, cognitive psychology for designers, and principles of human-computer interaction. She coauthored research reports on mobile usability, iPad usability, and the usability of websites for children. From 2004 to 2007, Budiu worked at Xerox PARC doing research in human-computer interaction. She also explored new ways of measuring information scent, and conducted research on interfaces for social bookmarking systems and on the cognitive benefits of tagging. Budiu was also a user researcher at Microsoft Corporation, where she explored future directions and made strategic recommendations for incorporating user-generated content and social-Web features into MSN. Before PARC, Budiu carried out research in psycholinguistics and cognitive science, building computational models of how people understand language. Budiu has authored more than 20 articles and conference presentations on human-computer interaction, psychology, and cognitive science. She holds a Ph.D. from Carnegie Mellon University.

About the Authors

v

Contents
Preface Why Mobile Is Different Screen Shots Are Examples Only 1: Our Research: How We Ran the Usability Studies Diary Studies Usability Testing Qualitative User Research 2: Mobile Strategy Usability Varies by Mobile Device Category A Separate Mobile Experience Is Best Mobile Site vs. Full Site Mobile-optimized Sites Why Full Sites Don’t Work for Mobile Use Mobile Is Less Forgiving than Desktop Responsive Design Usability Guidelines Are Rarely Dichotomies Mobile Sites vs. Apps: The Coming Strategy Shift Current Mobile Strategy: Apps Best Future Mobile Strategy: Sites Best When Will the Strategy Shift Happen? Mobile Apps Mobile Apps Are Intermittent-use Apps Half-speed Progress, But Hope Ahead 3: Designing for the Small Screen Wasted Mobile Space Chrome Overloaded vs. Generic Commands Case Study: Optimizing a Screen for Mobile Use Typing on Mobile Download Times Early Registration Must Die Example: Pizza Ordering Application Case Study: The WSJ Mobile App Confusing Startup Screen Degrading the Brand A Better Design A New WSJ Workflow Better Next Year 4: Writing for Mobile Mobile Content Is Twice as Difficult Why Mobile Reading Is Challenging vii vii x 1 3 3 5 9 15 17 18 20 21 23 28 33 34 34 35 39 41 41 44 49 52 55 63 67 76 79 81 84 86 89 90 91 94 95 101 102 104

vi

Mobile Usability

If in Doubt, Leave It Out Filler = Bad Old Words Are Best Bylines for Mobile Content? Defer Secondary Information to Secondary Screens Example 1: Mobile Coupons Example 2: Progressive Disclosure in Wikipedia Deferring Information = Initial Info Read More Mini-IA: Structuring the Information About a Concept Linear Paging? Usually Bad Alphabetical Sorting Must (Mostly) Die Example: Usage-relevant Structure Usage-driven Structure 5: Tablets and E-readers iPad Usability Tablets Are Shared Devices What Are iPads Used For? The Triple Threat of iPad Design Inconsistent Interaction Design The Print Metaphor Card Sharks vs. Holy Scrollers Swipe Ambiguity TMN: Too Much Navigation Splash Screens and Startup Noises Orientation Toward a Better iPad User Experience Kindle Usability Kindle: The E-reader Kindle Fire Usability 6: Looking Toward the Future Transmedia Design for the Three Screens PCs Will Remain Important The Third Screen: TV Transmedia User Experience Beyond Flatland In the Future, We’ll All Be Harry Potter Next-generation Magic Don’t Harm the Muggles Appendix: A Bit of History Field Study in 2000 WAP Doesn’t Work Déjà Vu: 1994 All Over Again Mobile Killer App: Killing Time Index

108 109 111 112 116 116 118 120 123 123 124 127 129 131 132 136 137 138 146 151 153 158 159 165 166 168 168 169 172 181 182 183 183 184 186 189 189 190 193 195 195 196 198 199

Contents

vii

Preface
The topic of this book is simple: how to design the best websites and apps for mobile devices and tablets. How is it different from the many other books on this topic? It is based on empirical evidence on how regular users actually use such user interfaces. A key lesson from the past decades of usability is that you cannot trust your own instincts regarding what will be easy for normal people. The fact that you’re reading this book proves that you are very different from the average mobile user. Repeat after us: “I am not the target audience” (unless you’re designing an app for designers). Most other books on mobile design describe the authors’ personal preferences: what they think is good. This can certainly be interesting information, but it’s safer to rely on actual usability research with more representative users. Chapter 1 describes how we conducted this research.You can skip it if you simply want to know what we discovered but not how we ran the studies. However, the chapter is short, so we recommend that you read it anyway. Who knows, maybe you will be inspired to conduct your own user testing when you see how easy it is to get real data. Chapter 2 is about the question that should be addressed before doing any mobile design: Should you even have a mobile site or app? Chapters 3 and 4 are the meat of the book: how to design for mobile devices and how to develop content for the small screen. Chapter 5 applies these concepts further to the larger tablet screens. Chapter 6 presents a broader perspective beyond the current flat touch screens, and the appendix takes a look back at the pre-iPhone phones.

Why Mobile Is Different
In 2012 the analytics company Monetate released a study of 100 million site visits across its e-commerce clients. Conversion rates differed dramatically, depending on which device was used to access a site, as shown in the following table:
Device Desktop computer Mobile phone Tablet Conversion Rate 3.5% 1.4% 3.2%

viii

Mobile Usability

The definition of “conversion rate” is simple. It’s the percentage of visiting users who end up taking a desired action. On e-commerce sites—such as those analyzed in the table—it’s even easier to understand conversion, because the “desired action” is to buy something. Thus a conversion rate of 3 percent means that of every 100 people who arrive at the site, 3 turn into paying customers and 97 leave without buying anything.

It’s clear that mobile users bought much less than people sitting at their PC. It’s also interesting that the conversion rates of the tablet users were much closer to the desktop users than to the phone users. As you’ll see in Chapter 5, this matches our usability findings, because we have also seen that browsing websites on tablets (like the iPad) is much easier than it is to use websites on mobile phones. What should we make of the huge difference in conversion rates between desktop computers and mobile phones? There are at least two different possible conclusions:
■■

The mobile user experience must be horrible. (This is in fact what we find in user testing.) Therefore there are fortunes to be made if companies would only design mobile-optimized sites that are easier to use for mobile users. After all, mobile sales could be 2.5 times greater if mobile sites were as easy to use as desktop sites. It’s not worth investing in mobile design, because mobile users don’t account for very much business. Mobile phones are fine for frivolous tasks like checking sports scores and posting Facebook updates but not for higher-value tasks.

■■

Both conclusions are reasonable. As we discuss in Chapter 2, some companies shouldn’t bother designing for mobile. But many companies should improve their mobile design to better match mobile usability guidelines, even if they don’t currently get a lot of business from mobile users. It’s quite likely that the small amount of business is caused by a low conversion rate, which again is caused by a design that doesn’t match the special mobile needs. So what are those special mobile usability issues? To some extent, many are not that different from the regular usability issues we have discussed in our many previous books about Web usability. The main difference is that each guideline is even more crucial for mobile. For example, when we discuss writing for the Web, we’ve always said to be brief and to get straight to the point at the top of the page. Many users will never see the bottom of a Web page if the top of the page doesn’t immediately communicate its relevance for the user’s current problem. This guideline is equally true for desktop design and for mobile design. But it’s stricter for mobile. On the small screen, text shouldn’t just be short—it should be ultra-short. And the “top of the page” means a much smaller area on mobile. There are two ways to consider whether mobile and desktop user experience issues are different. First, we can empirically say for certain that there is a measurable difference between the two classes of
Preface

ix

devices, as shown by the conversion data in the preceding table and by the user testing data we present in this book. Second, it just makes good common sense to design differently for highly different devices. In the early days of the Web, we had to explain why designing Web pages was not the same as designing printed magazines or brochures. By now most people have probably come to realize that print and online are distinct media forms and require separate design approaches. Similarly, there are many differences between mobile and desktop use, such as small versus big screen, on the move versus stationary, touch versus mouse, wireless (and sometimes spotty) connectivity versus faster wired Internet, and so on.

Screen Shots Are Examples Only
We can tell you right now what the customer reviews in various online bookstores will say about this book two years from now. Many reviewers will complain that the screen shots are very old. Others will say that it’s not fair to criticize companies for the way their mobile sites looked before they were redesigned (as most will hopefully be by then). In fact, even if you bought this book the day it was published, you might feel the same: It’s not fair to criticize a design that has been improved while the book was being edited and printed. The mobile field moves fast enough that many of the sites and apps shown here will surely be out in new releases by the time you lay your eager hands on a freshly printed book. But let’s make one thing clear: We don’t show a screen shot to criticize the owners or designers of that site. This is not a consumer review of best mobile sites or advice for what apps to install on your phone to have a good time. We don’t even care whether a specific site is good or bad, because we have no vested interest either way. We’re always happy to see sites improve, because that shows uptake of our usability findings, but if a design stays the same—or gets worse— it’s no skin off our nose. We include screen shots in this book to serve as examples of our usability findings. If we expended our entire page count on elaborate discussions of abstract principles, we would have no readers. Snooze. It’s a well known, human-factors principle from instructional design that specifics communicate better than abstractions. We’re simply

x

Mobile Usability

following our own guidelines when we try to show you what we mean instead of purely telling you. A given screen shot remains just as good of an example of a usability principle even if the company behind that site came to its senses and improved the design after we grabbed the image. As a meta-example (an example of an example), let’s say that we included a picture of Apple Computer’s rainbow-striped logo from 1976 as an example of how you might employ many different colors in a logo. Well, Apple changed to a monochrome logo in 1998, but that doesn’t mean that all pictures of its 1976 should be removed from discussions of how color works in logos. In fact, sometimes older examples are better examples than newer ones if they more clearly show the underlying principle. Some usability mistakes, fortunately, are becoming so rare that they’re found mainly on obscure sites that make many other design errors in the same screen, making for more confused examples. But we still must warn against usability problems that have become rare because there’s always somebody who’s ready to introduce a bad design that revives the mistake. Case in point: We had almost eradicated splash screens from the Web after a decade-long campaign against this user-hostile design idea. No big corporation or best-selling e-commerce site will put a Flash intro in front of its homepage these days. But we’ve tested several mobile apps that reintroduced this user experience sin. Sure enough, our test users complained just as bitterly about these new designs as the last generation of users did about Flash intros back in 2000. To misquote a famous saying, the price of good user experience is eternal vigilance. Old mistakes will come back to bite you (and your customers) if you don’t know about them. If you designed any of the screen shots we use in this book, rest assured that we don’t mean you any harm. We’re not complaining about you. We know that commercial design projects are nothing but one compromise after the next, and that design decisions are often made by old-school managers who don’t understand interaction design. The examples have no deeper meaning other than this: They make our usability findings concrete so that you can see some specific user interface designs that average people will have an easy or a difficult time using. —Jakob Nielsen and Raluca Budiu

Preface

xi

102 Mobile Content Is Twice as Difficult
• Cloze Test • Cloze Test Solution— Don’t Peek • Why Mobile Reading Is Challenging

116 Defer Secondary Information to Secondary Screens
• Example 1: Mobile Coupons • Example 2: Progressive Disclosure in Wikipedia • Deferring Information = Initial Info Read More

123 Mini-IA: Structuring the Information About a Concept
• Linear Paging? Usually Bad • Alphabetical Sorting Must (Mostly) Die • Example: Usagerelevant Structure • Usage-driven Structure

108 If in Doubt, Leave It Out
• Filler = Bad • Ditch the Blah-blah Text • Old Words Are Best • Bylines for Mobile Content? • Author Bios Dos and Don’ts

4: Writing for Mobile

We’ve run many user studies, watching people read information on mobile devices. Our research included mobile websites, apps, and email newsletters. Across all formats, there’s one indispensable element: focus. Of course, there are many other points to consider, but this one issue is the main usability guideline for mobile content: When you’re writing for mobile users, focus their attention on the essential content.

For full details of the research study discussed in this section, please see R.I. Singh, M. Sumeeth, and J. Miller: “Evaluating the Readability of Privacy Policies in Mobile Environments,” International Journal of Mobile Human Computer Interaction, vol. 3, no. 1 (January– March 2011), pp. 55–78.

As discussed in the next section, research has shown that it’s 108 percent harder to understand information when reading from a mobile screen. Content comprehension suffers when you’re looking through a peephole, because there’s little visible context. The less you can see, the more you have to remember, and human short-term memory is notoriously weak.

Mobile Content Is Twice as Difficult
Research by R.I. Singh and colleagues from the University of Alberta shows that it’s much harder to understand complicated information when you’re reading through a peephole. Singh and colleagues ran a Cloze test on the privacy policies of ten popular websites: eBay, Facebook, Google, Microsoft, Myspace, Orkut, Wikipedia, WindowsLive,Yahoo!, and YouTube. We did a quick analysis of Facebook’s privacy policy, which features:
■■

5,789 words, or 35 times the number of words users read during an average page visit. 13th-grade reading level, so only people with a year or more of university would find the text easy to read. Nicely formatted for Web reading, including a good use of subheads, bulleted lists, and highlighted keywords in keeping with guidelines for writing for the Web. (That said, these guidelines also call for short text and an 8th-grade reading level when targeting a broad consumer audience, not just Harvard students.)

■■

■■

In any case, there’s no doubt that privacy policies count as complicated Web content.
The study didn’t use an actual iPhone, but because users didn’t perform navigation or any interactions other than reading and scrolling, the specific device shouldn’t impact the comprehension results.

In Singh’s study, 50 test participants completed Cloze tests while reading the privacy policies on either a desktop-sized screen or an iPhone-sized screen. Here are the results:
■■ ■■

Desktop screen. 39.18 percent comprehension score Mobile screen. 18.93 percent comprehension score

Test scores must be 60 percent or higher for text to be considered easy to understand. Even while reading from a desktop screen, users achieved only two-thirds of the desired comprehension level, showing that privacy policies do tend to be overly complicated.

102

Mobile Usability

Cloze Test
The Cloze test is a common empirical comprehension test. It works as follows: 1. Replace every Nth word in the text with blanks. A typical test uses N = 6, but you can make the test easier by using a higher N value. 2. Ask your test participants to read the modified text and fill in the blanks with their best guesses as to the missing words. Each person should work alone. 3. The score is the percentage of correctly guessed words. Because you’re testing comprehension rather than spelling skills, synonyms and misspellings are allowed. If users get 60 percent or more right on average, you can assume the text is reasonably comprehensible for the specified user profile employed to recruit test participants. There’s a clear difference between readability scores and comprehension scores:
■■

■■

Readability is a property of the actual text and predicts the education level typically needed for people to read the content without undue difficulty. Comprehension is a combined property of the text and a specific user segment, and indicates whether this target audience actually understands the material’s meaning.

Here’s an example using a paragraph from Facebook’s privacy policy: Site activity information. We keep {1}______ of some of the actions {2}______ take on Facebook, such as {3}______ connections (including joining a group {4}______ adding a friend), creating a {5}______ album, sending a gift, poking {6}______ user, indicating you “like” a {7}______, attending an event, or connecting {8}______ an application. In some cases {9}______ are also taking an action {10}______ you provide information or content {11}______ us. For example, if you {12}______ a video, in addition to {13}______ the actual content you uploaded, {14}______ might log the fact that {15}______ shared it. (To see the solution, turn the page.) The full text—before inserting the blanks—scored at a 14th-grade reading level, corresponding to having completed two years of university. Thus if you’re a typical, smart, college-educated reader, you can probably understand the paragraph and complete the Cloze test. Still, this is a higher reading level than what’s required for much of the younger Facebook audience. Most teenage users need far easier text, and even college students prefer non-college level text when they’re online—leisure sites shouldn’t feel like textbooks.

4: Writing for Mobile

103

Cloze Test Solution—Don’t Peek
Don’t peek if you want a go at solving the Cloze test on the previous page on your own. Here are the missing words from the sample paragraph: {1} track {2} you {3} adding {4} or {5} photo {6} another {7} post {8} with {9} you {10} when {11} to {12} share {13} storing {14} we {15} you

Did you get at least nine of these right (corresponding to 60%)? If so, you can probably comprehend the full text fairly easily. If you got a lower score, that doesn’t prove that you’re stupid or that the text is densely written. The problem is likely to be a lack of contextual knowledge of Facebook. For example, the word “poking” is generally easy enough to understand, but its meaning in the Facebook privacy policy context is completely incomprehensible unless you’re a user (which is OK, because any given text needs to be comprehensible only to the target audience).

Why Mobile Reading Is Challenging

User comprehension scores on the Cloze test were 48 percent of the desktop level when using the iPhone-sized screen. That is, it’s roughly twice as hard to understand complicated content when reading on the smaller screen. Why? In this case, people were reading only a single page of information, and they were shown that page as part of the study without having to find it. Thus navigation difficulties or other user interface issues cannot explain the increased difficulty. Also, users were tested in a lab, so there were no issues related to walking around with the phone or being disturbed by noises or other environmental events. (In the real world, such distractions and degradations of the user experience further reduce people’s ability to understand mobile phone content during true mobile use.) The only reason mobile scored lower than desktop is the screen size, because that was the only difference in the study conditions.

104

Mobile Usability

A smaller screen reduces comprehension for two reasons:
■■

Users can see less at any given time. Thus users must rely on their highly fallible memory when they are trying to understand anything that’s not fully explained within the viewable space. Less context = less understanding. Users must move around the page more, scrolling to refer to other parts of the content instead of simply glancing at the text. Scrolling introduces three problems:
■■ ■■

■■

It takes more time, thus degrading memory. It diverts attention from the problem at hand to the secondary task of locating the required part of the page. It introduces the new problem of reacquiring the previous location on the page.

■■

In Figure 4.1 you can see an article from the app How Stuff Works. The article spreads across multiple screens; to follow the details in the text, users must remember or refer back to a diagram shown on a different screen.
Figure 4.1 The How Stuff Works app on iPhone: (A) Diagram of the different camera parts and (B) the explanation of how the camera works refers to the parts in the diagram. Users must go back to the diagram to understand the explanation.

A

B

4: Writing for Mobile

105

Figure 4.2 Lonely Planet’s app for iPhone anchored the title of its article, thus reducing the effective screen space.

Because a small screen impairs comprehension, it’s important to make sure that it’s used optimally and not occupied with unnecessary or redundant information. For instance, Lonely Planet’s choice (Figure 4.2) to make the title of the article sticky reduces the effective screen space without adding extra value to the user. Whereas this typically is recommended for e-commerce apps (where the “Buy now” button needs to be visible at all times in case users make up their mind as they scan through the product information—see Figure 4.11 and Figure 4.12 later in this chapter), it doesn’t make sense for touring guide information. It makes even less sense when the title is as devoid of content as “Hello, Amsterdam” is. (See also Figure A.1 in the Appendix for an example of how we discovered this mobile design principle way back in 2000.) Because comprehension is more difficult on mobile, it’s imperative that mobile content be easy to read and scan. Roundabout, fluffy writing should be replaced with direct and concise content that is formatted for scannability. Let’s look at some examples of good and bad writing and formatting. In Figure 4.3., Teavana is overly wordy and suffers from poor and buggy formatting: The Health Info paragraph has no punctuation and is preceded by the meaningless-to-the-user FTGOP-2(SPECIAL).

106

Mobile Usability

Figure 4.3 (Left) Teavana app for iPhone: Tea description page. Not only is the description in the first paragraph relatively hard to read due to the multiple clauses per sentence and the many adjectives, but the formatting is buggy. Figure 4.4 (Right) OSHA Heat Safety Tool app for Android.

In contrast, OSHA (Figure 4.4) deserves a prize for concise, scannable writing for mobile: Emergency information needs to be read fast and understood easily, and the bullet points and keywords help with that. However the illustrations are just decorative: It is unlikely that they can help users identify the corresponding condition. In general, bullet points make the information more scannable (Figure 4.5). In the Recalls.gov app (Figure 4.5A), the information is easy to read; the main points are bolded and attract the eye. (The use of the “previous” and “next” buttons at the top of the screen to navigate to a different article is less fortunate, because “next” and “previous” are low information-scent labels.) However too much space between bullet points can make the page look less structured, as in the HSN example (Figure 4.5B). Additionally, the table-withoutborders format makes it hard for the user to know which description goes with each option. And the brand description under the first blue sentence is completely unnecessary on mobile: It does not focus on the product facts. Brand information is better delegated to a secondary page.

4: Writing for Mobile

107

Figure 4.5 Bullets make the small page more scannable: (A) Recalls.gov app for Android and (B) HSN app for Android.

A

B

If in Doubt, Leave It Out
Our research on how users read on mobile devices has uncovered something of a paradox:
■■

Killing time is the killer app of mobile. As we’ve seen since our first mobile usability studies in 2000, killing time is the perfect match for mobile devices because they’re readily available when users are waiting around for something to happen. Favorite time wasters include gossip, games, and sports. But even a seemingly serious task, like checking the stock market, is often no more than a time-killing episode in which users look up the current index numbers with no intent to trade. Mobile users are in a hurry and get visibly angry at verbose sites that waste their time. Also, it’s twice as hard to understand content on small mobile devices as it is on bigger desktop screens, making wordy content even more despised.

■■

How can people simultaneously want to kill time and get angry when their time is wasted? Well, that’s a conundrum to be teased apart.

108

Mobile Usability

The solution to the puzzle lies in recognizing that even relaxation is purposeful behavior: According to information foraging theory (see the sidebar “Information Scent” in Chapter 3, “Designing for the Small Screen”), users seek to maximize their cost/benefit ratio. That is, people want more thrills and less interaction overhead.
Filler = Bad

Unfortunately interaction costs are inherently greater in mobile, which is why you need to focus mobile content even more tightly than content for desktop websites. Figure 4.6 shows a typical example from one of our studies. When reading the “breaking news” story about a tornado, one test user found commentary from local people and said, “I don’t need to know what everyone else is saying and the event from their point of view. I don’t mind a quote from a local leader, but all this to me is just filler, and I wouldn’t read it.” She went on to say, “This is what came to me as breaking news? That’s too much. It should be:This is what happened, and this is what’s going on.” Several other test users made comments about not wanting to read entire news stories—especially “filler” content—on their phones. Users didn’t want to bother with extra, secondary text, particularly in mobile apps designed for quick information consumption. They just wanted to know the main points.
Figure 4.6 The CNN News app, as shown on a study participant’s phone. This photo is a frame from the video recording of our usability study.

4: Writing for Mobile

109

Usually we take screen shots directly from the site or app, but in CNN’s case the story was already gone from the app by the time we finished the study. For that reason, recording high-quality video is a safe backup, but it’s also trickier in mobile studies than in traditional PC-based user testing.

In all fairness, CNN has slightly changed its app since our testing, and now it has a summary (or “story highlights”) at the beginning of the article that makes the article more scannable (Figure 4.7). It still doesn’t fix the filler-information problem, but at least it makes it easier for the users to find the main points. You might ask why people don’t simply stop reading once they’ve consumed as much information as they want about a given topic. Sure, users do stop reading and are quick to leave sites. But they still feel drawn in by the writing and often skim more words than they really appreciate. And, after doing so, they feel duped because they didn’t get sufficient payoff from investing their precious time. There are two solutions:
■■

Cut the fluff. In particular, ditch the blah-blah verbiage that people inevitably place at the beginning of pages before getting to the meat of the matter. A good exercise is to simply delete your first paragraph and see if the page works as well without it. If it does, don’t click that Undo button. Defer background material to secondary screens that are shown only to users who explicitly ask for more info. Such additional content supports people who have extra time on their hands or an exceptional interest in the topic.

■■

Figure 4.7 A newer version of the CNN app for Android. The main story points are summarized at the beginning of the article.

110

Mobile Usability

Ditch the Blah-blah Text
The introductory paragraph(s) found at the top of many Web pages is what we call blahblah text: a block of words that users typically skip when they arrive at a page. Instead their eyes go directly to more actionable content, such as product features, bulleted lists, or hypertext links. The worst kind of blah-blah text has no function; it’s pure filler—platitudes, such as “Welcome to our site, we hope you will find our new and improved design helpful.” Kill the welcome mat and cut to the chase. Ruthlessly editing introductory paragraphs might be good advice, but why not just eliminate them completely? Cutting word count seems a weasely approach.
■■

Some intro text serves a valid role in that it helps set the context for content and thus answer the question: What’s the page about? A brief introduction can help users better understand the rest of the page. Even if they skip it initially, they might return later if it doesn’t look intimidatingly long and dense. If you keep it short, a bit of blah might actually work. So prune your initial draft of marketese and focus on answering two questions:
■■

What? (What will users find on this page— that is, what’s its function?) Why? (Why should they care—that is, what’s in it for them?)

When you’re writing for mobile users, heed this maxim: If in doubt, leave it out.
Old Words Are Best

“Speak the user’s language” has been a primary usability guideline for more than 20 years. The fact that the Web is a linguistic environment further increases the importance of using the right vocabulary. In addition, mobile users are growing ever-more search dominant. Search is how people discover new websites and find individual pages within websites and intranets. Unless you’re listed on the first search engine results page (SERP), you might as well not exist. So writing for the mobile Web is writing to be found. There are many elements to search engine optimization (SEO), but SEO guideline #1 is our old friend, “Speak the user’s language.” Or, when you write, use keywords that match users’ search queries. Winston Churchill said that “short words are best and the old words when short are best of all.” Churchill was talking about how to write punchy prose, not about SEO. To be found, precise words are often better than short words, which can be too broad to accurately describe the user’s problem. For example, our audience is more likely to search for “usability” than for “easy”.

4: Writing for Mobile

111

But Churchill was right that old words are best. Old words rule because people know them intimately. Familiar words spring to mind unbidden. Thus users are likely to employ old words when they boil down their problem to a search query, which is typically only two or three words long—particularly on mobile where it’s hard to type. Because old words are used most frequently, people understand them faster. Remember that on mobile, users are often rushed and text comprehension is difficult. Using familiar and precise words delivers the gist of the content more quickly and makes it less likely for users to need to refer back to other parts of your text. Figure 4.8 shows an example of hard-to-read text that relies heavily on economic jargon (from the app Labor Stats).You could perhaps argue that this app is for an audience with some sort of economic education. If so, such an audience is probably fairly versed in the economic lingo and needs neither a vague definition of “labor productivity” (“relationship between output and labor time”—what is the nature of this relationship and how is it calculated?) nor a more precise one.
Figure 4.8 The Labor Stats app for iPhone. The news release in this app has been rewritten for mobile, but the use of economic jargon (as well as the lack of formatting) makes it hard to read and hard to follow.

Bylines for Mobile Content?

Should you identify the author of articles and other website content? Or should the material remain anonymous and be published under the organization’s institutional voice?

112

Mobile Usability

Unfortunately there’s no single answer to the Web bylines question. But there are a number of criteria, some that follow the mobile writing principle discussed earlier—cut the fluff.
Against bylines: Cut the fluff

Here are the reasons to remove bylines:
■■

As always when writing for online use—and particularly for mobile—one main guideline is to keep it short. Users spend very little time on Web pages; information that doesn’t provide sufficient value-added should be left out. On average, users read only about 120 words per page view, so you may not want three of those few words to be “by Joe Schmoe.” Mobile copy should be cut even more than you might cut verbiage for a desktop site. Even if some of the following criteria lead you to include bylines, it might be better to remove them for the mobile version of your site.

■■

For bylines: Establish credibility

Bylines can be worth their word count in the following cases:
■■

If the author is famous—maybe even famous enough that people might read the piece mainly to hear what he or she has to say on some current issue. In this case, you should include the author’s name when linking to the article from homepages, SERPs, article listings, tweets, and so on. Note that “fame” doesn’t necessarily equate to “celebrity.” Respected geeks can be well known in specialized communities while being completely unknown to 99 percent of the population. What counts is whether the author is known to the target audience.

■■

If the author has credentials or status that support the article’s credibility. The classic example is a medical doctor writing about a health issue, in which case you should certainly list the article as being “by Joe Schmoe, MD.” If the author has experience that provides some credibility. For example, the designer of a website should be named when you’re writing an article discussing that design. If the author often writes about a certain topic. Regular readers might recognize the name and want to seek out the writer’s other articles.

■■

■■

4: Writing for Mobile

113

Author Bios Dos and Don’ts
Usually a brief author biography is secondary content that should appear on a separate page. However if a credentialed or experienced author’s credibility-boosting effect requires more info than just his or her name, you should add a one-line bio abstract at the top of the page to encourage users to read the article. (For example, “by Dr. Joe Schmoe, head of the Cystic Fibrosis Centre, Toronto Hospital for Sick Children” in an article about Cystic Fibrosis in children.) Longer biographies should always be relegated to secondary pages and linked from the author’s name. But don’t link the name to an email address for two reasons:
■■

■■

a new Web page, which is the expected behavior of Web links. Users are much more likely to want to read about the author than to contact the author. If appropriate, you can add contact info at the bottom of the biography page.

Author biographies should include a portrait photo, at least when you provide a separate bio page. This can be a standard headshot or an action shot of the author doing something relevant to the article (such as sitting on a tractor for a farmer writing about farming). Also the author bio page should include links to the author’s other articles on the site, except in the case of weblogs or other sites that are essentially the work of a single author.

It’s distracting for users when clicking a name initiates an email instead of showing

■■

If the article is an opinion piece, review, political commentary, or other type of content that is specifically positioned as an individual person’s take on an issue. A byline is needed simply to clarify the content’s status. Depending on the nature of the site, such content might also require a disclaimer that the analysis does not necessarily represent the organization’s position. If the article belongs to an intranet. Naming authors can help establish a feeling of community by helping employees get to know each other.

■■

Here are some examples of situations where bylines are or are not appropriate on mobile. Zite, a news aggregator (Figure 4.9), justifiably uses bylines indicating the source of the different articles. On the other hand, including author information in the article listings (like ProPublica in Figure 4.10A) is not warranted. That prime real estate should be used for more important information. The Washington Post (Figure 4.10B) lists the article author on the article page beneath the title. Although better than listing it on the headline page, it still takes up valuable space; it would be best if that space were used for content unless the Washington Post has some reason to believe that this author is famous enough for people to seek his articles. (The top

114

Mobile Usability

of the page tends to get the most attention and should be reserved for essential information.) If the author needs to be credentialed and is not famous, consider adding the name at the end of the article—as in the CNN Money example in Figure 4.10C.
Figure 4.9 Zite app for iPhone uses bylines to indicate the news source.

A

B

C

Figure 4.10 Author bylines are not necessary on mobile: (A) ProPublica’s website (propublica.org); (B) Washington Post app for Android; and (C) CNN Money app for Android.

4: Writing for Mobile

115

Defer Secondary Information to Secondary Screens
Our own studies of mobile usability have found that users are typically rushed when using their mobile devices. A contrasting mobile use case is people who simply want to kill time while waiting. However most tasks are at least somewhat goal directed, and people using a mobile device often have minimal time to accomplish them. For example, when you check email on your phone, you tend to allocate less time to a newsletter than you would when reading email at home or in the office. We’ve known since 1997 that it’s best to be concise when writing for the Web. Mobile simply reinforces this point and stretches it to the limit. Short is too long for mobile. Ultrashort rules the day. How can you be super-concise and still offer the info people need? You do that by deferring secondary information to secondary screens. The first screen users see should be ruthlessly focused on the minimum information needed to communicate your top point.
Example 1: Mobile Coupons

Discount coupons are a perfect mobile service because they’re highly dependent on time and/or location: Flash sales have a sense of urgency because people want to know about a coupon before it sells out. Similarly people are likely to be interested in coupons for shops and products they encounter while they’re out and about (and away from their desktop computers). Figure 4.11 shows an example of how a Groupon deal looks on an Android phone. The initial view is clearly suited for the hurried mobile user. The detailed view, on the other hand, is a nice second step for people who are really interested, but it would have been a great turnoff to show this wall of text as the first screen. Groupon worked well in our mobile usability study. Groupon changed its design slightly, so that now “More about this deal” actually appears on the same page (Figure 4.12). It kept the nicely structured information at the top of the page. The new design is still layered, but instead of moving the details on a separate page, it puts them on the same page at the bottom. A competing service, LivingSocial, did poorly, as shown in Figure 4.13.

116

Mobile Usability

Figure 4.11 Mobile Groupon deal: (A) initial view and (B) detail view. You get the detailed view when you select “More about this deal” on the first screen.

A

B

Figure 4.12 On the newer version of Groupon, all the text under “More about this deal” appears at the bottom of the page. Figure 4.13 Mobile LivingSocial: Sample deal.

4: Writing for Mobile

117

LivingSocial offends against several mobile usability guidelines. Cute babies are always nice, but in a mobile user interface, stock photos only push salient information off the small screen. With this layout and writing, it’s hard to find out what you’re buying. And if there’s one thing we know about mobile users, it’s that they are usually too busy to work at finding information. (In fairness to LivingSocial, the “Buy Now” button does follow guidelines for easy touchability on a mobile screen: It’s big, clear, and has nothing near it that users might tap by mistake.) Here’s what two of our study participants said about these two ways of presenting coupon offers on mobile devices:
■■

LivingSocial’s presentation: “It just seems like more of a display that would be on a website as opposed to adapting it on the phone. It would be fine to me if it was on my computer.” The same user on the Groupon app: “It’s the quick version on the front.There are options to see more, but there isn’t a ton of info. Since it’s a phone, crowding the screen isn’t a good idea.” Another user on Groupon: “I like the really quick bulleted format.” And on LivingSocial: “You have to read through the whole thing to see what’s included in it.”

■■

Example 2: Progressive Disclosure in Wikipedia

Wikipedia has always had two qualities: extensive hypertext linking and exhaustive content, telling you something about everything. Wikipedia has also always exemplified bad writing, with contributors who have little insight into a topic’s truly important aspects and thus have an inability to prioritize information in their articles. Given this decade-long tradition, we were somewhat surprised that Wikipedia scored well for information prioritization in our study. Figure 4.14 shows an example of how an article looks the first time users see it on their phones. This design focuses users nicely on the article’s key points while deferring secondary information. The page starts by showing the main biographical facts in a tabular format, followed by a short paragraph about Dr. Huang and collapsed sections that contain further details. Of course this is nothing but a case of progressive disclosure, which is a very old idea in human–computer interaction (see the sidebar “Progressive Disclosure” in Chapter 3). This established design principle comes to the forefront when you’re writing for mobile.

118

Mobile Usability

Figure 4.14 Mobile Wikipedia (m.wikipedia.org): (A) initial article view and (B) information visible by scrolling down the page.

A

B

It’s particularly effective to show an outline of the secondary information instead of dumping it into a linear scrolling page. Users can immediately see, for example, that there’s a section about awards. And if they care about awards, they can expand this section without having to slog their way through a long biography section. Here’s what some of our test users said about mobile Wikipedia:
■■

“It’s sort of giving me an outline.They have their TOCs at the top, so it gives you the headings but not the whole thing. So you know what the heads are in the article and go to them as you wish.” “I like that [hiding content] better than having everything available. I can open the bio and not see all the references. It’s something I appreciate.”

■■

Of course, in true obsessive-compulsive Wikipedia fashion, this article also includes material that’s definitely not well written for mobile. The table at the beginning of the page does contain information that may be considered less important (for example, where Dr. Huang studied). And, given that users are likely interested in understanding Dr. Huang’s scientific accomplishments, explaining how her name would be transcribed in Pinyin and Wades-Giles is not even secondary information; it’s tertiary at best and, on mobile, should have been delegated to a secondary layer.

4: Writing for Mobile

119

Deferring Information = Initial Info Read More

It’s a tough decision to defer most of your information to secondary screens because many users will never see it, even though you no doubt consider it very important. But remember: if you make the first screen too dense, nobody will read anything. It’s better to focus the initial screen and let those users who’re particularly interested dig into the rest. That way you’ll satisfy more customers, get more traffic, and derive more business value from your mobile content. Figure 4.15 shows an example of good information layering from Apple. The software update information is presented very briefly on the main page; those few users who are interested in more details can click the link “Learn More” and get the extras on a secondary page. (The wording “Learn More,” however, is less than ideal, because it does not carry much information scent and is one of the more salient items on the page.)
Figure 4.15 Software update on Apple iPhone: (A) main page and (B) detail page. The information is layered.

A

B

News sites often offer another example of good layering (Figure 4.16): Many users are able to get the information they need quickly by scanning the article summary on the headline page rather than reading the entire article. For that reason, “true” summaries (like those from The Wall Street Journal in Figure 4.16A) that make sense on their

120

Mobile Usability

own and capture the gist of the story are preferable to sentence fragments (as USA Today uses in Figure 4.16B) or to just echoing the first sentence of the article.
Figure 4.16 Summaries for articles in a list of headlines are an example of layered content. (A) The Wall Street Journal’s website (m.wsj.com) and (B) USA Today app for Android.

A

B

However some companies push the layering too far, to the extent of forcing all users to go to a secondary page to find any information. Figure 4.17 shows two examples (WebMD and Net-a-porter) that manage to show practically zero useful information on the first page, forcing users to tap again to get to the relevant details. In the WebMD app (Figure 4.17A–B) the main types of information pertaining to the drug are easy to scan; however the page is arguably too structured. It would have been preferable to have a brief summary under each of the different sections (uses, side effects, etc.), so that users could quickly get the main idea and then move to more information if they wanted to. Once users click to any of the sections (in [b]), they get to a page only barely formatted for mobile: The lack of bullet points makes that page hard to scan. Net-a-porter (Figure 4.17C–D) also forces the users to tap for information about a product. Only the image is displayed on the main

4: Writing for Mobile

121

product page; all the other relevant details are sent to secondary screens. That information should all be present explicitly on the page with links to only that info that most users would not need (for example, “What size I am”). The essential content, relevant to most people, needs to be on the first screen in a scannable and concise format, and not be delegated to a secondary screen.
Figure 4.17 Information structured into sections: (A)–(B) WebMD for iPhone and (C)–(D) Net-a-porter for Android. Both apps display too little information on the main page.

A

B

C

D

122

Mobile Usability

Mini-IA: Structuring Content
The definition of mini-information architecture (mini-IA) is simple: It’s how you structure the information about a single topic. For example, the mini-IA of an email message is a single page. When something is covered on a single page, we don’t usually think of the presentation as “information architecture.” However the very decision to stick to a single-page format is an IA matter. Often it’s better to break up information into multiple units rather than using an overly long linear flow, like that shown in Figure 4.18. You can then present these multiple units across a few pages or use a within-page navigation system, such as tabs or carousels.
Linear Paging? Usually Bad

Let’s first dismiss a popular mini-IA as being almost universally bad for usability: If you have a long article, it’s almost never good to do as NBC does in the example in Figure 4.19 and simply chop it up into a linear sequence of pages. If the only navigation is a “Continue” or “Next page” link, it’s typically better to stick it all on a single page and rely on scrolling instead of page turning. Not only do users have to wait for a page to load every half a minute or so, but should they want to go back to the list of episodes when they finish reading the summary, they would need to tap the browser’s Back button 12 times.
Figure 4.18 Ted Video for iPhone. All the 104 available videos are presented in a long list. A mini-IA grouping of videos on topics would have been more helpful. Figure 4.19 NBC’s mobile website (m.nbc.com) splits episode summaries into many pages with just a picture and a paragraph per page.

4: Writing for Mobile

123

(The exception here is for content presented on tablets, such as the iPad, or for book-reader apps where the swiping gesture provides a generic command for moving between pages and/or the content is preloaded, so it doesn’t take any time to move between pages. Also, books are not usually read in a single session, and having the book split into pages makes it easier for users to keep their place in the book; otherwise, imagine having to scroll through an entire book to find the third paragraph in Chapter 11.) In many situations the best alternative is to chunk information into individual content units, focusing on logical cohesiveness.You can then describe each unit accordingly and let users navigate directly to the unit that meets their needs. (Note that “page 2 of 12” is neither descriptive nor deserving of its own page.) (For wizard-style interactions, such as e-commerce checkout, a linear page-turning progression usually works better because even though each step is logically cohesive, they’re in an application workflow, so you can’t go to step 3 without first completing step 2.)
Alphabetical Sorting Must (Mostly) Die

Another popular mini-IA that is often misused is alphabetical ordering. Sorting a list of options alphabetically has two main benefits:
■■

If users know the name of what they want, they can usually find it in the list pretty quickly. Lazy design teams don’t have to work on figuring out a better structure. Because we all know our ABCs, anybody can put the items into the correct sequence.

■■

The first point is a true benefit, and alphabetical sorting works fine in some cases. For example, it’s usually easy enough to pick out a state from an alphabetical list of the 50 U.S. states. Indeed, in this case an alpha listing is more usable than, say, grouping the states by region or showing them on a map—at least when users need to click only one state (usually their own) to navigate to a page with state-related information. (Listing states alphabetically is a good choice only when people have to select one state from a menu for navigation or a command. When users need to specify the state as part of their address—as in e-commerce checkout forms—it’s better to present a text field where people can type the two-letter abbreviation. This is faster and less error prone; on mobile, it also avoids the need for prolonged scrolling within a small drop-down box that spans only half of the tiny Phone screen, as in Figure 4.20.)
124

Mobile Usability

Figure 4.20 Macy’s app for iPhone. Selecting a state from a drop-down box is inefficient.

Lists of countries and other known-item problems are also often fine to alphabetize. However you do need to ensure that users will know unambiguously the name of their selection. If people have to look at several places in the list, you’ve defeated the purpose of the A–Z order. For most questions, either:
■■

Users don’t know the name of what they want, making A–Z listings useless, or The items have an inherent logic that dictates a different sort order, which makes A–Z listings directly harmful because they hide that logic.

■■

Sizes are ordinal data, meaning that they have an inherent monotonically increasing sequence. Such items should almost always be sorted accordingly. Other times, items have domain-related logical groupings.You can often determine this underlying logic in a card-sorting study where you ask users to group related items together. For example, Epicurious is a recipe app that allows users to search and save recipes (Figure 4.21). The list of favorite (or saved) recipes can be seen in alphabetical order or in recently added order. Neither works for a long list of recipes. In the case of alphabetical sorting, the first word of a recipe name (such as, “Balsamic” for “Balsamic roasted

4: Writing for Mobile

125

vegetables”) is often nonindicative of the recipe. And except for very recent recipes, users are unlikely to remember when they’ve added a recipe to their list for the first time. (To add insult to injury, Epicurious does not have a search function for the recipe box, making it very difficult for people to deal with a large number of recipes.) A mini-IA that grouped recipes under different categories (fish, meat, desserts, etc.) would have been a lot more useful. Timelines and geographical location are other groupings that are often useful, although sometimes they can go wrong, too, as shown in the example in Figure 4.22. The entries in the list are geographical locations, but the editors had their own understanding of alphabetical order: The Black Forest is under “F” (presumably for “Forest”), and Antwerp is under “G” (for “Geography of Antwerp”). It’s very unlikely that users could guess at this type of classification; in fact, when searching for Antwerp, they’ll probably just stop at “A,” thinking that it shouldn’t appear farther down the “alphabetically” ordered list.
Figure 4.21 Epicurious for iPhone. The list of favorite recipes can be sorted in alphabetical order or in recently added order. Neither of these is appropriate for long lists of recipes. Figure 4.22 How Stuff Works app for iPhone. Here’s an example of alphabetical order gone wrong: Antwerp is under “G” (for “Geography of Antwerp”).

You can let the importance or frequency of use guide how you prioritize long listings rather than default to less-useful alphabetical sorting. Depending on the nature of your information, usability might be better served by yet other types of structures. And yes, in a few cases, this might even be the alphabet. But typically, when you reach for an A–Z structure, you should give yourself a little extra kick and seek out something better.

126

Mobile Usability

Example: Usage-relevant Structure

To illustrate a usage-relevant structure, look at Figure 4.23, which shows two example structures that present information about exercises in a mobile fitness app.
Figure 4.23 Lists of exercises in two iPhone apps: (A) You Are Your Own Gym and (B) Full Fitness.

A

B

The example in Figure 4.23A employs a useful mini-IA for push-up exercises: It puts all the exercises together in a list that’s ordered from the easiest to the hardest. In contrast, the example in Figure 4.23B sorts the exercises alphabetically, which, as discussed in the previous section, is usually a poor structure. The Full Fitness screen shot (Figure 4.23B) shows only a part of the complete list and includes incline push-up, modified push-up, and plain old push-up. How do you know which one to pick if you want a variation that’s a bit more challenging than your last exercise? Is “modified” easy or difficult? “Modified” obviously emits poor information scent: The word tells you what the exercise is not instead of what it is. “Incline” is better, though not as clear as the equivalent “hands elevated” label used by You Are Your Own Gym. Quick, what’s the difference between an incline push-up and a decline push-up? We bet you can’t answer that as quickly (or as correctly) as you might decipher “hands elevated” versus “feet elevated.” Simpler words are usually best. (You’re excused from preferring simple words if you’re writing for an expert

4: Writing for Mobile

127

audience. But advanced fitness enthusiasts definitely won’t need to look up how to perform an incline push-up, even if that’s what they might prefer calling this exercise.) The designers of Full Fitness would have surely benefited from reading this chapter. That said, their main problem is structural. Even with improved labels, the current Full Fitness scheme would remain less usable than the You Are Your Own Gym solution, which recognizes that push-up variations deserve their own mini-IA structured according to the best way to make sense of different push-up exercises (here, progressing from easy to hard as you get stronger). As an aside, both apps use thumbnail photos to further explain the exercises and help users determine which one to choose. And both have usability problems. Except for the “moderate” photo,You Are Your Own Gym’s photos have too much background detail to be easily understood given their small size. Full Fitness’s photos are cleaner and almost as easy to grasp as the Own Gym photos, even though they’re much smaller. We usually criticize tiny thumbnails, but most of the Full Fitness images (except for the two machine exercises) are clean enough to adequately differentiate the exercises. Another example of good mini-IA comes from Teavana (Figure 4.24). Teavana splits its teas by type (white, green, oolong, and black). Interestingly, Teavana implements its mini-IA in a slightly different way than You Are Your Own Gym (see Figure 4.23A): Teavana’s mini-IA is
Figure 4.24 Teavana app for iPhone. Teavana appropriately uses a mini-IA for its tea list. The top panel with the four types of teas is persistent.

128

Mobile Usability

not given a separate page; instead it’s shown in a persistent strip (that doesn’t disappear as the user scrolls down through the list of teas) at the top of the tea list. This solution sacrifices some screen space, but it lets users change the tea type more efficiently. However the thumbnails are small and hardly necessary: It’s unlikely that anybody would recognize or select a tea using that kind of image (or, perhaps, any image at all.)
Usage-driven Structure

When you have a lot of information about a topic, there are three ways of presenting it:
■■

One long page. One long page is a simple choice but makes it harder for users to access individual subtopics.You also risk intake fatigue as users slog their way through the page to the bitter end (and many will give up before the going gets too bitter). Mini-IA. Mini-IA lets you split the info into appropriate chunks. This allows direct access to subtopics of interest and can give users a better understanding of the concept space than they’d get while putting their nose to the grindstone to endlessly scroll. Distributed information. Distributed information lets you blend together subtopics of many topics, as in the push-up exercises, cable machine exercises, and so on in the Full Fitness section on “Chest Exercises” (Figure 4.23B).

■■

■■

Here we’ve argued that usability is often enhanced by the second approach. However, a mini-IA makes sense only if you can structure this localized information space according to a principle that supports the users’ tasks and mental models. Since the Web’s beginning, internally focused structuring has been one of the most user-repellent design mistakes. Our research into intranet IA, for example, has repeatedly found that both usage and employee productivity skyrocket when a department-based IA is replaced by a task-based IA. Along similar lines, a mini-IA won’t help if it’s structured according to your internal organizational chart or any other way that fails to match how customers want to access information. But if you embrace a mini-IA—identifying a usage-based structuring scheme as a basis for a clear and modest navigation system—you’ll likely have a winner on your hands.

4: Writing for Mobile

129

Index
90-9-1 rule, 88

B

A

A/B testing, 92–93 ABC News app, 52, 53 accidental activation, 138, 143–145 Adobe Photoshop Express app, 59 affordances discoverability of, 138–141 explanation of perceived, 141 Alfred app, 132 AllKpop.com case study, 67–76 iterative design steps, 73–75 positive features of current site, 68 redesign recommendations, 69–72 user testing of redesign, 75–76 alphabetical sorting, 124–126 Amazon.com Android apps, 36 Kindle devices, 169–178 Kindle iPhone app, 170 Windowshop app, 70, 156 Amici’s pizza app, 83 Android Back button, 65, 66 physical vs. virtual buttons, 37 smartphones using, 14 subplatforms, 35–36 Apple App Store, 86, 88, 90 application chrome, 56 apps ephemeral, 42 homepage for, 64 hybrid, 40 intermittent-use, 41, 43–44 mobile, 41–44 native, 40 sites vs., 34–41 Web, 38–39, 40, 42 Association for Truth in Skins (ATIS), 187–188 ATT U-verse app, 159, 160 augmented reality (AR), 186–187 author biography guidelines, 114

Back button, 65–66, 143–144 BBC app, 166, 167 Best Buy app, 27, 50 biographies, author, 114 blah-blah text, 111 bloated pages, 10 Bloomberg app, 167 Boston Globe website, 29, 31 business model, 95 buttons Back button, 65–66, 143–144 physical vs. virtual, 37 Buy.com website, 133, 173 bylines consideration on using, 112–115 removing from mobile text, 69, 113

computer trends, 182 Condé Nast app, 64 content continuity, 185 contextual tips, 59 conversion rates, viii–ix cost/benefit ratio, 109 coupons, 116–118 cross-device integration, 170–171 cross-platform UIs, 185

D

C

Card, Stuart, 73 card model, 153–155 carousels, 12, 13 case studies AllKpop.com mobile site, 67–76 WSJ mobile app, 86–99 cellphones, 15 chrome, 55–63 benefits of, 62–63 explanation of, 55–56 gestures as alternative to, 59, 61–62 hiding and revealing, 58–59 screen space consumed by, 57–59 system examples of, 56–57 Clarke, Arthur C., 190 Clear app, 61, 62 client studies, 2 Cloze test, 103–104 CNN apps, 109–110, 115 The Collection app, 140–141 commands generic, 63 overloaded, 63–66 reusing, 67

data continuity, 185 data overlays, 186–187 demo features, 86 design iterative, 73–75 mobile-optimized, 20–21 responsive, 28–33 Design of Everyday Things,The (Norman), 141 Designing Web Usability (Nielsen), 6, 44, 165 desktop PCs, 183 diary studies, 3 directed tasks, 5 discoverability issues, 138–141 distributed information, 129 download times improving, 79–81 slowness of, 10, 14, 51, 79 drop-down menu, 72

E

early registration Pizza Hut example, 84–86, 87 problems with requiring, 81–84 e-commerce sites conversion rates, viii–ix user experience guidelines, 82 electronic books (e-books), 171–172 Elements iPad app, 135 email app for iPad, 163–164 Envisioning Information (Tufte), 56 ephemeral apps, 42 Epicurious app, 125–126, 155 e-readers. See Kindle e-reader

Index

199

ESPN Score Center app, 72 Eyetracking Web Usability (Nielsen & Pernice), 6, 25

I

F

“fat finger” problem, 52, 134, 172 feature continuity, 185 feature phones, 15, 16 feature reduction, 69 filler content, 109–111 Financial Times Web app, 39 finger vs. mouse input, 24–25 fitness apps, 127–128 Fitts’ Law, 76 Foodspotting app, 84 formatting for mobile examples of good and bad, 106–108 See also writing for mobile forms, filling in, 77–78 Full Fitness app, 127–128 full vs. mobile websites, 18–33 full-screen phones, 15 future innovations, 189–191

G

generic commands, 63 geographical locations, 126 George Mason University School of Law website, 28, 30 gestures chrome replaced by, 59, 61–62 generic commands as, 63 memorability of, 141–143 Google+ app, 66 Google Glasses, 186 Groupon mobile site, 116, 117 guest checkout option, 81

H

Harry Potter’s world, 189–191 headlines, 69, 70 Hill, Will, 88 Hipmunk app, 78 homepage usability, 64 homing time, 24 Hotels.com app, 144–145 How Stuff Works app, 105, 126 HSN app, 107, 108 huge screens, 184 human-interface guidelines, 77 hybrid apps, 40

iBooks mobile site, 54 Ice Cream Sandwich (Android) Back button functions, 66 virtual buttons, 35, 36, 37 IKEA mobile site, 21 image maps, 138 information architecture (IA), 23 task-based vs. department based, 129 See also mini-information architecture information foraging, 73, 109 information layering, 120–122 information scent, 69, 73 input mobile device, 51 mouse vs. finger, 24–25 Instapaper app, 58 interaction cost, 80 interaction design, 146–151 interfaces. See user interfaces intranets, mobile, 47 Invisible Computer,The (Norman), 186 iOS folders, 43, 44 subplatforms, 35 iPad, 4, 132–168 accidental activation on, 138, 143–145 card vs. scroll models for, 153–157 discoverability issues on, 138–141 improving the user experience on, 168 inconsistent interaction design on, 146–151 memorability of gestures on, 138, 141–143 navigation issues on, 159–165 orientation options on, 166–167 perceived affordances on, 138, 139–141 print metaphor related to, 151–153 shared nature of using, 136 splash screens and noises on, 165–166 swipe ambiguity on, 158–159

usability considerations, 132–136, 168 use patterns for, 137 See also Kindle Fire; tablets iPhone compared to iPad, 132–133 Kindle app for, 170 mobile usability of, 46 popovers and split views on, 164–165 software update pages, 120 use patterns for, 137 iterative design, 73–75

J

Jakob’s Law of the Web User Experience, 44 JavaScript crashes, 10, 14 JC Penny Web app, 40

K

Kay, Alan, 46 keyboards, virtual, 76–77 killing time, 108, 137, 198 Kindle e-reader, 169–172 cross-device integration, 170–171 usability issues, 169 Kindle Fire, 4, 172–179 Back button, 65 command overloading, 64 magazine apps, 174–177 reading experience, 174 usability issues, 172–178 virtual buttons, 36, 37 See also iPad; tablets Kindle iPhone app, 170 Kinect system, 188

L

Labor Stats app, 112 landscape orientation, 166–167 launch screens, 165 layering information, 120–122 Life magazine app, 146, 147 linear paging, 123–124 links to/from mobile websites, 19–20 LivingSocial mobile site, 116, 117, 118 Lonely Planet app, 106

200

Mobile Usability

M

Macy’s mobile app, 125 magazine apps iPad, 146–147, 149–150, 156–157, 158, 161 Kindle Fire, 174–177 Mail app for iPad, 163–164 Martha Stewart Cocktails app, 139, 154 Marvel Comics app, 84, 155 mega menus, 163 memorability of gestures, 141–143 Microsoft Kinect system, 188 Microsoft Surface tablets, 166 mini-information architecture (mini-IA), 123–129 alphabetical sorting used in, 124–126 linear paging used in, 123–124 usage-driven structure and, 129 usage-relevant structure and, 127–129 mobile apps, 41–44 chrome used in, 57 registration issues, 81–86 WSJ case study, 86–99 mobile device classes, 15–18 explanation of, 15–16 separate designs for, 17–18 mobile intranets, 47 mobile usability studies. See usability studies mobile websites apps vs., 34–41 arguments against, 21–22 design ideas for, 20–21 download times for, 79–81 filling in forms on, 77–78 full websites vs., 18–33 guidelines for building, 18–20 iPad display of, 133 screen optimization, 67–76 typing on, 76–79 usability issues, 50–51 user testing of, 75–76 wasted space on, 52–67 Monetate study, viii–ix Moore’s Law, 35 mouse vs. finger input, 24–25

N

NASA’s iPad app, 162–163 National Geographic website, 19 native apps, 40 navigation bars, 13, 72 navigation problems, 159–165 NBC.com website, 11, 123 Net-a-porter app, 78, 121, 122 New York Times iPad apps, 140–141, 151 mobile apps, 71 New Yorker magazine app, 146–147 newspapers mobile apps, 71, 79, 121, 147–149, 151 survival imperatives, 91 WSJ app case study, 86–99 Nielsen, Jakob, 6, 88, 165, 171 Nielsen Company, 14 Nielsen Norman Group, 2, 14, 186 Nielsen’s Law, 35 90-9-1 rule, 88 noises, startup, 165–166 Nordstrom mobile site, 96, 97 Norman, Don, 141, 186 Notability app, 143, 144 NPR mobile site, 70

print metaphor, 151–153 Prioritizing Web Usability (Nielsen & Loranger), 6 privacy policies, 102 progressive disclosure, 59, 60, 118–119 ProPublica website, 31–32, 114, 115 publication date info, 71

Q

qualitative user research, 5–7 QVC iPad app, 136

R

O

Raskin, Jef, 153 reading comprehension, 102–108 Cloze test of, 103–104 mobile devices and, 102, 104–108 Recalls.gov app, 107, 108 recognition-based user interfaces, 142 registration requirement Pizza Hut example, 84–86, 87 problems with, 81–84 research. See usability studies responsive design, 28–33 Rue La La app, 136

OpenAppMkt Web app, 39 open-ended tasks, 5 Orchestra app, 82, 83, 93 orientation views, 166–167 OSHA Heat Safety Tool app, 107 overloaded commands, 63–66

S

P

Palo Alto Research Center, 73 PayPal, using for purchases, 12 perceived affordances, 141 physical vs. virtual buttons, 37 physical vs. virtual keyboards, 76–77 pinch-zoom gesture, 63 Pirolli, Peter, 73 Pizza Hut app, 84–86, 87 Playboy Web app, 38 popovers, 164–165 Popular Science app, 149–150, 151–152, 175 portrait orientation, 166–167

scannability, 69 screen shots, x–xi screens extremes of tiny and huge, 184 limitations of small, 50–51, 52 optimizing for mobile use, 67–76 transmedia design for, 182–185 wasted space on, 52–55 See also user interfaces scroll vs. card model, 153 scrolling designing into iPad apps, 156–157 mobile device problems with, 10, 11 search engine optimization (SEO), 111 search engine results page (SERP), 111

Index

201

search function apps vs. Web, 38 mobile use of, 12, 111 multiple fields for, 64 secondary screens, 116–122 selectable categories/tags, 69 self-looping carousels, 12, 13 sequential navigation, 152 seven-inch tablets, 178–179 shared devices, 136 shopping distinguished from demos, 86 reluctance to use mobile, 12, 14 Singh, R. I., 102 skinned images, 187–188 small screen design, 49–99 smartphones, 15 Snapguide app, 93 snippet technique, 3 software chrome, 56 sorting, alphabetical, 124–126 splash screens, xi, 165 split views, 164–165 Star Trek PADD app, 139, 140 startup screens confusing designs for, 89–90 splash screens and noises on, 165–166 story summaries, 71 structuring content, 123–129 alphabetical sorting in, 124–126 linear paging used in, 123–124 usage-driven structure for, 129 usage-relevant structure for, 127–129 success rates defined in usability studies, 16 mobile task performance, 10, 14 swipe ambiguity, 66, 158–159 swipe gesture ambiguity of, 66, 158–159 discoverability of, 154–155 reading apps and, 59

T

tablets, 132–168 seven-inch, 178–179 shared nature of, 136 user interface for, 27, 132, 134, 168

Web page display on, 133, 134–136 See also iPad; Kindle Fire tasks performance times for, 44–45 reluctance to perform, 12, 14 success rates for performing, 10, 14 usability testing examples of, 5 Teavana app, 107, 128–129 Ted Video mobile site, 123 television user experience, 183–184 testing usability. See usability testing text bylines for, 112–115 comprehension of, 102–108 conciseness of, 25–26, 33, 116 deferred to secondary screens, 116–122 ditching blah-blah, 111 eliminating filler, 109–111 old words used in, 111–112 structuring, 123–129 See also writing for mobile text messages, 77 thumbnail navigation, 160–161 Time magazine app, 156–157, 158 timelines, 126 tiny screens, 184 TMN problem, 159–165 tone of voice, 185 top navigation bars, 13 touch input, 24–25 touch phones, 15 touch targets enlarging, 69 proper size of, 77, 78 transmedia user experience, 184–185 truncated headlines, 69, 70 Tufte, Edward R., 55, 56 tutorials, 84 TV-based design, 183–184 Twitter, 3 typing on mobile sites, 76–79

U

USA Today app, 79, 121, 147–149 usability guidelines, 33, 82 usability studies, 1–7 client studies, 2 diary studies, 3 mobile usability, 9–14, 44–46, 193–198 qualitative user research, 5–7 success rates in, 16 usability testing, 3–5 WAP usability, 44, 193–198 usability testing, 3–5 app redesign, 95 iPad and Kindle Fire, 4 mobile site redesign, 75–76 task examples, 5 usage environment, 45 usage-driven structure, 129 usage-relevant structure, 127–129 user experience (UX) research, 2 user interfaces (UIs) alternate, 54 chrome in, 55–63 commands in, 63–67 confusing, 89–90 cross-platform, 185 density of, 55 guidelines for, 86 inconsistent, 146–151 optimizing, 67–76 recognition-based, 142 tablet, 27, 132–136, 168 touch targets in, 77, 78 unfamiliarity issues, 10 user manuals, 84 user reviews, 86, 88, 90

V

Vanity Fair app, 161, 175, 176 Virgin America website, 134 virtual reality (VR), 186 virtual vs. physical buttons, 37 virtual vs. physical keyboards, 76–77 visioneering project, 187, 188 visual continuity, 185 Visual Display of Quantitative Information,The (Tufte), 55, 56

202

Mobile Usability

W

Wall Street Journal mobile app case study, 86–99 mobile website layering, 120–121 Walmart mobile site, 96, 97 WAP (wireless access protocol), 17 mobile usability study, 44, 193–198 modern phone comparison study, 44–45 Washington Post app, 114, 115 wasted mobile space, 52–55 Weather Bug app, 55 Weather Channel app, 52, 53, 155 Web apps, 38–39, 40, 42 Web browser chrome, 57 Web usability studies, 196 WebMD mobile app, 121, 122 websites chrome on, 57 full vs. mobile, 18–33 homepage for, 64 iPad display of, 133 links to/from, 19–20 usability guidelines, 82 See also mobile websites

Wikipedia mobile site, 20, 118–119 Windows OS chrome, 56 Wolfram Alpha app, 83 workflow design importance of, 96–97 WSJ case example, 94–95, 98–99 writing for mobile, 101–129 author biographies and, 114 byline pros and cons in, 112–115 deferring information in, 116–122 eliminating filler in, 109–111 examples of good and bad, 106–108 importance of conciseness in, 25–26, 33 layering information in, 120–122 old, familiar words used in, 111–112 reading comprehension and, 102–108 secondary screens used in, 116–122 structuring content in, 123–129

WSJ mobile app case study, 86–99 brand degradation issues, 90–91 business model consideration, 95 screen design improvements, 91–94 startup screen confusion, 89–90 workflow redesign, 94–95, 98–99

Y

Yelp mobile site, 20, 54 You Are Your Own Gym app, 127–128

Z

Zapd app, 82, 96 Zappos Android app, 65, 79 iPad app, 146, 147 mobile website, 80, 81, 97 Zite app, 114, 115 Zollman, Peter, 182

Index

203