It is a good idea to have an overview of the user interface (UI) as it pertains to Android, so that’s the starting point here. You will learn a brief history of Android design to see how it evolved to Material Design before diving into some core design principles.
Android had a very technical start with a lot of amazing work going on to make it a platform that could run on a variety of devices without most apps having to care too much about the details. Unfortunately, all of that also meant that early design for Android was blasé and focused on the lowest common denominator, so embellishments like animations were sparse. Colors were bland and often inconsistent, and most input and visual organization was based on what had been done in the past rather than pushing things forward.
In 2010, Google hired Matias Duarte (most known for his excellent work with WebOS) as the Senior Director of Android User Experience, which made it clear that Google had become serious about the user experience for Android and its related visual design. The Android beta was released way back in 2007, so Matias and his colleagues had a lot of work in front of them.
About a year later, the first Android tablets running Honeycomb (Android 3.0) were revealed. These tablets gave Google the opportunity to really experiment with the UI because there was no prior version of Android that had been designed for tablets, and therefore users did not have strong expectations. With the radical new Holo theme, these tablets were a significant departure from the previous Android styles.
By the end of 2011, Google had revealed Android 4.0, Ice Cream Sandwich, which showed how they were able to improve the tablet-only Honeycomb styling to tone down some of the “techieness” and smooth out the user experience.
Android 4.1, Jelly Bean, was revealed at Google I/O in 2012. A release focused primarily on usability, Jelly Bean gave Android a much better sense of polish. “Project Butter” brought about a much more fluid user experience with graphics improvements such as triple buffering. Even components of Android that hadn’t been touched in years, such as notifications, were updated to improve the user experience. Android 4.2 came just a few months later, with support for multiple users, the “Daydream” feature (essentially, application-provided screensavers with the ability to be interactive), support for photo spheres (panoramas that can cover 360 degrees), and wireless mirroring. Android 4.3 followed with many more features, including OpenGL ES 3.0 support. Android 4.4 finished off the 4.x version with major system improvements, allowing Android to run on devices with as little as 512MB of RAM.
Then, Android undertook a radical change for version 5.0, Lollipop, with the introduction of Material Design.
Although Android 5.0 and Material Design are closely linked, Material Design isn’t just a design language for Android 5.0 and beyond. It is meant to be a set of design principles that apply across device types and arbitrary software versions. That means best practices from Material Design should be applied to older versions of Android and even web apps.
A material metaphor is the unifying theory of a rationalized space and a system of motion. The material is grounded in tactile reality, inspired by the study of paper and ink, yet technologically advanced and open to imagination and magic.
In the Material Design world, paper is the primary surface that everything else exists on. It can grow and shrink, unlike paper in the real world. That means a piece of paper can appear in the center of the screen by growing from a single pixel to its full size and it can even change shape. Paper always shows up with some kind of transition (growing or sliding into place); it is never just suddenly there at full size. Pieces of paper can push each other when their edges collide. Pieces of paper can be split into two, and multiple pieces can join to become one. A sheet of paper can never go through another, but one sheet of paper can slide over another.
The fact that paper can slide in front of other paper means that Material Design exists in a 3D environment. The third dimension, plotted on the Z-axis, is how close the object is to the surface of the screen, which affects the shadow it casts and whether it is in front of or behind another piece of paper.
Devices don’t (yet) have a third dimension to their screens, so this depth is created with the traditional techniques of perspective, obscuring (sometimes called occlusion), and shadow.
Shadows in Material Design are created by two light sources: a key light and an ambient light. If you imagine taking a quick photo of someone with your phone, the flash is the key light and all the other light is ambient. The key light is what creates the strong, directional shadows. The ambient light creates soft shadows in all directions.
One of the most important aspects of app design that is often ignored is interaction. What happens when the user touches this button? Sure, it shows a new screen, but what is the process to get there? Does the button grow or shrink or change color? Does the new content slide in or grow from the old content? Material Design puts much more emphasis on interaction and animation than previous design guidelines, which will help make your apps feel well polished.
Animations should be fluid and accelerate or decelerate where appropriate. Just like how a car doesn’t start out at its top speed when you press the accelerator, a piece of paper sliding off the screen in response to your touch shouldn’t start at its maximum speed. As small as the paper may be, it does have mass. The way an animation changes as it goes from 0% complete to 100% complete is called interpolation.
Another important note about animations is that their purpose is not to “wow” the user. It is not to distract the user or arbitrarily make things interesting. The purpose is to help the user understand the transition from what was on the screen to what will be on the screen.
When Android 4.0 was released, Google also unveiled Roboto. Roboto is a typeface designed specifically for today’s mobile devices, making it appear crisp on a variety of densities. For Android 5.0, Roboto has been updated to fix some of its more noticeable quirks, improving some characters (such as the capital “R”) and making the dots for punctuation and tittles (the dots above lowercase “i” and “j”) the more common circle rather than a harsh square.
Material Design emphasizes a 4dp (or four density-independent pixel) grid. That means every element on the screen is aligned based on a multiple of four. For instance, the left and right sides of the screen are typically indented 16dp on a phone, so thumbnails and text in a list all start 16dp from the left.
When images such as thumbnails or icons are shown to the left of a list item, the Material Guidelines say that the text that follows is indented a total of 72dp from the left edge of the screen.
That was quite a bit about Material Design, but there is a lot more to it. Throughout this book, you will be learning more about Material Design, what factors into certain decisions, and how to actually implement it all, but it is also a good idea to look at the Android design website (http://developer.android.com/design/). That site will give very specific details about how Material Design applies to specific Android components.
You should also look at the Material Design spec from Google (http://www.google.com/design/spec/material-design/), which has a lot of great video clips for demonstrating things that are hard to understand with just words, such as interaction animations.
You don’t need to have the content of either of those sites memorized before you start designing your own app or implementing a design someone else has created, but you should look through them to have an idea of what is there and be ready to come back to them any time you have a question.
It is impossible to come up with a perfect checklist that lets you know that your app is exactly right when everything is checked, but guiding principles can make a big difference. Start with your users’ goals to define exactly what your app should do.
If you ever want to build a mediocre app, a sure way to do so is by trying to make it do everything. The more narrowly focused your app is, the easier it is to make sure that it does what it is supposed to and that it does so well.
When you’re starting on a new app, list everything you want it to do. Next, start crossing off the least important things in that list until you have narrowed it down to just the absolute essentials.
You are probably ready when you can answer the question, “Why would someone use this app?” without including conjunctions (such as “and” and “or”) and without using a second sentence. Here are two examples:
Good: “Users will use this app to write quick notes to themselves.”
Bad: “Users will use this app to write notes to themselves, browse past notes, and share notes with other users on Twitter.”
There are times when your app does have multiple purposes because these features are too intertwined to separate or the requirements are outside of your control. In those cases, you should split the functionality in a clear and meaningful way for the user.
For instance, consider the Gallery in Android. It allows users to look at their photos and manipulate them in simple ways. It doesn’t allow users to draw images or manage the file system, so it has a clear and obvious focus.
Just because your app does only one thing extremely well doesn’t mean it needs to limit the user’s experience. One of the best parts about Android is that apps are really just components in the overall user experience. Your app should handle reasonable
Intents, which is the class Android uses to indicate what the user is trying to do and to find an appropriate app to accomplish that objective. Is it an app for a particular site? Have it handle links for that site. Does it let the user modify images? Handle any
Intent for working with an image.
The time you spend implementing sharing for third-party services in your own app is time that could be spent making your app better. Why would you spend a week developing some tolerable sharing tools when you can pass that work off to the user’s favorite apps?
One of the major challenges of mobile applications is that you often have a lot of information to convey, but you have very little screen real estate to do so. Even worse, the user is frequently only taking a quick look at the app. That means it needs to be easy to scan for the exact information desired. Use short text for headers, directions, and dialogs. Make sure that buttons state a real action, such as “Save File” instead of “Okay,” so that a button’s function is immediately obvious.
Use images to convey meaning quickly. Use consistent visuals to anchor the user. Always include all applicable touch states. At a minimum, anything the user can interact with should have a normal state, a pressed state, and a focused state. The pressed state is shown when the user is actively touching the view, so excluding it means the user is unsure what views can be interacted with and whether the app is even responding. The focused state is shown when a view is selected by means of the directional pad or other method so that the user knows what view will be pressed.
People are judgmental. People using an app for the first time are hyperjudgmental, and that means it is critical that your app be easy to use. The primary functions should be clear and obvious.
If your app provides photo filters, do not just say “stretch contrast” or “remove red channel.” Instead, show a preview thumbnail so the user can see and understand the effect of the button.
One last thing to remember about making your app easy but powerful is that the user is always right, even when making a mistake. When the user presses a “delete” button, in 99% of cases, the user meant to press that button. Don’t ask the user “Did you really mean to do that thing you just did?” Assume the user meant to, but make it easy to undo the action.
When in doubt, follow the user experience expectations of the platform. Even when you’re not in doubt, you should follow the user experience expectations of the platform. In other words, unless you have an extremely good reason, you should not do things differently from how they are done in the built-in apps.
Other platforms can require navigational buttons such as a back button or an exit button; these do not belong in an Android app. The actual Android back button should have an obvious and intuitive function in your app, and adding another element to the UI that does the same thing creates user confusion. There is no need to exit your app, because the user can either back out of it or simply press the home button.
Using styling from another platform not only looks out of place, but it is also awkward for the user. For example, Android has a specific sharing icon that looks quite distinct from other platforms such as iOS and Windows Phone. Users are likely to be confused if an icon from another platform is used. Take advantage of what the user has already learned from other apps on Android by being consistent with the platform.
One of the great things about Android is that users have a lot of choice right from the beginning. A construction worker might choose a rigid device with a physical keyboard over a more powerful thin device. Someone with larger hands has the option to pick a device with a 6-inch screen over a much smaller screen. Android makes it extremely easy to support these different scenarios. Just because it can be difficult to support landscape and portrait on other platforms does not mean that the support should be dropped for Android as well.
Bending to the user does not just mean adjusting your app to give the best experience on a given device; it also means picking up on user habits.
Android has two system bars: the status bar and the navigation bar.
The status bar is at the top of the screen and displays icons for notifications on the left and standard phone status info on the right, such as battery and signal levels.
The navigation bar is at the bottom of the screen and consists of back, home, and overview software buttons when hardware buttons are not present.
Apps that were built against older versions of Android will also cause a menu button to appear in the navigation bar.
For the most part, these do not need to be considered much during design. You can hide the status bar, but you almost never should. It’s acceptable to hide the system bars during video playback and it’s fine to hide the status bar when it might interfere with the user experience.
Notifications are a great feature that many apps do not take advantage of. If your app does something in the background, such as syncing a playlist, it should show a notification while that is happening. If your app has important information the user should be aware of, such as a stock alert that the user has set, it should be displayed as a notification.
Android 4.1 brought about richer notifications that allow notifications to have actions as well as larger displays. Notification design is improved for Android 5.0 by changing to a dark on light theme with support for accent colors and much more.
The app bar is the toolbar that sits at the very top of the app, just below the status bar. Previously called the action bar, this toolbar is now able to be implemented just like any other view.
The app icon is typically no longer included in the bar, but navigation still goes on the left (such as “up” navigation, which allows the user to navigate “up” one level in the hierarchy, or the hamburger menu icon, which indicates a sliding drawer) and contextual actions still go on the right.
Just like before, infrequently accessed actions and actions that don’t fit on the app bar go into an overflow menu that is represented by three vertical dots. Although you can include a logo, it’s generally not desirable.
The app bar makes sense for most apps, but you can hide it as needed (such as for an app focused on reading or watching videos). A common behavior in Material Design is for the app bar to slide away as the user is interacting with the content (such as when scrolling down the page) but come back when the user might need it (such as when scrolling back up).
Tabs have been a common form of navigation since well before PCs, and they continue to be effective. In Android, tabs always go at the top. If there is an app bar, the tabs are the bottom portion of that bar. As opposed to most other navigation methods, tabs are easily understood and increase the visibility of different sections of your app.
When in a fixed position, having two or three tabs is ideal. If you have more tabs, you can make them scrollable, but you should consider another means of navigation, such as a navigation drawer.
The “FAB” is a fairly iconic piece of Material Design. It is the circular floating action button that is shown in an accent color when there is a primary action for a given page. This allows the important action to draw more attention and also be in a position that might make more sense (from a layout perspective or from a thumb-reach perspective).
Although already briefly touched on in the “Bend to the User” section, the importance of supporting multiple devices cannot be overstated. If you’re not doing anything with the NDK (and if you don’t know what that is, you’re not using it, so wipe that sweat off your forehead), it’s typically very easy to support a range of devices wider than you even know to exist.
Following the guidelines for Material Design will make your app great, but there are a few painful mistakes that many designers and developers still make. Two of these come from old Android standards that are outdated: the menu key and the context menu. In addition, there are two other common mistakes that will call negative attention to your design: incorrect notification icons and styles from other platforms.
Before Android 3.x, devices were expected to have a menu key. Unfortunately, this actually led to several problems. For one, the user had no way of knowing if the menu key did anything in a given app. He or she had to press it to see what happened. Because it often did nothing, users would forget to even try pressing it for apps that did make use of it, leading to confusion on how to access certain features.
The menu key was also meant to be contextual to the current screen contents (it was essentially the precursor to the app bar and the overflow menu), but many developers and designers used the menu key in inconsistent ways, even abusing it as a full navigational menu.
Fortunately, all you have to know now is that you should not use the menu key. Your apps should target the newest version of Android so that a software “menu button of shame” does not appear.
The long press gesture (sometimes called long touch or long click) was used to bring up a context menu, similar to right-clicking on a desktop application. This use of the long press has gone away and should instead be replaced with selection. Long pressing on a given item should select it and then enable a contextual action bar.
Selecting one or more items might give you the options to delete, archive, or flag them. If your app does not have the ability to select items, then long press should not do anything. Android 5.0’s ripple will slowly expand out without selecting the item, which lets the user know “your touch is recognized but it is treated as a regular touch because there is no long press action on this item.”
Notification icons have very specific guidelines, and it is particularly important to follow these guidelines because notifications show up in the status bar across apps. Notification icons should have pixels that are fully white or fully transparent.
Although already mentioned in the “Platform Consistency” section, it is worth repeating that you should not use styles from other platforms. One of the most common mistakes in the design of Android apps is to take the design from an iOS app and “port” it over to Android.
Now that you have finished this chapter, you should have a good idea about what a modern Android app looks like. You now know the standard components (such as the app bar) and the outdated ones that should be avoided (such as the menu button). You understand some high-level goals from the “Core Principles” section that you can apply to future apps, and you may find it useful to come back to this chapter later on once your app has started being designed.
(To Be Continued)