There’s been a mini-flurry of debate on the Android Back button, with Christoffer Du Rietz arguing that it’s harmful and broken, and a small chorus of the usual Android-hater suspects chiming in. Steven Van Bael pushes back. There are interesting subtleties here.
Provenance · Here’s a really easy question: Where does the notion of a Back button come from? I have argued, and I’m really not joking, that the Web browser’s Back button is one of the greatest user-interface innovations of my lifetime. First, it’s useful. Second, the knowledge that wherever you are, if you’re lost or confused or change your mind you can back out, has been immensely successful in defusing angst among nontechnical users and encouraging them to check things out that otherwise they might not.
So I’d ask those who want to amputate Android’s back button to consider doing the same thing to their browser. No takers, right?
What Does “Back” Mean? · To the extent that there’s any room for criticism, it’s that sometimes it feels like you need two back buttons. Christoffer’s example is clicking something that takes you to a tweet in your Twitter client. Maybe, when you go back, you want to go to your Twitter timeline, not back to the browser or wherever it was that sent you to Twitter.
Ooh! Confusion! Breakage!
This line of argument is simply wrong. First, consider the alternate case, which happens 100 times as often: when I click on something in Twitter and go to the browser or YouTube or whatever, then want to go back to Twitter. The Back button solves the most common use-case elegantly and minimally.
Which is to say that on the vast majority of occasions, the average person knows more or less how they got to where they are and where pushing Back will take them, and this is a good thing.
But in fact, I think, I think that in Christoffer’s case, what he really wants is two separate buttons for Back and for “Up”. Take me back where I was, or Up to the top of the current resource.
The Up Button · The same situation arises when you click on a “mailto” link and get popped into your email. When you leave there, do you want to back to where the link was, or up to your inbox?
What you’d like is what we have on the Web, where in just about any site, you can expect that clicking on the big fat logo in the top left will get you to that site’s top level.
Google is actually pretty good at learning from the Web. So, If you use Honeycomb, the most recent Android release that’s actually in the field, you’ll discover that more or less every app has an “Action Bar” across the top, and at its left is an app icon that works as an Up button. Which is to say, you get both options.
Judgment Calls · There are in fact cases where it might make sense for an app to intercept the Back button and use it for Up. Twidroyd, a Twitter client now known as Ubersocial, used to do that: If an app bounced you into a tweet, hitting Back once took you to your timeline, and then hitting it again took you to where you came from.
I notice that DropBox does this too: If you’re sharing something to DropBox, it remembers which folder you last shared to and takes you there (usually right); if you hit Back it climbs up through the DropBox folder hierarchy, and from the root back to where you came from, aborting the share. And if you hit Share, it pops you back to wherever you shared from.
I hated the Ubersocial choice, but find DropBox’s comfortable. Which is to say, there is room for judgment as to what to do with the Back button; developers have to, you know, think, about how to achieve the principle of least surprise. (Hint: The system’s default action is almost always right.) But that doesn’t mean it’s a bad idea.
Keep The Button · I think if you polled a large number of regular Android users on whether they like the button, you’d be hard-pressed to find a single one who wanted to lose it; most would say it’s one of the better features.
The people on the other side are saying more about their own agendas than about the subject at hand. I’m reminded of those who argued for years that no, you really shouldn’t want to have more than one button on a mouse.
Yes, Make Them Soft · More and more current phone and tablet designs omit hard buttons entirely. And this seems to be a win if only because you can make sure the buttons are in the same place however you currently happen to be holding the phone. So I agree with Christoffer that soft is better than hard.
He’s also right that it’s sometimes OK to leave out the Menu button, which turns out to be superfluous in lots of apps.
But soft or hard, the presence of the Back button is a win; one of the single biggest wins you can offer your users. It reduces friction, makes apps play better together, and improves people’s day-to-day interaction with their devices and with the world.
Contributions
Comment feed for ongoing:
From: Cedric (Nov 03 2011, at 15:55)
I don't think there is much controversy about the usefulness of "Back", but you're not the only one confusing the issues (Gruber makes the same mistake).
The real discussion is about labeled back buttons. iOS has them (you can always see where you are going back) and Android doesn't (not easy to do with hardware buttons).
I would argue that while labeled back buttons seem to be a great improvement, they are actually only a minor one, because if an application needs to explain to you where "Back" is taking you, then its flow is broken in the first place. It seems to me that the label is largely unnecessary on most of the Android, iOS and web applications that I have used.
This takes care of the label issue.
As for the "hardware" vs/ "software" button debate, I think the jury is still out. They both seem to work great (soft on iOS and hard on Android) and they are both subject to failures: iOS' software buttons is mostly consistently in the upper left side of the screen except when it's not (e.g. in Safari) while Android's hardware buttons usefulness greatly depends on their hardware design and location.
[link]
From: Ken (Nov 03 2011, at 16:58)
As an Android user since the Nexus One, I have to say that the back button remains my most hated feature. It's something that sounds great in principle, but the analogy to the web browser breaks down for me in two ways.
First, a web browser supports multitasking in a visual way (i.e. with tabs and windows), but a phone/tablet only has one primary task. Thus, if I multitask on a phone, my Android activity is now interleaved with multiple actual activities that I'm performing.
Second, the back button in Android is unpredictable. As you note, many developers choose to override its behavior. In order to demonstrate my gripes with Android, I used to show people the GMail app. It's much improved now, but it used to be the cause that hitting the back button would rarely go to the previous screen. There are other critical applications like Messaging, which have no on-screen 'Up' navigation. I have found that the quickest way to get to the top-level menu in Messaging is to:
1. Open Messaging
2. Hit back (returns to Android Home)
3. Open Messaging. It's now on the Messaging Home.
The above sequence is still reproducible on my Gingerbread phone.
[link]
From: Rich Ehmer (Nov 03 2011, at 17:24)
Web page analogy aside, users now expect the 'Back' button to escape contextual actions. Press 'Back' to hide the soft keyboard, close a drawer, or generally exit a mode of 'edit' or 'inspect.' Twitter breaks the mental model when their notification sends users to 'inspect' mode without giving them a familiar way out.
[link]
From: Steve Holden (Nov 03 2011, at 17:39)
I've argued in the past that the "back" button is a dreadful idea in web browsers. The problem being that it doesn't result in the reloading of a RESTful resource, which means that the displayed doesn't necessarily accurately represent the current state of the server. Once client and server lose sync in that way only trouble can ensue.
So if you want a browser "back" button, please allow servers to indicate whether it can simply re-display the previous content or whether it has to re-apply to the server for the updated content. It's all very well to design web systems as though they only had one client, but in fact each page impression is time-specific in some systems. On those systems the "back" button is more likely to do harm than good.
"Up" is all very well if you view webs are hierarchical resources. Sometimes they are, sometimes they aren't.
[link]
From: Nick Adams (Nov 03 2011, at 18:06)
No exaggeration, the back button has played the largest single role in keeping me away from the iPhone (had a 3G briefly). I'm lost on an iPhone because of its omission of the back button.
[link]
From: John Cowan (Nov 03 2011, at 18:38)
Google browser apps are notorious for malfunctioning if the user hits Back, or tries to have two logins open in two tabs, or otherwise breaks the model of "forward, ever forward".
[link]
From: Peter Phillips (Nov 03 2011, at 23:12)
An "Up" button sounds like a reasonable idea, but I'd much rather add a "forward" button.
A back button without forward is just another name for "ESC" and is equally not useful for navigation.
[link]
From: Mike (Nov 04 2011, at 03:34)
The mouse button is a little different. The average computer user is a moving target, so how you design a mouse needs to take into account the degree of computer sophistication by the average user at the time the mouse is being designed. It was much lower in the 1980s than it is now. You can have a more complex mouse now, and most people can use it with no problem. Such people always existed, but they are the majority now. People who get confused by more than one button still exist, but they have shrunk into a small minority now.
[link]
From: Gavin B. (Nov 04 2011, at 05:09)
Microsoft Windows (ugh) abandoned the distinguishing between Back & Up on the desktop - when Vista came along.
For the record: to
"Make Backspace in Windows 7 or Vista Explorer Go Up like XP Did" see here:
http://www.howtogeek.com/howto/8955/make-backspace-in-windows-7-or-vista-explorer-go-up-like-xp-did/
[link]
From: John Gill (Nov 04 2011, at 06:04)
I use the back button all the time. It takes me where I'd expect often enough to be useful, but when it gets it wrong it is tedious + the lack of a forward button adds to that tedium.
How about if holding the back button popped up a menu, so you get some choices about how far back to go?
Better still, include some forward stuff in that menu.
So, if you hit back and it doesn't do what you expected, just press and hold and you can then select what you want from the menu -- including back where you came from.
[link]
From: Edwin Stearns (Nov 04 2011, at 07:09)
I use the back button all the time, but I hate when it doesn't do what I expect. The fact that individual apps can decide what the back button does seems to be part of the problem. One of the differences between Android and IPhone is that Apple makes more decisions on how apps should operate and Android leaves much more freedom to the app developers. In this case, Google should have a standard operation that is highly recommended to the app developers so that there is more consistency for the user.
[link]