July 15, 2011

The Back Button Dilemma

Yesterday, I wrote about issues with the iPhone's home button. Today, in order to balance things out,1 I'm going to write about a problem with a hardware button on a competing platform: Android's back button.

Here's how the back button works. Let's say you open an email app on Android. Next, you open a message inside the app. Hitting "back" once will bring you back to the list, hitting it again will bring you back home.

This seems pretty straightforward. What might not be obvious is that the back button is actually doing double-duty. It's doing two different things that just happen to be the same thing, in this particular instance. The back button is both moving you back through history, and it's moving you "up" the application's hierarchy.

Why is this relevant?

Well, imagine that you're jumping directly into the mail application's message view. For example, there's a notification telling you that you've received a new email message.2 You hit the notification, and you see the email.3 Now, suddenly, going back and moving up the application's hierarchy are two entirely different things!

Here's the dilemma: should hitting "back" move you up the app's hierarchy, or should it bring you back to the screen you came from?

If it brings you back (which is the better option), how do you move up the app's hierarchy? Do you add an additional "up" button? If you do, do you only show it when necessary, or at all times? If you show it at all times, you're duplicating functionality. If you don't, you're creating a situation where the UI of your application changes based on rules that may not be obvious to most of your users.

One solution to this problem is to simply go to the application's first screen when the user hits a notification, or switches to it via the task switcher (in fact, that's what the Gmail app on Android currently does).

This solves the problem, because now "back" and "up" are the same again, but it does mean that the user will have to do more work to actually open the new message.

As far as I can tell, there is no satisfactory solution to this problem.

Further Reading

Jon Bell talks about problems with the back button. Aza Raskin mentions some issues in his essay on the home button.

Update

I don't have a Honeycomb tablet right now, but over on Twitter, Mark Murphy explains:

[In Honeycomb, the] BACK button is in system bar @ bottom. Apps can make the left icon in action bar signify "up", with arrowhead indicator

So essentially, developers can (optionally) have two different UI elements for "back" and "up", both of which do the same thing most of the time, except that "up" presumably adds screens to the "back" stack, while "back" removes them.

  1. Apparently, some people think that I'm actually honestly trying to balance things out by complaining about Android. I'm not. I was just trying to make a joke. In fact, I had started writing this essay before I wrote the back button essay, as can be gleaned from the article's ID in the short link. ↩︎

  2. Or a new text message, or a calendar reminder, or you're just using the task switcher to jump to an application that's already open. ↩︎

  3. Note that while I'm using screenshots of Gmail, based on my limited experience with a recent version of Android, this is not how Gmail on Android currently behaves. I've seen Android apps that behave like this, though. ↩︎

If you require a short url to link to this article, please use http://ignco.de/344

designed for use cover

But wait, there's more!

Want to read more like this? Buy my book's second edition! Designed for Use: Create Usable Interfaces for Applications and the Web is now available DRM-free directly from The Pragmatic Programmers. Or you can get it on Amazon, where it's also available in Chinese and Japanese.