At the beginning of this year, Google launched the Android Design Principles Web Site. This site outlines how and why the Android 4.0 Ice Cream Sandwich User Interface (UI) is built the way it is. For those of us who work as User Experience Designers, it’s a treasure trove of information and insights into the minds of Matias Duarte and his team.
What I would like to do is break down a few elements of the Android 4.0 UI and talk about how they follow tried-and-tested user-centered design principles. Yeah, this might be a bit geeky even for us geeks, but trust me… it’s these kinds of solid building blocks that can make or break a platform. Read on after the break for my take on how Android is implementing and evolving their User Experience (UX).
The first principle is a classic UX law. Fitts’s Law states that the time to acquire a target is a function of the distance to and size of the target. That’s just a fancy way of saying that the bigger an object and the closer it is to us, the easier it is to move to it. In a touch UI, the size of the target is paramount. Since we are using our fingers to select, activate, slide, or click a target, that target needs to be relatively large since our fingertips are not exactly stylus-precise.
Android 4.0 adopts Fitts’s Law in its UI by ensuring targets are at least 7 mm in size. Taking into consideration a device’s resolution and pixel density, the Android UX team has determined that the recommended sizes for touchable objects should range from 7 to 10 mm. The Android Design web site talks about this.
On average, 48dp translate to a physical size of about 9mm (with some variability). This is comfortably in the range of recommended target sizes (7-10 mm) for touchscreen objects and users will be able to reliably and accurately target them with their fingers.
If you design your elements to be at least 48dp high and wide you can guarantee that:
- your targets will never be smaller than the minimum recommended target size of 7mm regardless of what screen they are displayed on.
- you strike a good compromise between overall information density on the one hand, and targetability of UI elements on the other.
Status Mechanisms – Providing User Feedback
Sometimes actions take time to complete. If the UI does not provide feedback to the user that it’s “thinking” during these slow times, then the user may feel like the system has crashed or is not performing the action the user is expecting. Also, simple feedback that a touch has been registered provides the user with immediate reassurance that the object they touched has actually been touched. Status mechanisms are vital to supplying the information necessary for users to respond appropriately to changing conditions.
Use color and illumination to respond to touches, reinforce the resulting behaviors of gestures, and indicate what actions are enabled and disabled.
Whenever a user touches an actionable area in your app, provide a visual response. This lets the user know which object was touched and that your app is “listening”.
Most user interfaces use icons. Icons are graphical representations, usually of applications or actions. To encapsulate an entire idea into an icon, that icon needs to look a certain way to get the idea across at a glance. Studies have shown that in many cases, there is a stereotypical, or “canonical”, view of everyday objects that is recognized faster by humans. A famous 1981 study known as “Canonical Perspective and the Perception of Objects” by Palmer, Rosch, and Chase, showed that most people perceive an object faster when seen from a perspective as if the user were slightly above the object looking down, and offset a little to the right or left.
This study has been debated, and there is still not 100% agreement with all its findings, but there is enough there to suggest that there should be a standard way to display icons that may help improve recognition speed. The Android UX team seems to agree since they provide icon guidelines that recommend a slightly top-angled perspective for their icons.
Use a distinct silhouette. Three-dimensional, front view, with a slight perspective as if viewed from above, so that users perceive some depth.
Visible Navigation – Back and Up
A good UI never leaves the user lost. Having a good sense of home and how to get to other places in an app is the key to usable navigation. Android Design provides many guidelines for how to manage Android’s Back button and in-app Up buttons that navigate screens within an app.
Consistent navigation is an essential component of the overall user experience. Few things frustrate users more than basic navigation that behaves in inconsistent and unexpected ways. Android 3.0 introduced significant changes to the global navigation behavior. Thoughtfully following the guidelines for Back and Up will make your app’s navigation predictable and reliable for your users.
Android 2.3 and earlier relied upon the system Back button for supporting navigation within an app. With the introduction of action bars in Android 3.0, a second navigation mechanism appeared: the Up button, consisting of the app icon and a left-point caret.
The Up button is used to navigate within an app based on the hierarchical relationships between screens. For instance, if screen A displays a list of items, and selecting an item leads to screen B (which presents that item in more detail), then screen B should offer an Up button that returns to screen A.
If a screen is the topmost one in an app (that is, the app’s home), it should not present an Up button.
The system Back button is used to navigate, in reverse chronological order, through the history of screens the user has recently worked with. It is generally based on the temporal relationships between screens, rather than the app’s hierarchy.
When the previously viewed screen is also the hierarchical parent of the current screen, pressing the Back button has the same result as pressing an Up button—this is a common occurrence. However, unlike the Up button, which ensures the user remains within your app, the Back button can return the user to the Home screen, or even to a different app.
Good navigation is paramount to a usable design. If a user can’t find his way around an app, it’s unusable regardless of how usable any of the screens within the app are.
Just the fact that Google has published the Android Design web site shows that they are conscious of the benefits of consistency across a user interface. These design guidelines are written so that app developers can follow best practices for designing their apps, which assures at least a baseline of usability.
Google has provided reusable building blocks for standard controls that helps developers be consistent with other apps on the platform. Some may argue that this goes against the open nature of Android since the more reusable building blocks that are used, the less unique an app becomes. This is a short-sighted point of view, in my opinion, since an app with non-standard controls requires users to do more work learning a new UI and could cause decreased usability.
Google has come a long way in improving Android’s user experience with each version. It is generally agreed upon that Apple is the king of UX, and that Android is far behind since it is “harder to use”. The fact is, Android has evolved into a highly usable platform with many features. Though iOS is certainly simpler on the surface, it achieves this through a combination of excellent UX around a much smaller set of functionality. In other words, it’s easier to use because it’s a simpler platform. That’s great for a very large number of users, as Apple’s market share shows. But for those wanting a little more without a huge sacrifice in usability, Android 4.0 Ice Cream Sandwich offers an intelligently maturing and usable platform based on the principles of User-Centered Design.