Shared publicly  - 
Can't we just go back, to Back?

I'm watching the Navigation in Android session from Google IO and just learned about some upsetting changes. Google is continuing on their effort to upend the concept of Back, and this time, notifications are in the crosshairs.

Example: You're looking at your Google+ stream when a Gmail notification comes in. You click into that notification, Gmail opens, and after reading the email, you press back.

What do you expect to happen?

If you've ever used Android, you would probably expect Gmail to close, and G+ to reopen where you left off. This is the way it has always worked. In Jelly Bean, you will, instead, be taken UP in Gmail to reveal the "conversation list." If you press back again, it will take you to... the home screen?!

If I understand this correctly, they have fundamentally changed the way notifications work in Jelly Bean. The basic concept is, now, clicking a notification clears the task stack. Therefore, pressing back, after clicking into a notification, takes you back to the home screen, and not the app you were previously in.

They justify this decision by pointing out that the "recent tasks" button is easily available to switch back to the previous app, and that it's "only two clicks away." What's even worse is that it seems this decision was made to reduce user confusion in cases where the task stack is very large(?).

What ever happened to designing for the most common usage, like the one mentioned above?

This doesn't only bother me as a developer, but enrages me as a user. I have been using Android for 3+ years, and for me, the back button and notifications have always been the shining example of why Android is better. Now, I'm really not so sure.

CC: +Adam Powell +Richard Fulcher 
James Power's profile photoFederico Paolinelli's profile photoDavid Lawerteh's profile photoPeter Sinnott's profile photo
This aggravates me to no end as a user. grrrr
I've noticed this in JB and its pretty annoying. It also kills the whole point of the “up" navigation from the app icon; this could be done in order to adopt the side menu when tapping the app icon instead
Yeah, this is terrible behavior. 

"This doesn't only bother me as a developer, but enrages me as a user. I have been using Android for 3+ years, and for me, the back button and notifications have always been the shining example of why Android is better. Now, I'm really not so sure."

This sentence sums up my feelings regarding navigation between the two major OSs as well. I still think Android is better (iOS back button isn't always noticeable or convenient to reach, at least Android one can always expect the actual back button to exist) - but the new behavior on Android is garbage. 
Wow that is a major change in flow and one that is not intuitive at all
Thanks for the feedback, even though we disagree. :)

Based on our user testing, we are designing for the common use case here. The element that made this such a difficult decision was that if you allow Back as an immediate reverse task jump after answering a notification, you create inconsistent task state for the user to find later, which people found far more frustrating over time than the one-time adaptation to using Recents for this use case instead. You don't see this hidden cost when testing a certain flow in isolation with the old way, but you do see when your muscle memory is disrupted by this change. Back as a reverse task jump here was a short term gain with a high long term cost.

To your example, in an app following these guidelines Back from after answering a notification would only land you at the home screen if answering the notification opened the root activity of the target app. If we led to misunderstanding with the way we phrased this in the IO session, please let us know which part caused the confusion so we can be clearer in the design guide and other docs.

We're not pretending that it won't be a rough transition as apps update to the new guidelines. Hopefully in time we can convince you that this was a better way to go.
Thanks for the response and clearing up the specifics, +Adam Powell. I will have to re-watch to find the source of my confusion, but just to be clear:

In my example, after clicking into the Gmail notification, the user would press back once -> Conversation List, back again -> Google+?
Well they are only guidelines, noone follows them, so have no fear. :)

At least Currents, got rid of the back button.
Drop back or drop up. I'm going to go all Harry Potter and say "neither can live while the other survives" :)
It would go Notification (task switch) to Gmail conversation, Back to Gmail conversation list, Back to Launcher, since the conversation list is the root of the Gmail task. (I might have misunderstood you above; I thought you meant Back would go immediately to Launcher from the thread you were reading, skipping the conversation list.)

Once you task switch by opening the notification, you have a hard break, just as if you switched in via Recents. We didn't illustrate this very well prior to Jellybean - in JB we've added a very deliberate "swooping" animation where the current window zooms out into its place in the Recents list while the new task's window comes forward. This helps reinforce that you've fully switched contexts.
+Adam Powell So my original assessment was correct. Damn.

I sincerely hope that the Recents list is 500% faster than it is in ICS, because otherwise this change will be extremely painful. 
+Jake Wharton I hope we made at least the beginnings of a case in this session that we really do need both. Having only one and leaving every developer to override it to mean the other thing when convenient is partially how we got into this mess in the first place. :)
+Paul Burke It is. Speeding up the Recents list was a prerequisite for unleashing this decision on the world. ;) We had originally wanted to do it in HC/ICS.
It is much faster on JB - but as a user it's still pretty painful :(

It does remind me of using my iPad and switching between applications using the iOS switcher drawer - I don't consider this a good thing
+Adam Powell Before synthetic tasks stacks were introduced I would have wholly agreed. The logical separation of back acting like a browser and up ascending hierarchically through an app made perfect sense to me. With this latest change, however, I'm not yet convinced it's for the best. I understand it was backed by user research but it just feels wrong as a developer.

I would have loved for back to disappear completely being purely replaced by up and task switching. This is one thing I think Apple got really right (once they actually implemented switching).
+Jake Wharton Even without the policy change around notifications, synthetic task stacks still needed to exist for cases where Up jumps tasks. It's a use case that exists and can't be ignored in a system where apps can collaborate by starting each other's activities. Back still needs to exist in this scenario too, to provide a way out of a different app's viewer or share-box activity without jumping to another app.

That's part of why the Navigation talk had so much ground to cover. If you attack any of the subsections in isolation you'll come up with a locally optimal solution that is completely inconsistent with the rest of the system.
I guess I should (and will) watch the whole video but is this related to something I came across in the javadoc this week. It kinda surprised me but maybe I wasn't paying attention when HC was released.

 'In API level 11 (Android 3.0/Honeycomb) the recommended conventions for app navigation using the back key changed. The back key's behavior is local to the current task and does not capture navigation across different tasks. Navigating across tasks and easily reaching the previous task is accomplished through the "recents" UI, accessible through the software-provided Recents key on the navigation or system bar.'
I can accept having to use recents. It's a change, but now that it's an always on button, it's almost acceptable. It's still far too slow for the recents list to appear after tapping the button though.
Using recents maybe but a back button that goes places I have never been might well drive me insane.
Why not use the old behavior if back is the first navigation activity after the notification's activity is displayed, otherwise use the new behavior (if home is pressed, or the user navigates deeper into the app displaying the notification)?
+Jason LeBrun My guess is the back button is going to disappear in the next version of Android. Either the functionality or the actual button.
+Jason LeBrun We want navigation behavior to remain predictably stable when you return to an Activity you were in previously.

+Peter Sinnott There are no plans for that. In the presence of Android's ability to host activities from other apps on your own task you really need both Back and Up.
Add a comment...