This was a huge frustration for me on 2.x. I'm glad they're suggesting that people insert fake activities to fix it.

Here's an example -- from the homescreen, click a Music widget. The Music app opens and shows the song I was listening to. I want to go back to the playlist I was playing from so I hit back. Instead, I'm dumped back to my home screen. you have to hit the Google Music icon in the top-left to go back within the Music app. I don't mind having to hit back a couple of times because I've learned that you can just keep hitting back and you'll eventually get where you were.

I disagree. I think the confusion is caused by users not intuitively understanding the context of the android "back". In a web browser, if you click a link to a sub-page on a different domain, you don't expect the back button to take you to the home page of that domain, you expect to go to the previous site you were browsing. Do any android devices have something akin to the right click on the back button in web browsers, that shows the back stack?

This consistently confuses me too (and I much prefer it when application insert artificial pages).

I've thought about it some, and I think the problem is that the back button lacks the concept of context.

In the music app example, when I first use it I get the front screen, then choose a song.

Then I press the home button, put my phone away and at some point the song stops.

Now, some hours later I open up the music player from the home screen and it is still showing the song, what behaviour should the back button have?

I think it should take me back to the song list (because I am now in the "Music" context in my head - and this is what it now does). But one could argue that the back button should take me back to the home screen.

The biggest problem for me is the uncertainty and inconsistency. Do you always remember the previous screen you were on in any app hours ago? What if you got to the song from some other screen? I would constantly have to "guess", what is this app going to do, take me back to where I previously was or to a higher level in the app. It needs to be consistant, back is back and navigating within the app needs to be obvious and on the UI itself.

The back button in browsers is often used as analogy, but how many tabs/windows do you have open in your browser? What if pressing the back button in the browser switched you to a word processor because that is what you were looking at before.

That's what alt+tab and ctrl+tab are for. The confusion comes from the use of only one back button instead of one per hierarchy.

On android we have only one system-wide consistent timeline to work with, and that's the timeline of fired intents. It works across the whole system. Back works on that level by default and is defined by default as "go back in time".

> I disagree. I think the confusion is caused by users not intuitively understanding the context of the android "back"

That's exactly the problem. The user should intuitively understand an action. Since they don't, that means it's Google's fault for implementing it poorly.

I've only used an Android phone once for 5 min (my Mom got one for Christmas), but that was enough to run into Back button confusion.

My assumption was that it would take me up the stack, since when I entered the Mail program and navigated down, Back took me back up. But when I entered from some other place (like the settings app) then back wouldn't take me up to inboxes.

I'm sure it would have made more sense if I realized it was a system-wide Back and not an app-only Back.

There has to be some kind of middle ground here, some kind of way to do it that gives you quick access for transitory things, like email and text messages, but also lets you get back up the stack. Maybe if artificialy adding things to the stack was disabled when you're coming from notifications, but not otherwise?

You would be able to tell if the user had previously used the app, gotten to a state, switched out, then went back to the app to find that state or if the application was pushed to a certain state when it was opened.

Personally though, I would prefer the back button system-wide only. You can easily provide a UI element to take you to the top of the stack (especially since when an app is forced into a state, you only want to get to the top of the stack). Sometimes I even get confused when the back button takes me back a webpage in the browser.

Seems reasonable to me to use the (generally) hardware back button as a 'system' back button and the ActionBar back button as the in-app back button.

Why? The "multitasking button" should be enough for that. Press it, and you can switch to your app.

The problem is that the "Back" button has replaced onscreen upward navigation in Android apps. This means that the back button cannot function strictly as a means of returning to your previous activity if upward navigation is going to be possible. The options are for apps to build upward navigation into their UI (how its done on the web) or for apps to push their entire navigation tree onto the stack, regardless of how you get to a given location. Google seems to be opting for the latter option.

But they're not... The Google Music, Reader, Market and others that I can't think of use the top left icon and a left handed arrow to take you back in the apps activity and that works regardless of the actual Activity stack (And the back button works as a stack navigator).

This inconsistency and change in Google apps' behaviors is frustrating and is the only thing that I think they failed at in their attempts to fix the "consistency" problems of Android UI/UX.

I'm with the grandparent, I'd like to see this clarified. Some picture-based examples might help explain this issue better to those unfamiliar with Activity management.

WRONG! :-)

The way you suggest is why Android's back is confusing. If I hand you my phone and put you on a particular screen and ask you "if you press back right now where will you end up" you have no idea

Even if it's your own phone if it's been a few minutes, hours since you last used an app you'll have no idea.

Here’s what I hope is an objective fact about the Android back button. IT’S NOT PREDICTABLE!

The way it works is that each app has a “stack” of screens. Pressing the back button pops the current screen off that stack revealing the screen below. If there are none you are taken to the home screen. The problem is let’s say you start the Messaging app. The first screen is “list” of conversations screen. You pick a conversation and now you are on the “conversation” screen. From the conversation screen you press “back” and you get the “list” screen. Press back again you get the “home” screen.

Now let’s take another senario. You are in the browser. You get a notification that you have a new message. You select the notification for the message. You are taken to the “conversation” screen. You press home and do something else, say listen to music. Later you decide you want to send a message to someone. You go the home screen and pick the messaging app. Since the app is still running you see the “conversation” screen. You press back you get the “home” screen. WTF!

In the first case it went “conversation”->”list” in the second case it went “conversation”->”home”

Notice in this case, even if you had an amazing memory and could remember that you happened to launch the messaging app from a notification an hour ago or last night or something you still have no direct way to get to the “list” screen. The only way there is to select the messaging app either from the home screen or the recently used list. You’ll get the “conversation” screen. You press “back” and you’ll exit the messaging app back to the “home” screen. Now you have to navigate the home screen to the screen that has the messaging app icon on it so you can re-launch the messaging app and have it start in on the “list” screen.

Android should never have had a back button in the first place. If there was no back button there'd be no way to make it inconsistent. Switching back to another app would be come the simple habit of holding home for a moment and picking the app you want to go back to and you'd always be able to predict where any button will take you.

I applaud them for trying to fix it but putting in the guidelines, which may or may not be read by the majority of devs, seems unlikely to fix the problem.

Google Voice follows (or used to, at least) your advice, which led to endless frustration. You'd tap a notification to read a text, then have no way at all to get to the main screen of the Google Voice app. In Android 4.0, Google Voice has an app-specific back button that helps, but I think Google's advice on this is correct.

I'd think that the "typical" behavior would be to go back to what you were doing. I'm playing "Angry Birds", notification shows for text message. I click it, read the notification, hit back to get back to Angry Birds.

I don't see how inserting items between the text message and Angry Birds is a good idea.

What apps should have, is a way to always get to the apps main screen in the app. But changing the back button behavior seems confusing.

What if you change to the message app via the task manager?

In the message app context "back" takes you to a list of messages, which makes a lot of sense.

I happen to like this functionality and don't think it's confusing at all. As long as pressing back eventually gets me back to where I was before it's just fine.

In the email app (not the gmail app, the email app) I frequently have to press back 20 or more times, bouncing between earlier emails I read, before I get back to the app that I was on before the email notification popped up.

Whatever way you look at it, that's pathological behaviour.

I think this in an interesting discussion. Sometimes the user presses back to go to the previous screen, sometimes to go to the parent element (i.e., when you're seeing an email and press back to return to your inbox).

For me, the best solution would be make the back button come back to the previous screen, ignoring where they are. So, if you are playing Angry Birds, tap an email notification and then press back, you return to Angry Birds. But, also, in screens in which the user may want to go to the parent element, developers should put a button to go "home". In the email screen, a button to go back to inbox, in the Music app a button to go to the Music app initial screen...

Of course the real problem isn't which back button behavior too choose, it's that there's a choice to be made at all.

Both back button behaviors are perfectly valid and convincing arguments can be made for each, so the choice is pretty much arbitrary. But if Google doesn't enforce any particular behavior and leaves it up to the developers, the only possible result is confusion.

Additionally one could make the argument that the whole back button concept itself is inherently confusing, precisely because the right choice of behavior isn't obvious.

... or users can just be given the option and decide for themselves.

http://i.imgur.com/ym4W4.png

No, no.

Config settings like that are a way for lazy designers to avoid making hard decisions.

Joel Spolsky wrote about this over 10 years ago:

Every time you provide an option, you're asking the user to make a decision. That means they will have to think about something and decide about it. It's not necessarily a bad thing, but, in general, you should always try to minimize the number of decisions that people have to make.

and

"But wait!" you say. "It's important to have options for advanced users who want to tweak their environments!" In reality, it's not as important as you think. This reminds me of when I tried to switch to a Dvorak keyboard. The trouble was, I don't use one computer. I use all kinds of computers. I use other people's computers. I use three computers fairly regularly at home and three at work. I use computers in the test lab at work. The trouble with customizing your environment is that it just doesn't propagate, so it's not even worth the trouble.

http://www.joelonsoftware.com/uibook/chapters/fog0000000059....

Does that second part really apply to mobile development though? Most people only use one phone, or maybe two, for anything more involved than making a call.

They also use a tablet or two, maybe an ebook reader, maybe a TV running the same OS, etc etc.

i love those reasoning of 'real' designers to enforce what THEY think is best.

like the 'designers' of gnome3 (using the term loosely here) who thinks focus-follow-mouse and click-does-not-raise-window are things that only the devil would use and so no one should be allowed 'for usability sake' and 'think of the children'

think about it. a black wallpaper is the best readability option. period. so let's remove the user ability to change wallpapers pronto!

what i say "everytime you provide the user an option, you are asking him to, if he uses the software enough, to take a little second to make a decision that will give him an incredible productivity edge"

now, stop being lazy and hiding behind excuses. work on the real problem: how to present the options so they are not in the way, like joel mentions it while not being missed by the user

Did you read the link? He specifically addresses a subset of your issues:

This doesn't mean eliminate all choice. There are enough choices that users will have to make anyway: the way their document will look, the way their web site will behave, or anything else that is integral to the work that the user is doing. In these areas, go crazy: it's great to give people choices: by all means, the more the merrier. And there's another category of choice that people like: the ability to change the visual look of things, without really changing the behavior. Everybody loves WinAmp skins; everybody sets their desktop background to a picture. Since the choice affects the visual look without affecting the way anything functions, and since users are completely free to ignore the choice and get their work done anyway, this is a good use of options.

(Note this part: everybody sets their desktop background to a picture)

Yes, and i was pointing out how bad it is.

So you can only go crazy on futile options and not useful ones? Give me a break.

I think the best of both worlds is to have whatever your giant designer brain thinks is best be the default, and include options to change whatever you want. So if you don't care, you get a good preset, and don't have to make any decisions, and if you do care you aren't restricted.

I'd be wary of configuration settings like this, they sidestep the problem and create another one--you still have potentially confusing navigation and now there's more clutter in configuration screen. In this case, the configuration setting is badly named too, 'Manage "Back" button' makes sense to the developer, less so to the user.

There are useful settings that help me accomplish the task, and then there are not so useful settings where developer simply couldn't decide. I particulary dislike configuration UIs that devote whole section of toggles and switches for configuring the configuration screen itself.

So, giving the user more control is a bad thing?

While I understand that users can be easily overwhelmed with a plethora of options, this one makes sense.. especially for an email app.

Looks more like working around deficiency in navigation, than giving more control.

Rethink your UX, put together prototypes, user-test, and repeat. Leave configuration option as last resort. That's the approach for app that wants to "Simplify my life" and "Make me amazing".

There are hundreds of design decisions that go into any product. Designers can't give each and every one a configuration setting, and can't know before launch which decisions will be the wrong ones.

If the back button did it's job properly then the feature would just work; you wouldn't need to manually configure it to match your mental model.

Now that's only an option, if users understand what will happen and why they should change this setting. "Manage Back Button" is not an understandable option. So instead of solving the problem you just defered to the user. That's not design, that's just lazy.

I like Android, but the back button is totally useless to me. It only works in the simplest of cases, namely when opening an app and not navigating beyond that, I know I can press the back button to get to the home screen.

Otherwise, my workflow basically goes: press home button, use the task manager to kill everything, then visit an app and navigate top-down to where I want to go. Rinse and repeat for the next app. Like others have been saying, the back button is inherently either arbitrary or confusing, and I don't know how to fix it.

It should be replaced as a permanent UI feature with a task switcher button. I don't know how a modern operating system can get by without some sort of taskbar equivalent. I need to know what apps are open, and be able to navigate to them and close them as needed. Why has this not been implemented? I'd suggest putting this into the slide down top bar if there weren't full screen apps that totally break this function. Therefore, I suggest replacing the back button with a task switcher. I won't be holding my breath.

The ideal behavior would be if the app is launched via another app it should not touch the back stack. If I launch the email app from the home screen or app folder, it should populate the back stack so that hitting back brings me from the email I had open to the inbox.

My motivation for debating the two uses of the back button is whether I prefer a smooth OS integration (back as in back in time) or whether I prefer displaying more ads and am willing to capture the user inside (back as in up within my app).

It has unfortunately little to do with UX, since both end up being confusing on edge cases (Astro's horribly enraging "press back twice to 'exit'", the conversation or gmail app issues people mentioned in this thread).

I personally tend to prefer back as in back in time but I know for sure opinions vary.

What confuses me about this guideline is it suggests the back button behaves the same way as the new up button introduced in Honeycomb?

This is what I was told at the Android developer labs in Paris last November, in a Session about Ice Cream Sandwich Design:

http://developer.android.com/guide/topics/ui/actionbar.html#...

I'm not sure where I stand on this; and it's possible the context should determine the behaviour. But equally, perhaps Google just want consistency?

Weird, I just read the docs and none of the comments seem to relatr. The guidelines from an app with hierarchy is to have back and up buttons one all pages but home, up is on top left, back is in nav bar, bottom left, and this even when they point to the same target. Back is about click history, up is about information architecture. It makes sense.

Since no one else has mentioned it, ICS has improved how you navigate among apps.

The three omnipresent buttons are now back, home, and recent apps. Recent apps pulls up a visual stack of everything you've used recently, so the ICS expectation would be that users would hit that key if they want to navigate among apps.

How do phones with hardware buttons access the recent apps list? Same as in 2.3 (long-press home)?

I only have a galaxy nexus, so no idea! :) Repurposing the search key would probably make the most sense to me, but I can see that would be confusing.

Has ICS rolled out to any older phones yet?

I agree. Please get rid of the way the back button currently works, Google. It should only go back within the app, and that's it. Just like your browser back button on your PC, doesn't affect any other app in the system.

And while you're at it, pretty consider getting rid of all the buttons altogether, and just use screen gestures, kind of like in N9's Meego. I keep getting this feeling that being there all the time, they are just wasting precious space.

Totally agree with you. WP7 behaves the way you describe.