The Android back stack is broken
I want to discuss something that’s been bugging me for a while. The Android back stack. Most Android users love the back button, and I do too. But, the design is broken. I’ll explain with an example:
You receive a text. You tap the notification, which opens a conversation with your friend. She invites you to a party and asks you to invite some friends. You respond, “sounds good!”, and then tap the back
button on your Android phone to return to your list of messaging contacts. Except instead of going to the list of contacts, you are taking back to the Android launcher.
“Huh”, you think to yourself, “I swear hitting back from a text conversation took me to my contacts list?” Moving on with life, you tap on the messaging app and proceed to fire off texts to your buddies to invite them to the party. You close the messaging app by hitting home.
Five minutes later, you receive a text from your buddy who says he can’t come because he’s playing Skyrim. You reply, “get off your ass and socialize you introverted dragon-born”, you tap the back
button to return to the launcher. Except this time you end up at your buddy list.
Now you’re super confused. You swear that last time you hit back, the launcher opened, but this time it was the buddy list. How is this possible?
Unfortunately, the result of pressing the back button is non-deterministic. There is no way to know for sure where the back button will take you. The Android Back Stack
Every Android application is a series of activities held in a stack, which is together is called a task. When the user presses the back button, the top activity in the task is popped off. If there are no more activities, the user returns to the parent task that started the task, which is often the Android launcher. Multiple tasks can be running at once, and the user can switch between them using the multi-tasking button or hitting home
and choosing a new app.
Checkout this diagram from the Android developer documentation of a sample task:http://developer.android.com/images/fundamentals/diagram_backstack.png
On paper this system is consistent and deterministic. In practice, Android phones don’t have unlimited memory, so when too many tasks are in RAM, the system will destroy old activities and tasks to make room for new ones. Other times, the system will destroy activities after a period of inactivity.
(Edit: +Dianne Hackborn
of the Framework team corrects me:
"I'm sorry, but you are completely wrong to tie this with memory management. How back operates has nothing to do with memory management, activity state saving, etc. It is deterministic without knowing how activities are being killed in the background and their state being saved.
What is missing is just consistency in the behavior apps implement for the back button. And actually this is a more specific inconsistency: how apps handle their back stack when the user launches into them to a potentially different state than they were last in. That is, from a notification or a widget."
More explanation from her in the comments. I really wish G+ let you link to comments. Sigh. )
For some apps this behavior is inconsequential. However in other cases there are unintended consequences, such as with notifications. When a user clicks on a notification, a new task is started or
if the task is already in memory, a new activity is added to the top of the task stack.
There is no way to know which behavior occurred. So when you open a text message notification, the behavior of the back button depends on whether the messaging app task already existed in memory or not. The ambiguity is confusing, even to seasoned Android users.
Android developers have tools at their disposable to combat this problem. App best practices suggest to lazily save activity state to disk in the event of activity destruction, and restore state when the activity is needed again. Unfortunately, many apps don’t do this. And the ones that do often build perplexing activity stacks. Even first party apps are not immune.
Take the Google+ app. It has the most confusing back-stack I’ve encountered. I often click on posts from my launcher’s G+ widget. If I hit the back button repeatedly from a post, I get led through a seemingly random series of activities. Sometimes this stack ends at the launcher, and sometimes it ends at the Google+ home activity, but I’m never sure which I’ll get or how many steps it will take to get to the end.
The Facebook messenger app doesn’t manage activity state correctly. When you receive a notification, the app opens a new instance of the conversation activity, even if that conversation was already at the top of the activity stack.
So when you hit the back button, the conversation you were just reading fades out, then fades back in because the same activity appeared twice on the stack.
Even as a developer and Android power user, I’m still regularly confused by the back stack. I can only imagine the confusion for novice and casual users.Note: I glossed over some details of the back-stack and simplified the description for the purposes of narrative. If you’re interested in understanding the precise behavior of the Android back-stack, read the documentation: http://developer.android.com/guide/topics/fundamentals/tasks-and-back-stack.htmlIce Cream Sandwich to the rescue! (not)
So what can be done? In Ice Cream Sandwich, first party apps introduced a new design language straight out of iOS: a software back button in the top left of the screen. The beauty of this “bread crumb” back button is that it takes you back to the “logical” place in the application, instead of popping the current activity. Often these are the same place, but not always.
For example, in the text messaging app, hitting the bread crumb back button takes you to your conversion list every single time. Ah, finally some consistency! Unfortunately, this is a small victory. Each Google app implements the bread crumb back button differently. Some, such as Google+, seem to use it as a redundant back button. Others such as the Android Market, use it in a way that occasionally are counter-intuitive.
If anything, the new breadcrumb back buttons have made things more confusing
because I often wonder if I should hit the hardware back button or the breadcrumb back button. Despite this, breadcrumb back buttons are put to good use in a few apps, notably Messaging, Gtalk, Gmail, and Gallery.A (better) Solution
The back button is powerful. When it works (and it works most of the time), apps have more flexibility than on iOS to integrate activities from other apps. The intent system in Android is brilliant, but would be useless without the back button. We’re stuck with the back button for the long haul.
Thankfully, with the introduction of the soft back button with the Galaxy Nexus, the Android team has increased flexibility in how they represent the back stack. For example, the back button could be annotated with the icon of the task it leads to. This way the user knows if they are about to accidentally leave an app. The breadcrumb back button could indicate where it leads. Checkout example mock I’ve created with user experience designer +Fravic Fernando
attached to this post.
With this design, it’s clear to users where they are going, so they know whether to hit the back button or the breadcrumb back button. The confusion is gone. This is a simple and relatively easy to implement solution. There are more visually exciting solutions, such as representing the task stack as an actual visual stack and using swiping gestures for navigation.
Even with my suggested improvements, apps will still have poorly designed activity stacks. Ultimately it's up to app developers to build consistent and easy to navigate app. Perhaps the best solution is to raise awareness amongst developers of the perils of the Android back stack.
What it comes down to it, Is the back stack problem a show stopper for Android? No. Android wouldn’t be the most popular smart phone OS if it was. But, it’s a real issue that effects Android users every single day.
I’d love to hear your thoughts. Does the Android back button bother you? If so, how should it be fixed?PS: This is the last smart phone related update I’ll be posting for the time being. I begin work at Microsoft next Monday and it would be inappropriate for me to comment on the industry while I know any confidential information.