The Back Button Dilemma
ignorethecode.net
ignorethecode.net
If I go from a notification to the inner workings of an app, hitting back _should_ bring me right back to the view I was when I selected the notification. If that was the home screen, bring me back to the home screen. If I happened to be writing an e-mail and I got an @-reply on Twiiter with a notification, pressing back after reading the tweet should throw me right back to writing the e-mail.
I said it in yesterday's thread and I'll say it again here: the back button IS NOT an up button. Bad applications will attempt to "re-create" their internal stack of intents when you jump directly into a middle intent (like reading a Tweet or an e-mail), which breaks the back button's functionality. The author touched upon this in his post. A good analogy is Twitter's hash-bang urls breaking the back button in your browser. In this scenario Android's native Gmail app does it right: clicking back from a notification does NOT bring you to your inbox: it brings you right back into whatever you were doing.
Lazy app developers will try to shoe-horn "up" functionality into the back button. They're doing it wrong. What's the proper way to do this? The menu button and/or an on-screen UI element. If you're reading an e-mail and hit menu, there's a quick link to jump to your inbox. Other apps choose to use a button of sorts on the header or title area of their application. Android 3.0 and above have standardized this with the top Action Bar.
In short: there is no back button dilemma. There's a bad developer dilemma.
Design for the user, not for your ego.
The only time I see a reason to override the back button is in games. When playing a game you don't want the back button to accidentally bring you back to the main menu screen. Most override the button and either ignore it or bring up a pause menu. In non-game apps overriding it just causes problems.
I've also seen apps override it when they choose to have a lot of different functionality in a single activity. This is poor app design.
Not sure about Gmail. First of all, it doesn't behave the way you describe on my Nexus One. It always goes to the home screen when I switch to it, regardless of how I do it.
Second, is this really the best behavior? Or is the behavior you describe the best behavior? If you get a new message notification, and you tap on it, don't you usually want to see the new message?
And lastly, do you propose that applications should always implement "up" explicitly, or only when necessary? Because most of the time, they would just be duplicating functionality that already exists, thanks to the back button. But if you only show it when necessary, you're creating a situation where casual users won't really understand when and why they should use which UI element.
The problem here was that there are two ways to go "back" when reading an email. Press the back button, or clicking an on-screen UI element that took me back to the Inbox. One of them pops an item off the undo stack, and the other pushes one onto it. It's consistent, but frustratingly so.
I realize that I want to have my cake and eat it too, but at some point having an undo stack that is 30+ items deep doesn't really help me all that much.
I suppose it just goes to show that the meaning of Android's back button is way too overloaded (I think WP7 suffers from this across their other buttons as well).
Browser -> Email Message -> Inbox -> Email Message <<back>> Inbox -> Email Message <<back>> Inbox <<back>> First Email Message <<back>> Browser
You'd only be 3 back button presses to get to your browser session. Of course it's possible for users to create gigantic stacks of history where you wouldn't want to go all the way through them. If that's the case you can get back to your browser using the Multitasking UI or by going back to your home screen.
I think most users use the back button frequently however. If you do, you're always only a few presses to be back to your original activity.
Sometimes, you jump directly into an app, but then, you want to do other things inside that app; since the back button normally is used to move up inside an app, it's not always obvious how to do that (and it's sometimes not possible at all).
Android doesn't know what the correct "up" activity would even be. Unless they've changed that in 3.0, I have only used the 2.2 and 2.3 sdks.
As for "no satisfactory solution".. the first thing that comes to mind is having the notification take you to the inbox, but then open the message itself, thereby building the "stack" properly.
I don't want to get a text, reply to it and then have to relaunch my previous app. A tap of the back button and I'm back to doing whatever I was before I sent the text.
browser -> message
to
browser -> inbox -> message
Would suddenly mean that the browser gets killed. Is this really the case?
Not to mention that this simply wouldn't work in Android. If another application is launched via an Intent... and I press the back button and just return to a new level inside the launched application... I'm going to be peeved. Like, I'm removing the app irritated. I'm actually not sure a developer can even do that, thank god.
Why would you want to insert a new activity in the "back button history" that the user never visited? I was be distraught and am when applications screw with the Activity flow is messed with. The Google Voice app is notorious for stacking activities incorrectly to where it makes the back button useless.
That's why I prefer devs let Android handle it. The default behavior allows users to use their phones like iPhones (in terms of just going home -> app all the time) but also allows us to quickly switch into and back out of quick things like checking an email or replying to a text.
In the context of checking inboxes, adding an "inbox" activity does make sense, especially if you receive multiple notifications. Although I don't see why there couldn't be a way for the inbox activity to only be added when necessary.
* note: this is the Gmail app, I'm unfamiliar with the generic email app.