Design for Android 4.X: A Case Study
Part 2: Action Bars
Excerpt from Android Design Patterns: Interaction Design Solutions for Developers (Wiley 2013).
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. In the second installment, I show you how to redesign the app for Android 4.0+.
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 2.1). That location is arguably the second-most important and prominent spot in the mobile UI (the most prominent spot is on the screen is top left, occupied by a large logo).
Figure 2.1: Antipattern: The AutoTrader app emphasizes the useless Settings function in the home screen design.
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 2.2).
Figure 2.2: Antipattern: The AutoTrader app places essential functions in the old-style navigation bar menu.
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.
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 2.3.
Figure 2.3: 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.)
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 information architecture: Key functions such as Find Dealers and My AutoTrader are still hidden, and the Settings clearly does not go anywhere useful. Worse, placing Settings 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 2.4 shows how this might look.
Figure 2.4: 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 recommendations for the Ice Cream Sandwich (4.0) and Jellybean (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 recommended 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 needs while also adding visual noise and complexity. This is not a small consideration 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 2.4, I used both of the original Find Dealers and My AutoTrader icons. While neither icon is bad either one can be easily misinterpreted, 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 the author—at the heart of what mobile navigation is all about. The author has 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 2.5). The Drawer and other “Swiss-Army-Knife Navigation” Pattern techniques are lengthy topics I will cover in later articles. Here it will suffice it to say that the drawer user interface (UI) element enables both icons and text—the best of both worlds.
Figure 2.5: The Google Plus app design uses a Drawer menu that includes both text and icons.
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 AutoTrader. 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 2.6) 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 hiding it is the best strategy.
Figure 2.6: 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 flow inside the Car Search view, they may be one or more steps away from accessing 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 customers are on, which is recommended by the Android design standards document.
P.S. Got here from Twitter or Google Plus? This page is Part 2 of 7 of the free Android Design mini-course. Join 3,000 subscribers who got this entire series – enter your email below:
Copyright 2004-2012 DesignCaffeine, Inc. Contact Greg.Nudelman [at] designcaffeine.com