Not every mobile operating system is built equal. It’s not just their look or the size of their app stores. Let’s take a look at something you might not think is different: the ‘back’ button. It’s one of the most fundamental interface components for mobile devices, where space is limited.
iOS has a per-app back button in the top left corner, along with a left-to-right swipe gesture. If you open a Web page from an email message, you can only get back to the email message and its app by opening the app switcher.
Windows uses a system-wide back button that handles navigation inside an app and between apps. So, if you open a Web page in an email message, you can just press the single back button to close the page and go back to the message. Pressing and holding the back button opens up the list of apps in the order of interaction. It also allows a user to cancel an operation: a dialog can be dismissed by pressing the system’s back button instead of adding another button—cancel—in the mix.
Android has a strange combination of the two. It has two mechanisms for traversing both interaction paths. The primary path is the trail of interaction: you open one app, navigate through it, open a link in a browser, and the trail includes all of those. That means when you press the system’s back button, it goes back to the previous item in the user’s action history: a previous Web page, the email message you opened a link from, etc.
Android’s secondary path, used much less often, is the app’s own navigation layout, which is traversed using an arrow in the top left corner. This path is independent of a user’s actions, and will neither leave the current app nor traverse the interaction path. A usage example would be if one app opens another app to a specific item. Pressing the system’s back button at this point will go back to the previous app. If a user wants to stay in the app but go to a parent view, like a list containing that item, they would use the top-left back button within the app.