

The Back Button Dilemma - rkwz
http://ignorethecode.net/blog/2011/07/15/the_back_button_dilemma/

======
Pewpewarrows
No. Just... no.

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.

~~~
pavpanchekha
To add to what you're saying: bad developers are often under the impression
that their app is the universe within which user activity happens. This is
somewhat understandable, since their app is all _that developer_ think about.
But it's important to remember that while adding a button go _up_ might be the
optimal thing to do _within your app_ , it is unlikely to be the optimal thing
to do overall.

Design for the user, not for your ego.

~~~
MatthewPhillips
I'm not sure it's even the correct action to do within your app. Most of the
time there is going to be more than one way to launch an activity even within
an app. So going _up_ can ruin the user experience even within your app.

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.

------
zyb09
I think this is only a problem for people not familiar with Android. Once you
get used to it, it's pretty straightforward and intuitive. Fact is, the back
button always takes you back to the previous screen you where on, and it works
systemwide. So when you opened an email from a notification, you get taken
back from wherever you opened that notification. Yes, apps can mess with that
behavior, but only bad apps do and those don't get used anyway. iOS navigation
stacks work very differently, so this might be confusing for people coming
from iOS.

~~~
LukasMathis
It's not that the behavior is unclear, it's that going back is not always what
you want to happen.

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).

~~~
MatthewPhillips
It actually doesn't move up. It always moves back, just like the back button
on the browser. If you want to move "up" that is handled by the developer's UI
preferences.

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.

~~~
LukasMathis
"Back" is normally used to move "up" because most of the time, "back" and "up"
are the same thing.

~~~
MatthewPhillips
Possibly true, but users don't expect the back button to move up, they expect
it to move back. In the web browser if you click on a link from HN and then
hit back you don't expect the browser to direct you to the parent domain, you
expect it to return to HN.

~~~
LukasMathis
The web browser is a different case than something like the Gmail app, or the
Kindle app.

------
kaolbrec
This gets to be particularly annoying if you, for instance, check multiple
folders. Of course you can just hold back to quit the app, but that would be
an obvious solution, and put designers like this guy out of a job.

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.

~~~
drivebyacct2
But no one wants that flow. If I wanted that flow, I'd buy an iPhone so that I
have to completely stop what I'm doing and switch tasks (not that I dare say
anything bad about iOS multitasking).

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.

~~~
kaolbrec
I wasn't aware that going from say,

browser -> message

to

browser -> inbox -> message

Would suddenly mean that the browser gets killed. Is this really the case?

~~~
drivebyacct2
No, but I see no reason that that makes any more sense, the user experience is
that they navigate to their browser, surf, drop directly into a message and
then go back. Especially since I think you're still thinking about things from
an old mindset where users use the homescreen to switch apps. That's fine, but
for those of us that want to leverage Android multitasking (and presumably iOS
multitasking allows you to jump back into an application via the multitasking
pane), it's nice that we have a "history" so to say of our "session".

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.

~~~
kaolbrec
I can assure you I am not thinking of using the homescreen in that way, since
I never experienced android when it worked that way.

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.

~~~
MatthewPhillips
If you receive multiple email notifications it does take you to the inbox. If
you only have 1 you go directly to that message.

* note: this is the Gmail app, I'm unfamiliar with the generic email app.

------
veeti
I think that the Action Bar in 3.0 (and 4.0) is supposed to solve this
problem. It's basically on top of every screen, and clicking the app's icon on
the action bar is supposed to take the user back "one level up" in the screen
hierarchy.

------
KevinMS
Coincidentally, I just finished a rails plugin that does something like this
with rails and posted it a few days ago. In this case "back" is determined by
a graph of your web app you feed to the plugin. Never managed to get any
feedback on it though. However a similar concept has been running on a
production site of mine for years with fairly good success; I just finished
turning it into a plugin last weekend

<http://kswope.com/2011/07/10/backstack-rails-plugin/>

