When designing a system framework that can be applied to a lot of different projects, there are certain elements of design that have to remain consistent. In terms of something like Android, an OS and platform for mobile phone technology, one important aspect to work with carefully is navigation.
When thinking about designing a positive user-experience, consistent navigation is a critical starting point to work from, because navigational tools set a sort of standard method for the user to interact with the device. Deviating too much from that basis will cause confusion at best, and resentment or abandonment of the device at worst.
Working with a user’s expectations for navigation, rather than against them, is a massively important step when undertaking any development project in Android. This article is an overview of several navigation topics relating to Android, and goes into detail about how they work, why they were designed that way, and how they can be used.
There are two very basic buttons that form a large portion of Android’s navigational features: the up button and the back button. The up button is a control that uses the hierarchical organization of a number of screens to navigate. Basically, if a screen leads to another screen, using the up button will return to the previous screen in terms of hierarchy.
For example, if an item in a list of search results is selected, it will display more information about that item on another screen. If the user selects the up button, they will return to the original list that they were on, since it’s one hierarchical step upwards. The back button is similar to the up button, but instead of returning the user to the next highest hierarchical screen, it returns them to last chronological one. In the above example about the search result list, pressing the back and up buttons would have the same result, because the chronology and hierarchy of screens match up. This is, however, not always the case.
Additionally, the back button can take the user out of an app and back to the home page, whereas the up button will always remain in the app, and stop at it’s highest UI menu. The back button also has the ability to dismiss floating windows like dialogs and pop-ups, dismiss contextual action bars, remove the highlight from selected objects, and hide the onscreen keyboard.
There are, in general, a few different ways that navigation is handled through Android devices. The first is navigation to screens with multiple entry points.
This is useful for a screen without a specifically outlined position in an app’s hierarchy that can be accessed by the user in a number of different ways, such as an options screen that can be brought up no matter where in the app the user is. The up and back buttons, in this case, would function the same.
The next type of navigation is changing view within a screen. This covers movement like switching views using tabs or swipes, creating a dropdown menu or accessing a collapsed tab, filtering or sorting a list to pare down search results, and altering the characteristics of a screen with a function like zooming.
These options don’t make use of, or change the behavior of the up or back buttons, because the screen is still in the same location within the app’s structure, and the user remains on the same screen while it happens.
The last type of movement is navigating between sibling screens. This is the kind of navigation that occurs when there is an option, when viewing a list, to go into detail on the items presented there. Often, there is a command to change directly from a detailed view on the current item, to one preceding or following it in the list.
For example, email services allow users to change from one email thread to the next in the list, and galleries of images have the same functionality. These pages are called sibling pages because they exist at the same level of hierarchy within the app and because users can navigate between them directly, rather than returning to the parent list first. Obviously, these kinds of navigational elements highlight the difference between the up and back buttons – the back button returns the user to the previous sibling page, while the up button returns the user to the list.
There are a couple shortcuts within app navigation that provide users ways of directly accessing something without first going through an app’s hierarchy. These are often attached directly to the home screen or are accessed through widgets, and they are presented in two different ways: indirect notifications and pop-up notifications.
Indirect notifications are indirect because they are bundled with other information. Often, they are the result of an app presenting information about multiple events, and they take place on a screen that the user is directed to by the original notification, but that the user must access to see. The screen then summarizes the information and allows the user to choose what to do with it by presenting paths toward the varying topics involved in the notification.
Pop-up notifications, as the name suggests, immediately present themselves to the user and bypass the typical notification drawer where indirect notifications are displayed. Because pop-ups are, by their nature intrusive, most designers refrain from using them except in cases where timely contextual action is required; such as a notification about very low battery on a device.
Navigating between apps
One of the greatest strengths of the Android framework is that apps can work with each other, which means that users can go directly from one to the other, so long as that connection is programmed into each app. There are three topics important to how apps interact with one another in this way. Activity refers to the defining actions that the user can perform with the app. An app, at its heart, is a collection of activities. A task, meanwhile, is a sequence of activities that build towards a goal or function of the app. Tasks, interestingly enough, can draw from the activities of multiple apps. Finally, an intent is a signal that passes from one app to another in order to alert the second app that the first needs it needs assistance to perform an activity. Then, based on the user’s settings and preferences for how apps interact with one another, the app completes the task by using the activities of both apps.