Android ™ Design Patterns
Android ™ Design Patterns
InterActIon DesIgn solutIons for DeveloPers
greg nudelman
Android™ Design Patterns: Interaction Design Solutions for Developers Published by
John Wiley & Sons, Inc.
10475 Crosspoint Boulevard Indianapolis, IN 46256 www.wiley.com
Copyright © 2013 by John Wiley & Sons, Inc., Indianapolis, Indiana Published simultaneously in Canada
ISBN: 978-1-118-39415-1 ISBN: 978-1-118-41755-3 (ebk) ISBN: 978-1-118-43934-0 (ebk) ISBN: 978-1-118-65058-5 (ebk)
Manufactured in the United States of America 10 9 8 7 6 5 4 3 2 1
No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permis- sion of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley .com/go/permissions.
Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or war- ranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought. Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or Web site is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or website may provide or recommendations it may make. Further, readers should be aware that Internet websites listed in this work may have changed or disappeared between when this work was written and when it is read.
For general information on our other products and services please contact our Customer Care Department within the United States at (877) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002.
Wiley publishes in a variety of print and electronic formats and by print-on-demand. Some material included with standard print versions of this book may not be included in e-books or in print-on-demand.
If this book refers to media such as a CD or DVD that is not included in the version you purchased, you may download this material at http://booksupport.wiley.com. For more information about Wiley products, visit www.wiley.com.
Library of Congress Control Number: 2012956395
Trademarks: Wiley and the Wiley logo are trademarks or registered trademarks of John Wiley & Sons, Inc.
and/or its affiliates, in the United States and other countries, and may not be used without written permis- sion. Android is a trademark of Google, Inc. All other trademarks are the property of their respective own- ers. John Wiley & Sons, Inc. is not associated with any product or vendor mentioned in this book.
For Katie and Juliette: Let your dream be the golden compass you live your life by.
A b o u t t h e A u t h o r
Greg Nudelman believes in designing what works. His first experience with design- ing for mobile came when he joined the SkunkWorks team that created the origi- nal eBay mobile app that today generated more than $5 billion in revenue.
For more than 15 years, Greg helped craft cross-platform digital experiences for today’s top Fortune 500 companies, non-profits, and startups: eBay, WebEx, Wells Fargo, Safeway/Vons, Cisco, IBM, Groupon, Associated Press, the U.S. Patent Office, and many others.
Greg is the author of Designing Search: UX Strategies for eCommerce Success (Wiley, 2011), which has a solid 5-star rating on Amazon. The book includes 19 perspectives from today’s top names in search (a fact that Greg is particularly proud of).
Greg has contributed chapters and perspectives to the following publications:
■ Mobile Design Patterns (Smashing Media, 2012)
■ The Mobile Book (Smashing Media, 2013)
■ Designing the Search Experience, Tony Russell-Rose and Tyler Tate (2013, Morgan-Kaufmann)
■ Search Analytics for Your Site, Lou Rosenfeld (Rosenfeld Media, 2011)
Greg’s work on storyboarding tablet transitions was featured recently in Rachel Hinman's The Mobile Frontier (Rosenfeld Media, 2012).
Greg has authored more than 30 industry articles on mobile and tablet design and digital design strategy for leading industry magazines: Smashing Magazine, Boxes and Arrows, JavaWorld, ASP.NET Pro, UXmatters, and UXMagazine.
He is a FatDUX, Rosenfeld Media, Wiley, and eConsultancy affiliate and workshop leader, and he has taught design workshops at Marquette University, HULT Busi- ness School, Associated Press, and Wells Fargo.
Greg is an internationally acclaimed speaker, with repeated appearances and sold- out workshops at leading industry events such as Adaptive Path’s UXWeek, SXSW, MobX, IA Summit, WebVisions, Design4Mobile, Search Engine Summit, Enterprise Search Summit, Net Squared Conference, DrawCamp, and SketchCamp.
He is a co-founder of the UX SketchCamp movement with the landmark UX SketchCamp SF 2011 event. Greg’s cross-platform design strategy consulting company, DesignCaffeine, Inc., is based in the San Francisco Bay Area.
c r e D I t s
Executive Editor Robert Elliott Project Editor Charlotte Kughen, The Wordsmithery LLC Technical Editor Ambrose Little Production Editor Christine Mugnolo Copy Editor San Dee Phillips Editorial Manager Mary Beth Wakefield
Freelancer Editorial Manager Rosemarie Graham
Associate Director of Marketing David Mayhew
Marketing Manager Ashley Zurcher Business Manager Amy Knies
Production Manager Tim Tate
Vice President and Executive Group Publisher
Richard Swadley
Vice President and Executive Publisher
Neil Edde
Associate Publisher Jim Minatel
Project Coordinator, Cover Katie Crocker
Compositor Maureen Forys,
Happenstance Type-O-Rama Proofreader
Nancy Carrasco Indexer
Johnna VanHoose Dinse Cover Image
Greg Nudelman Cover Designer Ryan Sneed
A c k n o w l e D g m e n t s
To anyone who's never written a book it is difficult to imagine the blood, sweat, and tears required to finish one. I wish to acknowledge the generous help of my agent, Neil Salkind of Studio B as well as my fantastic team at Wiley: Charlotte Kughen and Ambrose Little. Any inaccuracies in the book are my own and no fault of theirs. Also, I'd like to thank Robert Elliott, from whose creative mind the idea for this book idea was initially born. I also want to acknowledge generous help provided by Kimberly Johnson, who helped decipher and sort out key Android visual design themes. Last, but definitely not least, I want to thank my family for their strong support and continual tolerance during this time of missed family commitments, forgotten appointments, and general mental fog surrounding the focused time of book writing.
c o n t e n t s At A g l A n c e
foreword xix
Introduction xxi
Part I: uX Principles and Android os considerations 1
chapter 1: Design for Android: A case study 3
chapter 2: what makes Android Different 25
chapter 3: Android fragmentation 41
chapter 4: mobile Design Process 55
Part II: Android Design Patterns and Antipatterns 69
chapter 5: welcome experience 71
chapter 6: home screen 87
chapter 7: search 113
chapter 8: sorting and filtering 149
chapter 9: Avoiding missing and undesirable results 179
chapter 10: Data entry 197
chapter 11: forms 251
chapter 12: mobile banking 307
chapter 13: navigation 347
chapter 14: tablet Patterns 391
Index 413
c o n t e n t s
foreword xix
Introduction xxi
Part I: uX Principles and Android os considerations 1
chapter 1: Design for Android: A case study 3
Launch Icon . . . 4
Action Bars and Information Architecture . . . 5
Tabs . . . 11
Dedicated Selection Page . . . 11
Select Control . . . . 12
Buttons . . . . 14
Search Results . . . 15
Result Detail . . . 19
Bringing It All Together . . . . 22
chapter 2: what makes Android Different 25
Welcome to Flatland . . . . 26
Tap Anywhere . . . . 28
Right-Size for Every Device . . . . 30
Mobile Space, Unbound . . . . 33
Think Globally, Act Locally . . . . 36
chapter 3: Android fragmentation 41
What’s Fragmentation? . . . . 42
Everything Is in Time and Passes Away . . . . 42
Android Device Trends . . . . 43
Celebrate Fragmentation. . . . 53
Contentsxvi
chapter 4: mobile Design Process 55
Observe Human-Mobile Interaction in the Real World. . . . 56
Your Prototyping Methods Must Allow for Variety in Form Factors . . 56
Your User Testing Must Allow People to Explore the Natural Range of Motion, Voice, and Multitouch . . . . 57
Touch Interfaces Embody Simplicity and Sophistication . . . . . 57
Delight Is Mandatory . . . . 58
Tell a Complete Story—Design for Cross-Channel Experiences . . . 58
Mobile Design Case Study . . . . 59
Part II: Android Design Patterns and Antipatterns 69
chapter 5: welcome experience 71
5.1 Antipattern: End User License Agreements (EULAs) . . . . . 72
5.2 Antipattern: Contact Us Impediments . . . 74
5.3 Antipattern: Sign Up/Sign In . . . . 77
5.4 Pattern: Welcome Animation . . . . 80
5.5 Pattern: Tutorial . . . . 83
chapter 6: home screen 87
6.1 Pattern: List of Links . . . . 88
6.2 Pattern: Dashboard . . . . 92
6.3 Pattern: Updates . . . . 95
6.4 Pattern: Browse . . . . 99
6.5 Pattern: Map . . . . 103
6.6 Pattern: History . . . . 108
chapter 7: search 113
7.1 Pattern: Voice Search . . . . 114
7.2 Pattern: Auto-Complete and Auto-Suggest . . . . 120
7.3 Pattern: Tap-Ahead . . . . 126
7.4 Pattern: Pull to Refresh . . . . 129
7.5 Pattern: Search from Menu . . . . 132
7.6 Pattern: Search from Action Bar . . . . 135
7.7 Pattern: Dedicated Search . . . . 138
7.8 Pattern: Search in the Content Page . . . . 141
7.9 Antipattern: Separate Search and Refinement. . . . 144
Contentsxvii
chapter 8: sorting and filtering 149
8.1 Antipattern: Crippled Refinement . . . . 150
8.2 Pattern: Refinement Page . . . . 153
8.3 Pattern: Filter Strip . . . . 160
8.4 Pattern: Parallel Architecture . . . . 164
8.5 Pattern: Tabs . . . . 170
chapter 9: Avoiding missing and undesirable results 179
9.1 Antipattern: Ignoring Visibility of System Status . . . . 180
9.2 Antipattern: Lack of Interface Efficiency . . . . 182
9.3 Antipattern: Useless Controls. . . . 184
9.4 Pattern: Did You Mean? . . . . 185
9.5 Pattern: Partial Match . . . . 189
9.6 Pattern: Local Results . . . . 192
chapter 10: Data entry 197
10.1 Pattern: Slider . . . . 198
10.2 Pattern: Stepper. . . . 204
10.3 Pattern: Scrolling Calendar . . . . 210
10.4 Pattern: Date and Time Wheel . . . . 215
10.5 Pattern: Drop Down . . . . 224
10.6 Pattern: Multiple Select . . . . 228
10.7 Pattern: Free-Form Text Input and Extract . . . . 232
10.8 Pattern: Textbox with Input Mask . . . . 238
10.9 Pattern: Textbox with Atomic Entities . . . . 247
chapter 11: forms 251
11.1 Pattern: Inline Error Message . . . . 252
11.2 Pattern: Toast Alert . . . . 257
11.3 Pattern: Pop-up Alert . . . . 263
11.4 Pattern: Callback Validation . . . . 271
11.5 Pattern: Cancel/OK . . . . 274
11.6 Pattern: Top-Aligned Labels . . . . 285
11.7 Pattern: Getting Input from the Environment . . . . 293
11.8 Pattern: Input Accelerators . . . . 302
Contentsxviii
chapter 12: mobile banking 307
12.1 Pattern: Login Accelerator . . . . 308
12.2 Pattern: Dedicated Selection Page . . . . 316
12.3 Pattern: Form First . . . . 321
12.4 Pattern: Dedicated Pages Wizard Flow . . . . 324
12.5 Pattern: Wizard Flow with Form . . . . 329
12.6 Pattern: Verification-Confirmation . . . . 334
12.7 Pattern: Near Field Communication (NFC) . . . . 338
chapter 13: navigation 347
13.1 Antipattern: Pogosticking . . . . 348
13.2 Antipattern: Multiple Featured Areas . . . . 349
13.3 Pattern: Carousel . . . . 352
13.4 Pattern: Popover Menu . . . . 358
13.5 Pattern: Watermark . . . . 365
13.6 Pattern: Swiss-Army-Knife Navigation . . . . 371
13.7 Pattern: Integration: The Final Frontier . . . . 383
chapter 14: tablet Patterns 391
14.1 Pattern: Fragments . . . . 392
14.2 Pattern: Compound View . . . . 394
14.3 Experimental Pattern: Side Navigation . . . . 396
14.4 Pattern: Content as Navigation/Multitouch Gestures . . . . . 401
14.5 Pattern: 2-D More Like This . . . . 404
14.6 Experimental Pattern: C-Swipe . . . . 408
Index 413
f o r e w o r D
The first thing Greg told me when we met was, “You wrote the book I was work- ing on,” referring to the book Mobile Design Pattern Gallery that I had just released with O’Reilly Media (2012). I felt a little guilty at the time, but now I am glad I beat him to it. But not for the reasons you might think.
When I started the pattern gallery, I focused on identifying universal design pat- terns across the six major mobile platforms. Two years later, the industry is maturing, and only three big players are left, each with their own distinct patterns and principles. Universal patterns are still valuable, but more valuable yet are the deep dives into specific operating systems.
Greg saw this coming and decided to focus on the fastest growing platform, Android, and the most sophisticated release yet, Jelly Bean. His book meets mobile designers and developers where they are most comfortable and expertly guides them towards mastery of mobile user experience.
This book is more of a workshop than a reference book. Greg builds upon the uni- versal design patterns for mobile devices and tablets and the Android UI design guidelines and takes the topic further into hands-on practical applications of the design principles. Each section covers fundamentals, warns of pitfalls and antipatterns, and then puts the lessons to the test by showing in detail how to redesign an existing app. You can and should bring this book to design sessions, and you should share it with your team. You will save countless hours solely from using the patterns in Chapter 7, “Search,” and Chapter 8, “Sorting and Filter- ing.” By reading and using Greg’s entire book you will tremendously improve all aspects of the mobile experience you will be creating for your customers.
Bottom line, there is no other resource out there that goes to this level of depth on Android application design. I just hope Greg writes a Windows pattern book next.
Enjoy, Theresa Neil
UX Designer, Start-up Advisor, Author/Speaker Theresa Neil Interface Designs (www.theresaneil.com)
I n t r o D u c t I o n
Let me begin by answering some questions about the book you hold in your hands.
why mobile computing?
Jim Rhodes: You're not a soldier.
Tony sTaRk: Damn right, I'm not—I'm an army.
—Iron Man, Marvel Studios, 2008 Mobile computing is the most game-changing development in human history. You live in the most exciting age—one of almost limitless potential, where your infor- mation, idea, product (in short, any meme) can reach virtually every person on the planet in a matter of days, if not minutes. And that is because no other modern technology has the reach and the potential of mobile computing. But simple pen- etration is not enough. The transformative force of mobile technology comes from the way it cradles people, empowers them to connect easier, make smarter deci- sions, and frees their minds in their soaring flight to go beyond the mundane.
With the coming of capable touch smartphones, the relationship with technology has shifted to that of intuitive digital assistant, an extra organ with super-human sensors—a true symbiosis that can best be described as a relationship of a Cyborg with his cybernetic components, or that of Tony Stark and his Iron Man suit.
Iron Man is my favorite metaphor because the suit is not a part of Tony, yet when he puts it on, he is one with the device. The Iron Man suit takes Tony’s intention and transmutes it into action, on a grand scale, and without much effort on Tony’s part (that is, without cognitive friction). At the end of the day, the Iron Man is just a man. Yet the power is always inside him, as it is in each of us. It takes this unique symbiosis with technology to truly enable and unleash that incredible power.
The mobile phone is our Iron Man suit. The mobile experience, when executed well, is a cybernetic skeleton. If you design and develop your app skillfully, your custom- ers will feel protected and empowered in a way similar to how Tony Stark feels when he puts on his Iron Man suit.
INTRODUCTIONxxii
why Android?
Anyone following mobile space is aware that in the beginning Android had a few growing pains. (And that’s putting it mildly.) Market fragmentation, overall confu- sion born out of a lack of focus and standards, and overly frequent updates all bear some of the blame. Yet like a professional prizefighter fueled by massive adrenaline and steroids, Android embraced these challenges head-on and man- aged to improve and evolve rapidly and grow market share faster than anyone thought possible.
As of this writing, the Android smartphone operating system was found on three out of every four smartphones shipped during the third quarter of 2012 (3Q12).
According to the International Data Corporation (IDC) Worldwide Quarterly Mobile Phone Tracker, total Android smartphone shipments worldwide reached 136.0 million units, accounting for 75 percent of the 181.1 million smartphones shipped in the third quarter of 2012. The 91.5 percent year-over-year growth was nearly double the overall market growth rate of 46.4 percent (https://www.idc.com/
getdoc.jsp?containerId=prUS23771812). With the release of Android 4.0 Ice Cream Sandwich, Android created a purely digital, business-like demeanor with a pow- erful core of a set of standards that work on virtually every device, while also dealing a left hook to fragmentation through a set of clever responsive design decisions for the structure of the menu and navigation scheme. All this new seri- ous business sense comes wrapped up in a set of open standards and a well- evolved code base.
In short, in my humble opinion, the state of the Android ecosystem is now the per- fect storm combining the factors for explosive near-term growth and long-term market dominance. If you have been working with Apple iOS, Windows Mobile, BlackBerry, and older Android OS, or if this is your first foray into the mobile space, today is the perfect time to look at designing and developing Android 4.0 apps.
why this book?
If you want your customers to feel as empowered when using your app as when they put on the Iron Man cybernetic exoskeleton, you need to unlock the patterns behind effective mobile design and apply them to your context. The book in your hands is the key to those patterns. Within these pages is everything you need to succeed in creating a great mobile experience.
INTRODUCTIONxxiii
use what works
This book is about what works: design patterns. A design pattern is a repeatable solution that helps resolve a particular problem within a specific context. But why do you need patterns—isn’t reading the Android design docs enough? What makes design patterns uniquely effective is the way they communicate best practices while addressing the complexities involved in real design problems. As Christopher Alexander (the early pioneer of design patterns as formal ideas) says in his book Timeless Way of Building (Oxford University Press, 1979), the patterns make up the vocabulary of a design language that can be used to build things that are whole, complete, and alive (what he calls "the quality without a name").
In addition to helping you build usable apps, design patterns are intensely practi- cal building blocks: they are small and can be learned and understood easily. You can combine patterns to create usable and delightful designs. Finally, patterns form the design language you can use to communicate simply and effectively.
Apply 58 essential Android App Patterns
In Part 2 of the book, you discover all the patterns you need to create great inter- action design and intuitive Information Architecture for your Android 4.0+ apps.
There are 58 essential interaction design patterns for dealing with the most chal- lenging aspects of the Android app design: welcome experience, home screen, navigation, search, sorting and filtering, data entry, and forms. The patterns in this book are designed to look beyond the obvious and build on the official Google documentation, allowing you to move smoothly from theory to practical applica- tions. In addition, there are specific chapters covering key design patterns for mobile banking and dealing with the tricky aspects of tablet design.
Avoid common Pitfalls with 12 Antipatterns
In addition to 58 patterns, there are 12 antipatterns, describing the most common mistakes to avoid in your quest for customer empowerment, delight, and enjoy- ment. Standalone antipatterns are mobile evolutionary dead-ends you want to steer clear of. Sometimes you also see the same antipattern icon used as part of the regular pattern. These are common pitfalls (lined with spikes on the bottom) that will catch the unwary. Read those carefully—often only a part of the screen or a specific interaction is called out as the antipattern and not the entire screen. The antipatterns and negative examples are marked with the symbol you see in the margin next to this paragraph.
INTRODUCTIONxxiv
be Inspired by Innovative Ideas
In addition to helping you build a rock-solid design pattern foundation, this book gives you the confidence and inspiration to move beyond the tried-and-true pat- terns to create exciting innovative implementations from existing mobile ideas and interface components. You can explore experimental patterns (marked with the symbol you see in the margin next to this paragraph), which stretch the existing ideas and mobile status quo.
In the workshops I teach around the world, people often ask me: “Do experi- mental patterns work?” To answer this question, let me tell you a short story.
In September 2010, I presented a pattern I called Immersive Navigation at Design4Mobile in Chicago. I suggested that the fold-out menu navigation used by games like Angry Birds can and should be adopted to more “serious” mobile applications like e-commerce, news, and social media. Many of those present were skeptical: Would this work? Can you even get these apps past Apple’s strin- gent guidelines that require the use of the tab bar? To this I replied that the Apple tab bar is merely a set of training wheels, and that I believe the mobile consumer is ready to upgrade to the latest Harley-Davidson, which, at the time, caused quite an uproar.
Less than a year later, Facebook came out with a new fold-out navigation menu on the top-left corner. Other successful apps started using it too; Flipboard, for example, used the same pattern on the top-right corner. Today this pattern, known as the Drawer, is part of the standard Android 4.0 toolkit, and it’s used by apps like Google Plus. I cannot, of course, claim credit for this development. I merely hope that I helped to provide another tiny push in the direction many tal- ented people were already taking.
Mobile design moves at incredible, unprecedented speed. Experimental patterns described in this book are possible near-future design patterns that run slightly outside current mainstream mobile approaches. For those willing to try out new ideas, these experimental patterns represent incredible opportunities to stand out from the 700,000 apps currently available in Google Play, leap-frog the competi- tion, and deliver uniquely engaging mobile experiences (“Google Says 700,000 Applications Available for Android,” Bloomberg Businessweek, 29 October 2012, Retrieved 5 November 2011). But please don’t take my word for it! Instead, I invite you to try out and customer-test the experimental patterns you like, to see if they will work for your particular project. I also invite you to use the ideas in this book as an inspiration to thinking outside the training wheels and building your own
INTRODUCTIONxxv
design approaches. As Eckhart Tolle so eloquently says in his timeless book, The Power of Now (New World Library, 2004), “Try it out and you will be the evidence.”
use a complete Design methodology
Patterns are the focus of this book. However, Part 1 describes the complete sticky-notes methodology for building effective, cheap prototypes and customer- testing them. Part I also includes an entire chapter on Android visual design prin- ciples and a case study demonstrating the hands-on use of the principles.
The book you hold in your hands is the practical, hands-on culmination of 14 years of designing and building digital products. In it I share the most effective meth- odologies I developed for mobile customer-centered design. But you don’t just get one chapter on methodology! Instead, a customer-centric methodology for mobile design is woven into every pattern. Practically every one of the 58 patterns in this book is accompanied by a meticulous, detailed drawing of how this pattern or interface control would look when implemented using the sticky-notes meth- odology, one you can use as a guide to create your own lean agile prototypes. If you need help, don’t hesitate to ping me and my team at www.AndroidDesignBook.com, the companion site for this book, where you can watch detailed videos of mobile usability testing and get all your questions answered. This book is all about what works, and I want to make sure you get the most value from these patterns by put- ting them to work yourself on your own project.
Design what works
I am not an adoring foam-at-the-mouth Google groupie. I have far too many proj- ects under my belt—projects that required compromise, out-of-the-box thinking, and striking innovation—to be devoted to a single idea or doctrine. I have also seen many so called “pure” projects of every kind fail miserably. Thus in this book you will see Android adaptations of great ideas from other mobile operating sys- tems such as Apple iOS, Windows Mobile, and even (gasp!) BlackBerry.
I outline the unique capabilities of the new Android OS in Part 1 of the book, while focusing the bulk of the material on practical issues that come up in design projects and effective solutions for solving real-world challenges. In short, this book is the compendium of everything you need to design great-looking and great- performing modern Android apps. Now, if you are ready to start, let’s do this thing!
INTRODUCTIONxxvi
what About the code?
Glad you asked! After all, fantastic, intuitive design is all well and good, but you need to implement it at some point. There is no code in this book. Separating design from implementation was a deliberate decision because mobile design is a sophisticated endeavor with crushing constraints and pitfalls at every step of the way, so it took the entire book just to get through the design portion of the project.
To help you with coding your app, I have built a companion book site, www. androiddesignbook.com, especially to provide the complete support for
Envision-Design-Build app life cycle. On the site there are more than 100 articles, numerous code examples, and mini-apps you can learn from and copy for your own purposes; regular design webinars, which deal with audience-posed design challenges; and a dedicated team of experts to answer your questions. Most important, there is a large supportive Android community to help you every step of the way. And an Android design certification program is being set up. You can register free with your e-mail simply by typing the code DROIDRULES into the space provided on the sign-up form.
I hope you join us!
how should You use this book?
This book is meant to be a hands-on reference throughout the design and devel- opment life cycle of your Android app. Part 2 of the book is something you will refer to over and over again. However, I—along with the fantastic editors at Wiley—have spent considerable effort to write the book as a story you can read from the beginning to end. Antipatterns are usually at the beginning of the chap- ters that include them. Simpler patterns are found earlier in the chapter, and more complex experimental ideas are placed toward the end. General patterns are at the beginning of Part 2, and the more specific applications, such as mobile- banking and tablet-specific patterns, are at the end of the book.
If you have a specific question, by all means, start with the pertinent chapter and dig in! However, at some point (sooner better than later) you should read Part 1.
It is meant as a brief, effective introduction to the Android 4.0 design and sticky- notes design methodology. Even if you consider yourself an expert, at the very least, be sure to read Chapter 1, which includes the AutoTrader redesign case study. It’s a great place to get your feet wet before you dig into the patterns in Part 2.
INTRODUCTIONxxvii
who should read this book?
I come to the discipline of customer-centered design from the background of back-end Java software architecture and Oracle databases. Thus, the material is hands-on, and the intended audience for this book is anyone involved with design- ing and developing Android apps. The book is aimed at mid- to advanced-level practitioners. However, a determined beginner can get full value from the book by using the design methodology to design, experiment, and build up skills to turn into an Android design expert. However, from the standpoint of design, goals, and monetization models, this book will likewise greatly benefit product managers, project managers, visual designers, user researchers, and business people by providing a common vocabulary with which to discuss mobile design and develop- ment challenges and various practical approaches to solving them.
PA r t I
UX Principles and Android OS
Considerations
Chapter 1 Design for Android: A Case Study Chapter 2 What Makes Android Different Chapter 3 Android Fragmentation
Chapter 4 Mobile Design Process
c h A P t e r 1
Design for Android:
A Case Study
This book is about what works: design patterns. Design patterns in this book build on the official Google Android design guidelines by com- municating best practices while addressing the complexities involved in real design problems. The official Android guidelines (available at
http://developer.android.com/design/get-started/ui-overview.html
) form the foundation; this book shows you how to bring these guidelines to life as complete solutions to real-world design challenges.
With this chapter, I am laying the foundation for the 58 patterns (and 12
antipatterns) in the book by providing a case study of an app that could
benefit from a more refined design—the AutoTrader app. The appropri-
ate patterns are referenced in each section of this chapter; feel free to
flip to the relevant pages to explore design solutions in more detail.
Chapter 1: Design for android: a Case Study4
The AutoTrader app is a typical example of a straight port, which is to say that it is basically an iOS app that was quickly and minimally made to work for Android. The following sections show you how to redesign this app for Android 4.0+ (Ice Cream Sandwich). The entire app isn’t covered because this would be exceedingly tedious to write (and even more tedious to read). Instead, three representative screens are discussed: home screen with a search form, the search results screen, and the item detail screen. These three screens should give you a good idea of some unique and interesting aspects of the Android visual design and navigation, and they give you a taste of the interaction design patterns in this book. Think of this chapter as an appetizer for a rich smorgasbord of practical solutions waiting for you in Part 2 of the book.
launch Icon
The first thing to look at is the launch icon. Most apps that do a straight port from iOS neglect the essential part of redesigning the launch icon. The Android launch icon design is not bound by the iOS square shape with rounded corners. Designers are encouraged to give their Android launch icons a distinctive outline shape. Take a look at the launch icons for Yelp and Twitter in Figure 1.1—these folks get it.
Figure 1.1: The Yelp and Twitter launch icons have distinctive shapes.
Action Bars and Information Architecture5
In contrast, AutoTrader, the app for the case study, did not take the time to cus- tomize its icon. Fortunately, this is often a simple modification. In the case of Auto- Trader, one suggested redesign is included in Figure 1.2. You could use the letter
“A” borrowed from the rebranded iOS app and remove the background fill to cre- ate a distinctive shape. You are not bound to use a part of the logo—for instance the icon could have been in the shape of a car or steering wheel. The eye more readily perceives the shape of the icon when it is different from other apps, so this enables AutoTrader customers to find the app more easily in a long list.
Figure 1.2: The initial AutoTrader launch icon isn’t distinctive, so here’s a redesigned icon.
Action bars and Information Architecture
In general, action bars and the accompanying functions form the nerve center of an app and are important in the overall design. Unfortunately, the current design of the AutoTrader app leaves much to be desired on this front (which is what makes this such a killer case study).
before
Look at the default home screen: the Car Search. The most emphasized menu function is Settings, which is prominently featured in the top-right corner (see Figure 1.3). That location is arguably the second-most important and prominent spot in the mobile UI (the most prominent spot on the screen is top left, occupied by a large logo).
Although it’s admirable to try to feature the Settings function, I unfortunately could not imagine a single primary or secondary use case that involves this func- tion. Especially because what is labeled as Settings is nothing more than the placeholder for lawyer-fluff such as the privacy policy, visitor agreement, and a button to e-mail feedback—hardly the essential functionality that the app needs to feature so prominently!
In contrast to the over-emphasized Settings button, the essential functions that need to be used, such as Find Cars, Find Dealers, Scan & Find, and My AutoTrader, are hidden in the older, Android 2.3-style navigation bar menu (see Figure 1.4).
Chapter 1: Design for android: a Case Study6
Figure 1.3: The AutoTrader app emphasizes the useless Settings function in the home screen design.
Figure 1.4: The AutoTrader app places essential functions in the old-style navigation bar menu, which is an antipattern.
Action Bars and Information Architecture7
The next section describes how the app could be redesigned according to the Android 4.0 guidelines to use action bars effectively and make the most important functions more prominent.
After
The first thing to fix is the style of the buttons. The rounder corners and bevels simply must go. So do the word-driven functions, such as Settings, in the action bar. In Android 4.0 the actions in the action bar are shown with icons, and the actions in the overflow menu are shown with text. Sticking to this scheme, the first suggestion is for the straightforward port of the old menu to the action bar, which might look like what’s shown in Figure 1.5.
Figure 1.5: Version 1 is a straightforward port to Android 4.0 with settings and actions in the overflow menu.
In this version, the settings button has become the hammer and wrench icon, and the bottom navigation menu has been moved into the overflow function on the action bar. The giant company logo is replaced by the Android 4.0 style action bar icon (which matches the launch icon “A”) and the screen title. (Note that according to the Android design guidelines, the screen title may not exceed 50 percent of the width of the screen, which is not a problem here; it’s merely something you need to keep in mind.)
Chapter 1: Design for android: a Case Study8
Unfortunately, as discussed in the “Before” section, these changes are not nearly enough. This basic redesign takes care of the Information Architecture (IA) port to Ice Cream Sandwich, but it does not take care of the inherent shortcomings of the app’s current IA: Key functions such as Find Dealers and My AutoTrader are still hidden, and the Settings clearly does not go anywhere useful. Worse, placing Set- tings on the top bar would actually discourage exploration of the menu because if the customer discovers that the Settings function is basically pretty lame, that would send a strong signal that the other functions hidden in the overflow menu are even more useless. The design can be improved even more.
One possible approach would be to bubble up the Find Dealers and My AutoTrader options to the top action bar and remove the Settings to the overflow menu.
Figure 1.6 shows how this might look.
Figure 1.6: In Version 2, the more useful functions are on the top action bar and settings have been moved to the overflow menu.
This is an acceptable IA, and it is in line with the current Google Android recom- mendations for the Ice Cream Sandwich (4.0) and Jelly Bean (4.1) OS versions.
However, it points out some key challenges with the implementation of the current UI specification of the action bars. For instance, on most devices, you cannot have more than a few functions on the action bar without taking up more than the rec- ommended 50 percent of the available space. Furthermore, placing more actions on additional action bars robs the app of the vertical real estate it so desperately
Action Bars and Information Architecture9
needs while also adding visual noise and complexity. This is not a small consider- ation that can be easily dismissed.
The main challenge is cognitive: Not every action can be easily represented with only an icon. For instance, in Figure 1.6, I use both of the original Find Dealers and My AutoTrader icons. While neither icon is bad, either one can be easily misinter- preted, as can most of the icons meant to represent complex or unusual actions.
You could remove all the icons and place all of the actions in the overflow menu, but that solution is also far from ideal because it forces all the menu items to be solely text. When you use only text you miss out on the playful aspect that the icons bring to mobile computing, which is—at least for me—at the heart of what mobile navigation is all about. I have seen repeatedly that using icons and text together makes navigation most effective. When customers first learn the app, they rely on both aspects of the navigation. After using the app for a while, the icon often offers enough information scent to ensure recognition of the action behind it. So does Android offer a way to use both icons and text together?
Fortunately, the recent redesign of the Google Plus app points the way to use both icons and text by using a Drawer element (see Figure 1.7). The Drawer and other Swiss Army Navigation pattern techniques are covered in Chapter 13,
“ Navigation,” so it’s not necessary to cover them here. Suffice it to say that the Drawer user interface (UI) element enables both icons and text—the best of both worlds.
Figure 1.7: The Google Plus app design uses a Drawer menu that includes both text and icons.
Chapter 1: Design for android: a Case Study10
The Android UI specification encourages the use of the Drawer element for top-level navigation if there are a number of views in the app that do not have a direct relationship with one another. This is exactly the case you have with Auto- Trader. The Car Search area of the app is different from the Find Dealer and My AutoTrader views, so placing these top-level navigation functions in the Drawer menu (shown in Version 3 of the redesign in Figure 1.8) makes a lot of sense. Scan
& Find is a car search function, so it makes sense to make it contextual to the Car Search view. It is accessible with a single tap on the action bar. The useless (but, as the lawyers would argue, necessary) Settings function is the only one that hides in the overflow menu; it does not need to be accessible with one tap, so hid- ing it is the best strategy.
Figure 1.8: Version 3 is the recommended design for the AutoTrader app: a top-level redesign that uses a Drawer menu.
Version 3 is the preferred design. It strikes a good balance of showing both the icons and the text, while making the navigation accessible using a right-to-left swipe or a tap on the Up icon (left caret or <). It also frees the top action bar for showing a good-sized, clear screen label. One recommended modification to the standard Android guidelines is a thin line all along the left edge of the screen that signals to customers that they can open the Drawer menu by swiping from right to left (as well as by tapping the Up icon).
The Android UI guidelines caution that the Drawer can be used only for top-level navigation, which means that while your customers are deep in the middle of the
Action Bars and Information Architecture11
flow inside the Car Search view, they may be one or more steps away from access- ing the additional views. The good news is that—with the global navigation out of the way—the action bar can include functions that are contextual to the page the cus- tomers are on, which is recommended by the Android design standards document.
tabs
Tabs are an essential element of secondary navigation that can be used in the Android platform for a variety of applications. The Tabs pattern is covered in Chapter 8, “Sorting and Filtering.”
The AutoTrader app uses the iOS style visual design rendering for the tabs with rounded corners and the “depressed” beveled look for the selected tab (see Figure 1.9).
Use a simple redesign of the control with end-to-end underline; no shadows, bev- els, and rounded corners. The heavier “underline” element signals the selected tab. In this screen, there is just enough space for compact text labels (Basic | Advanced | Recent) so that is what is used in the suggested redesign.
What if the screen was smaller than could comfortably accommodate the full text in the tabs? Then the text labels would turn into corresponding icon-based tabs.
As you read in Chapter 2, “What Makes Android Different,” the scalability of run- ning the interface on devices with smaller touch screens is a key differentiator for the Android OS. This scalability in turn dictates many of the basic visual design choices and guidelines.
Figure 1.9: The top shows the tabs in the AutoTrader app before a suggested redesign; the bottom is the suggested Android 4.0 treatment.
Dedicated selection Page
Dedicated Selection Page is the primary pattern for selecting from a long list. It’s covered in more detail in Chapter 12, “Mobile Banking.” The AutoTrader app uses the iOS-style selection with the greater than sign, (right caret or >). (See the top of Figure 1.10.)
Chapter 1: Design for android: a Case Study12
Figure 1.10: The top shows the link to the Dedicated Selection Page before redesign; the bottom is the suggested Android 4.0 treatment.
iOS uses the > to show row-based interactivity. In contrast, in the Android OS there is no indication of the underlying functionality. As discussed in Chapter 2, the concept of Tap Anywhere is an important one to the Android OS. If there is any reason to tap anything like a selector, the assumption is that it will carry the cor- responding interactivity. Thus, visual design is implemented accordingly in a typi- cal Spartan Android fashion, using a slightly darker row background and without the right caret.
select control
The Android platform comes with a full complement of touch-friendly controls that you can use on multiple screen sizes and device configurations. Ice Cream Sandwich comes fully equipped with touch sliders, a completely redesigned text entry, and a new dual-function wheel control, discussed in great detail in Chap- ter 10, “Data Entry.” For this section, suffice it to say that the AutoTrader Android port still uses the iOS-style form controls and form section headers. The follow- ing sections describe how to redesign them, Android-style.
before
The first thing to notice is the composite iOS-style wheel control that the cus- tomer uses in the AutoTrader app to select the year and price (see Figure 1.11).
Action Bars and Information Architecture13
Figure 1.11: The AutoTrader app uses an iOS-style form for selecting the year and price.
The iOS control is a non-native wheel that needs to change to the Android-style controls. Check out a couple of ideas in the following “After” section.
Another important aspect of the form design is the rounded container for the entry fields with an iOS-style section header. As discussed in Chapter 2, Android uses the Mobile Space, Unbound visual style principle that removes any contain- ers and boxes, especially those with rounded corners.
Chapter 1: Design for android: a Case Study14
After
As discussed in Chapter 10, there are various touch-friendly ways to implement entry of the range of values in Android. The most straightforward one is to convert the combo wheel into min and max wheel controls (marked by a line with a small triangle on the right). Figure 1.12 shows one idea how this might look.
Figure 1.12: The redesign uses native Android wheel controls and a section header.
Although wheel controls offer a decent solution, you can use a variety of other interaction design patterns. Chapters 10 and 11 discuss a composite Drop Down control, separate min and max Sliders, a Dual Slider, and a Slider with a Histo- gram experimental design pattern. Applying those patterns is not complicated, but it is a sophisticated endeavor, which is discussed in detail in Part 2 of the book. The patterns are designed especially to limit the cases of zero results in the search, such as picking a price range that is too low or having no inventory for a specific desired year, which is the topic discussed in detail in Chapter 9, “Avoiding Missing or Undesirable Results.”
Forms in the Android 4.0/4.1 are allowed to flow in order to conform to a variety of screen heights and widths. Thus, instead of using containers for form sections, various parts of the form are separated from one other by simple headers. Native headers are in the all capital Roboto font (Helvetica is used in the figures) under- lined by a thin separator line of the contrasting color.
buttons
The AutoTrader app uses iOS-style buttons with rounded corners and bevels. The buttons are in two different heights and visual treatments, with lots of space in between, which makes the screen look rather lopsided. In addition, the buttons are positioned as Search/Reset, in other words in the OK/Cancel order (see Fig- ure 1.13). As described in Chapter 11, “Forms,” the preferred button orientation is the opposite: Cancel/OK, so the redesign flips the buttons from their “before”
layout positions.
Action Bars and Information Architecture15
Figure 1.13: The current AutoTrader buttons are shown at the top; the redesign is in the middle; and an alternative of Android “tap areas” is at the bottom.
In contrast, the Android buttons are business-like: flat, with no gradient and just barely rounded corners. The preferred Android Cancel/OK button treatment is to turn them into square solid tap areas that occupy 100 percent of the width of the screen, with just a hint of a separator. Tap areas are discussed further in Chapter 2. I chose to emphasize the primary action button, Search, and make it easier to tap by making it larger and adding a magnifying glass icon.
search results
With the home screen and the IA redesigned, now turn your attention to the search results screen. Search results appear immediately after the customer searches with the home screen form, so this makes sense.
before
Again, the search results screen for the AutoTrader app has been generally designed without adopting it to the Android Ice Cream Sandwich and Jelly Bean OS guidelines (see Figure 1.14). The screen uses mainly iOS standards, with a light mixture of Android thrown in. The screen uses three buttons: two with text and one with an icon. All three buttons use rounded corners and bevels. In addition, each result on the screen uses the iOS right caret > treatment. As seen previ- ously on the home screen, the top app menu can be obtained by tapping the menu key in the navigation bar on the bottom of the device.
Chapter 1: Design for android: a Case Study16
Figure 1.14: This is what the search screen looks like before redesign.
After
The Drawer top navigation menu is safely out of the way on the Search Results screen. Tapping the icon in the top-left corner navigates back to the home screen, where the customer can get to the top menu by tapping the same button again.
This leaves space on the screen for contextual action buttons: Filter, Map, and Share (see Figure 1.15).
Starting with the Ice Cream Sandwich OS, the Share function has been a special use case because of the multiple built-in sharing functions. Thus you can imple- ment Share as a standard drop-down menu per the Android UI design standards.
The remaining Map and Filter buttons are implemented as the Android-style flat
Action Bars and Information Architecture17
single-color icons, which are placed right on the action bar. This is one way that the map-list relationship can be implemented. Many more effective search and filtering patterns are discussed in Chapter 7, “Search,” and Chapter 8.
Figure 1.15: This is Version 1 of the redesigned AutoTrader app search screen with Title Bar.
In addition to using the title bar treatment of the action bar, one other version is possible: a drop down control that can be used to select from multiple views: in this case from several different ways to sort the inventory. In this Version 2 of the redesign, the screen title (maker and model of the car) is displayed above the multiple views drop-down. Version 2 of the redesign is recommended because it adds key functionality by taking full advantage of the Android 4.0 capabilities (see Figure 1.16).
Chapter 1: Design for android: a Case Study18
Figure 1.16: Recommended Version 2 of the AutoTrader app search screen redesign adds a Sort view selector.
The last thing to notice is the absence of the right caret > symbol in the search results. As mention earlier, touch space on the screen should be tap-enabled without having any special visual indicators. If an action, such as drilling down to the Result Detail screen, is valuable to the customer it should be enabled as a touch target without any external visual indicators. Speaking of which, it’s time to pretend someone actually tapped the search result. The next section describes the third and final screen: Result Detail.
Action Bars and Information Architecture19
result Detail
What happens when the customer drills down into a car detail screen? It turns out that the last screen offers many opportunities for the new Android redesign, from IA to tabs and buttons.
before
The detail screen again includes many iOS elements (see Figure 1.17). As dis- cussed earlier, tabs are text-based and have bevels and rounded corners. Simi- lar to the search results screen, there is another Share button; however, in this screen it occurs twice: once on the top menu bar and once inside the screen in the guise of a Save/Share button. This is confusing.
Figure 1.17: This is what the original AutoTrader app Result Detail screen looks like before redesign.
Chapter 1: Design for android: a Case Study20
Other actions include call and e-mail the seller, yet no primary button can be identified in the entire set—it is not clear what the app wants the customer to do first. The rest of the screen is laid out using containers with rounded corners;
those have to go, of course.
Most important, the only way to navigate to the next item in the list is to “pogostick”:
Press the Back button to return to the search results screen and then select a differ- ent detail screen. (Pogosticking is a navigation antipattern described in Chapter 13.)
After
In the redesigned version of the screen, continue with the simple Up navigation by removing the global navigation functionality. But where should the action buttons go, and what’s the best way to identify the primary action that’s most likely to be taken by the customer? It’s easy to understand one way to implement this solution in the Android OS 4.0 by looking at the native Android Gmail app detail screen (see Figure 1.18).
Figure 1.18: The Gmail app uses the Swipe Views control in the Result Detail screen.
Action Bars and Information Architecture21
To reduce pogosticking, the native mail app uses a clever Android OS interface control, Swipe Views, to make navigation more efficient. This control enables the customer to swipe from right to left to get to the next result detail. This function- ality is shown to the customer using a thin, dark line on the bottom on the screen that states "2 of 133". Although this function works, in testing, the discoverability was poor. So for the redesign of the Android AutoTrader app, you should use a brief onscreen overlay tutorial as described in Chapter 5, “Welcome Experience,”
or an animated transition Watermark pattern described in Chapter 13 to high- light the Swipe Views control for the customer and improve discoverability of this important feature. Regardless of the introduction you choose to display, after the customer learns the action, the tutorial is no longer necessary and can be sup- pressed, so these patterns aren’t shown here.
The swiping action in some applications is used to navigate between tabs.
Because you want to preserve the swipe-to-next action to navigate to the next item detail, use the tap-only tabs on the top of the page, as shown in Figure 1.19.
Figure 1.19: This is how you can redesign the AutoTrader detail page.
Chapter 1: Design for android: a Case Study22
The primary and secondary contextual actions can now be placed in the action bar. Because there are only three actions on the car detail page, you need only a single action bar on the top, which accommodates all three actions above the tabs, next to the screen title (the name of the listing). If you need more space on smaller devices, or if future design iterations add more functionality, some of the detail page actions can either migrate to the overflow menu or to the split action bar that’s covered in the next chapter. Last but not least, remove all the containers on the screen, replacing them with Android 4.0 headers, following the Mobile Space Unbound principle discussed in Chapter 2. Note that frugal use of the real estate allows the redesigned screen to show several additional lines of text—no small feat on the mobile screen!
bringing It All together
Figure 1.20 shows three AutoTrader screens before the suggested redesign. Note the older IA and iOS treatment of the controls, fields, and buttons. Sections of the screen are separated from one another by containers with rounded corners.
Within each section, the elements that implement interactivity are especially called out by the > symbol to separate them visually from noninteractive ele- ments, giving the overall visual style a heavy appearance.
Figure 1.20: This is what the three AutoTrader screens look like before redesign.
Action Bars and Information Architecture23
In contrast, Figure 1.21 shows the three redesigned screens imbued with Android 4.0 DNA.
Figure 1.21: The three AutoTrader screens redesigned for Android 4.0.
In the redesign, a set of specialized touch controls and a unique navigational scheme recommended by the Android 4.0 guidelines are used. From a visual per- spective, the new design uses flat buttons, touch panels, and action bars that are mostly devoid of gradients and rounded corners. Finally, the new design removes any containers and extraneous touch indicators.
Throughout the process you examined several different versions of each screen.
This is natural: Android design is not complicated, but very sophisticated: with crushing space constraints and exciting novel interaction opportunities. That is why it’s a great idea to customer-test new design ideas thoroughly before they are implemented, using quick, inexpensive prototypes. I prefer to do prototyping and testing with sticky notes, and throughout this book you see many examples of using this design methodology. Chapter 4, “Mobile Design Process,” provides a detailed description of the entire design and prototyping process and offers prac- tical techniques to tackle customer testing with confidence.
AutoTrader offered a great opportunity for showing the detail of the Android visual design language and widgets, which kicks off the book with a powerful example.
However, this is just a short overview of many innovative, interesting, and use- ful design patterns found in Android. Before digging into the design patterns that form the bulk of the material for the book, the next chapter provides a quick look at a few aspects of Android that make it different from the other mobile operating systems.
