Chapter 2
What Makes Android Different
For many years since its release, the Android OS has been behaving like a teenager in the grip of raging hormones. Growth has been nothing short of explosive, and the changes have been sweeping and profound. With the release of Ice Cream Sandwich, the user interface (UI) standards and design elements have changed dramatically, and the platform has matured and stabilized somewhat. Nevertheless the OS has retained its rebellious hacker DNA with unique features that are authentically Android.
Welcome to Flatland
The first thing you might notice when comparing the Android OS apps with Apple iOS is that the world of Android apps is flat. Flat are the buttons. Flat are the content areas. And flat are all the toolbars and controls. Just like the Flatland people from Rudy Rucker’s story, “Message Found in a Copy of Flatland,” Android does not “see” anything outside two dimensions. Nor does it pretend to be anything other than a pure digital artifact: a thing imagined and created, not real in any physical sense. It’s a piece of software that runs the hardware, not the other way around. And that, as far as I am concerned, is a very good thing. Why? Because dispensing with the need to make things “real” and “pretty” allows the content to shine and sets a stage for the authentic minimalist digital experience for your customers. In many ways, Android 4.0 uses a flat digital visual scheme similar to that used in Windows Modern UI, another mobile operating system that stands in sharp contrast to Apple iOS.
Compare, for example, the Android Messaging app with the iOS counterpart in Figure 2-1.
Figure 2-1: Compare the two Messaging apps from iOS and Android 4.0.
The first thing to notice is the information density: There is a great deal more content crammed on screen in the Android app. Part of the reason is that the iOS uses the “speech bubble” representation of the message, whereas the Android app is simply listing messages in the table. Boring? For some folks, perhaps. However, Android makes no excuses and no decorations—the app is a straightforward, flat, and highly functional SMS machine. The overall visual scheme is reserved, almost corporate. Notice also the toolbars: iOS dictates that the toolbar elements have a three-dimensional quality that makes the elements seem to pop off the page. This is achieved with the gradients that help digital objects like toolbars visually approximate the physical world. In contrast, the Android toolbars, and indeed the entire page is decidedly two-dimensional and completely free from having to look like a physical object. Unabashed embrace of Flatland and “freedom from three-dimensions” opens the door to creating menus that are semitransparent (see Figure 2-2) and commit fully to the “content-first” directive. (Various menu styles are covered in more detail in Chapter 13, “Navigation.”)
Figure 2-2: Compare the semitransparent menus of Android 4.0 in the Google Earth app to the physicality of iOS menus in the iPhone app.
The entire Android screen is built with grayscale, using just enough color to make the toolbars a bit darker, whereas the content areas mostly remain light. Color is one area in which many other mobile OSs, such as Windows Modern UI, contrast strongly with the Android Ice Cream Sandwich OS. Even though both design languages embrace the Flatland, Windows Modern UI veritably explodes with both color and interactivity, and the home screen literally “pops” with movement, as each element vibrates, flips, and slides with clever transitions and contrasting color combinations. In contrast, a typical Android screenlooks compact, serious, business-like, and provides only the essentials—exactly like a typical wireframe. Even more interesting, this “flat world” scenario applies to buttons and tap-targets. Android “buttons” also have no gradients, which is the subject of the next section.
Tap Anywhere
In the early days of using the mainframe workstations (that was a very long time ago), I remember being stumped when first seeing the message Tap Any Key to Continue. Programming was such a precise discipline, that it seemed inconceivable that any key would work. You could tap any key, but which is the best key? Is one better than the other? Of course the confusion quickly passed, and I learned to enjoy the freedom to just jam anywhere on the keyboard without having to think hard—most of the time just hitting the space bar with my thumb.
Android takes buttons to a new level. Whereas the iOS painstakingly identifies any tap-worthy element with the three-dimensional beveled button, Android simply assumes that any element on the screen is a tap target, often providing no additional clues. Compare, for example, the two message rows in the messaging app shown in Figure 2-3. The iOS implementation provides the beveled, round circular > button, whereas Android in contrast provides…absolutely nothing.
Figure 2-3: Compare table rows in Android 4.0 and iOS.
In Android 4.0 the customer must figure out that she can simply tap anywhere on the element (that is, anywhere in the row) to get more information. The initial cognitive friction for taking the action is often high, especially if the customer is transitioning from iOS or previous Android versions. However, most people figure out the new visual scheme quickly: If a customer wants more information about something, she is (usually) able to tap it (even if an element has no visual tap affordance). Android trains customers to simply “tap any key to continue.”
The Tap Anywhere visual design principle finds its ultimate expression in the typical Android buttons, which are implemented instead as “tap-worthy areas” (to borrow a favorite catch phrase from the mobile design expert and book author, Josh Clark, http://globalmoxie.com). In Figure 2-4, the iOS takes the time to make sure the buttons look and feel tappable with an elaborate combination of a prominent bevel, inner drop-shadow, and gradient.
Figure 2-4: Compare the Android tap-worthy areas to the iOS beveled buttons.
In contrast, Android commits whole-heartedly to the Tap Anywhere approach, using areas instead of buttons with just a hint of a vertical separator. This underscores the Android theme of not defining rigid visual border areas for tap targets and not wrapping touch targets with whitespace. This theme is profound because in its purest expression this means that everything on the touch screen is a touch target. For designers, this is both a challenge and an opportunity. It’s a challenge because without primary or secondary tap targets, a consumer might be justifiably confused about the tap-any-button scenario: “If you can tap anywhere, which area is the best one?” The Tap Anywhere scenario also presents a hefty challenge for designers and developers: Everything that the customer would conceivably want to touch should be responsive and do something intuitive. This book discusses how to adhere to this design principle without losing sight of your customers’ primary goals (and your development budget) in Chapters 10, “Data Entry,” and 11, “Forms.”
Tap Anywhere is also a tremendous under-exploited opportunity to introduce accelerometer gestures, multitouch gestures, and “hidden” menus that promulgate the content-forward design and promote immersive digital experiences. The myriad exciting possibilities are covered further in lucky Chapter 13, “Navigation.”
Right-Size for Every Device
In the early days of Android, it became clear that simply porting the Apple menu model to every device would result in failure. Part of the reason was the tremendous range of different devices that were running Android: From the tiny HTC Hero, to the 7- and 10-inch tablets, to Android-enabled ski-goggles, smart homes, and in-car touch control panels—Android interfaces offer a great variety of space constraints in which customers must operate. Recall from the AutoTrader app case study in Chapter 1, “Design for Android: A Case Study,” that simply hiding every function in the navigation bar menu on the bottom of the screen as Android had done for versions 2.3 and earlier was not the answer, either, because it hid vital functions for devices that actually had the space to show them, as well as made having more than three or four contextual actions difficult (see Figure 2-5).
Figure 2-5: This example from the AutoTrader app demonstrates how the hardware menu functions for Android 2.3 and older hide essential functions.
To solve this problem, Android 4.0 designers used an authentic mobile solution: the overflow menu. To understand how to design for Android 4.0 and 4.1, it is essential to understand how this menu works. Functions are distributed to one or more menus called action bars. When the interface distributes functions along more than one action bar, the second action bar is called…get ready for it…a split action bar. An app with two action bars is shown in Figure 2-6.
Figure 2-6: The Gmail app has an action bar at the top and a split action bar at the bottom.
Regardless of the number of bars (typically one or two: the action bar on the top and the split action bar on the bottom), the menu acts as an accordion, expanding and contracting with the available screen real estate. Smaller screens get only a few essential functions. Larger screens such as in tablets get the entire available menu, with a bias toward having only a single action bar. Additional functions that do not fit on the action bars end up in the overflow menu, which is an excellent, highly scalable, mobile solution to the problem of limited real estate. Figure 2-7 shows a comparison of menus on a tablet (top) and a phone (bottom).
Figure 2-7: In the Gmail app on smaller screens, extra functions move to the overflow menu.
In stark contrast to iOS and older Android menus, the action bars, as a rule, use only icons, whereas the overflow menus use only text. Icons and words together are still used in Android 4.0—for example, in places such as some Cancel/OK action buttons and in the Drawer menu in Google Plus, as shown in Figure 2-8.
Figure 2-8: The Google Plus app uses icons and text in the Drawer menu.
Action bars combined with the overflow menu usually enable the Android to work reasonably well on a majority of screens and device orientations. However, not all resulting UIs are ergonomically desirable: Specific device constraints are discussed in the next chapter. Chapter 13 discusses how to make the most of this pattern using the “hidden” menus and active corners in Swiss-Army-Knife Navigation, and Chapter 8, “Sorting and Filtering,” shows you different menu approaches for essential functions like Search. Discover how to design effective 7- and 10-inch tablet UIs in Chapter 14, “Tablet Patterns.”
Mobile Space, Unbound
One important corollary to the principles of Tap Anywhere and Right-Size for Every Device is the unabashed removal from the interface of containers of any kind, in stark contrast to iOS, which typically features multiple containers with rounded corners, as shown in Figure 2-9.
Figure 2-9: The iOS Settings app demonstrates emphasis in iOS on UI containers.
Many designers point out that the defining features of the Windows Modern UI (see Figure 2-10) are the multicolored square containers, called tiles, as well as the unifying backgrounds and sweeping headers in the Panorama controls (read more about those in Chapter 13).
Figure 2-10: Windows Modern UI Settings app demonstrates the sweeping backgrounds and titles in a Panorama control.
In contrast to both iOS and Windows Modern UI, one of the signature features of Android 4.0 are the simple headers that completely dispense with containers. Instead of containers, when separation of the UI elements’ sections is necessary, Android 4.0 OS uses the contrasting colored headers, executed in uppercase Roboto font and underlined with a horizontal divider, as shown in Figure 2-11.
Figure 2-11: The Android 4.0 Settings screen uses simple headers instead of containers to promote page flow.
This general absence of containers promotes flow of the forms and uses every pixel to emphasize the content. The absence of containers also helps the UI look great on a variety of devices, regardless of the width and height of the screen.
Containers behave best when they are smaller than the size of the screen; in other words, the screen shows more than one container. For this reason, containers in iOS often behave awkwardly when the device is positioned in the horizontal orientation. This is a special consideration for Android because, as discussed earlier, Right-Size for Every Device means that the interface must work for every screen, no matter how small or strangely proportioned (within reason of course). Thus containers as an interface principle do not work well because they cannot be adjusted dynamically for every situation. Instead, the content flows free, unbound, and adjusts appropriately to the size of the screen.
Unfortunately, nothing on the mobile platform comes free, and the absence of containers is no exception. Although form flow is enhanced, the absence of containers places an extra burden on vertical spacing to help separate the form fields from one another. On smaller devices sometimes this can be difficult, resulting in the forms that simply seem to go on forever without any idea where the person is at any given moment. The other issue is the minimalist color treatment. In the Settings screen, the headers are rendered in light gray, which is similar to the color of the links. In other native apps like Calendar, the headers are colored in the same way as the active fields; Both are light blue. Either treatment can cause confusion because it is not clear which are the active tappable fields and which are the headers. Using a header color that is visually distinct from both the active links and active fields is a good basic usability practice and usually helps resolve the confusion.
Think Globally, Act Locally
One of the most interesting and brave principles of the new Android 4.0/4.1 design scheme is the local-actions-first principle. Practically all other OSes on the market, including the older Android OS versions, take special care to make global navigation available throughout the app. For instance, Apple iOS does this through the prevalence of the tab bar, as shown in Figure 2-12.
Figure 2-12: The Amazon.com app uses the iOS tab bar to make global navigation accessible throughout the app.
The same principle used to apply to the older, pre-Ice Cream Sandwich Android apps, such as the pre-4.0 Android Amazon.com app design, as shown in Figure 2-13.
Figure 2-13: Older Android apps have a global menu in the navigation bar as in the Amazon.com app.
In contrast, Android 4.0 offers the customers a brave, new world in which the actions presented to the customer are always the most appropriate ones to the task at hand.
For example, in the Mail app as shown in Figure 2-14, the key actions in the action bars on the app’s summary pane are Search, New Message, and so on, plus a few more general actions such as Settings, Help, and Send Feedback, which are hidden in the overflow menu.
Figure 2-14: The Gmail app’s List view shows global actions.
Drilling down into the specific piece of mail, however, makes a dramatic change to the available actions. In Figure 2-15 instead of the top-tier menu items, such as Search and New Message, you see contextual actions such as Favorite and Reply (the star and arrow icons on the top bar), as well as commonly used Archive, Trash, and Tag (the file cabinet, trash can, and tag icons on the bottom bar).
Figure 2-15: The Gmail app’s detail view shows contextual actions instead of the global menu.
The more general action such as Settings, Help, and Send Feedback are still available in the bottom overflow menu, but global functions that were available in the list view are completely gone. This is important because due to the Act Locally principle, from the e-mail detail screen, it is impossible to access Search and New Message, for example. The Act Locally principle also extends to the overflow menu: The top overflow menu is not merely an extension of the message functions but instead augments the Reply options with less frequently used functions, such as Reply All and Forward.
The Android 4.0 screen label is yet another corollary to this design principle. For example, in the iOS, the screen label tells the customers where they are and the back button often spells out where people will be going should they tap it. As in the mail app example shown in Figure 2-16, iOS Mail app uses 14 of 69 as a screen title, and the Back button displays All Mail (41).
Figure 2-16: Compare the Android title header on the left with the back button and screen title in iOS on the right.
Android 4.0 offers no indication of where customers would go should they tap the back button. Instead, the entire bar is devoted to a screen label showing the subject of the e-mail—that is, where the customer is at the moment. This creates some confusion, especially among the iOS designers and customers taking on the Android design patterns. To these folks, “< + logo + label” means that the action would be going back to the destination shown on the label, in sharp contrast to the Android 4.0 where the same visual treatment means “you are at the label location” and “tapping the back button would go up a level.” Unfortunately, there is no good solution at the moment to this mental model transition, other than simply perhaps to get used to it.
If you contrast this hyper-local screen labeling with the older Android OS breadcrumb treatment, such as the one shown in Figure 2-17, you can see that the change is actually profound. The Android 4.0 OS simply ignores anything other than the hyper-local context.
Figure 2-17: Compare the Android 4.0 action bar from the Photo Gallery app on the left to the Android 2.3 breadcrumb on the right.
Using only local functions on each of the screens is a departure from the earlier versions of the mobile technology—one that signals that Android assumes that people are no longer going to be “lost” without some global tab navigation showing them at all times where they are. Instead, Android 4.0 uses the “Think Globally, Act Locally” principle: The hyper-local actions and screen labels remove the global navigation (that used to be in the breadcrumb) from being in front of the customer. At the same time, in the back of their minds, Android 4.0 customers have to understand that to get to all the global navigation, they must press the back button one or more times.
Interestingly, this hyper-local context does not exactly fit with many apps’ best use cases. For example, Facebook is a notable exception that uses the Swiss-Army-Knife top-left navigation to make global actions universally available. Some practical design patterns for addressing this tension between global and local are covered in Chapter 13.
Now that you’ve had an overview of the general design principles that make Android 4.0 different, it’s time to dig into how these principles are implemented in a variety of devices that support Android.