So, What's the Problem?
While it is very easy for us, the developers, to understand what pressing the back button does it isn't so easy for the end users. The back button behavior is inconsistent.
The back button can perform any of the following actions:
- Go back to previous screen (activity)
- Dismiss a popup
- Terminate a long running process
- Close on-screen keyboard
- Go to previous page on browser
- Exit the running app when on the last activity
- Return to previous app when on the last activity and the app was launched through intent from another app
An added problem comes when trying to understand when the back button cancels a running operation and when not. For example, when installing apps from Android market tapping back takes users to previous screen and leaves the installation process running in background. I know there's a rule that back cancels operations that are presented users as popup progress indicators and any other cases it is used to navigate. But is that what users expect? Do users have to think before pressing back to understand what is going to happen?
One More Complication the Up Button
In Honeycomb and now also in ICS action bar has became part of the core platform APIs and hence an integral part of Android UIs. The new API allows changing the top left icon's functionality from what it was before. It can be used as "up" button now (also adding the visual indicator next to the icon). But what is the difference between pressing back and tapping up from the action bar?
According to guidelines difference between back and up is that up takes user one level up in the information hierarchy and back takes user back to the previous screen.
See the following example scenario. User navigates through screens from one to four.
On screen 1: Pressing back would exit the app. Up button on action bar is not active.
On screen 2 and 3: Back button and up button both take the user one screen up. Either screen 1 or 2.
On screen 4: Back button would take user to screen 3 and up button to screen 2.
Is this forcing users to think before taping or making them endup on different screen than they thought.
What About the Home Button
Home button adds some additional confusion in some situations. Lets take the previous scenario as an example again. On screen 1 pressing back button or home button will both take user to app's home screen (assuming that the app was launched from home screen or launcher drawer). What happens in the OS is different in each situation though. If users clicks the back button the app is actually terminated as the last activity is closed. Pressing home button, on the other hand, will not close the activity and the app will only be paused and if the OS doesn't need more memory and kill the app it will still be running and in the same state if the user returns to it later.
My Thoughts, How Should it Work?
Before Honeycomb action bar functionality was clear. Top left corner always took user to the app's front page. That was a familiar concept that was used in the web for ages. For example Android Market logo always takes you to the front page.
I think this is how Android apps should work. The new action bar up button is more confusing than helpful.
And what comes to the back button there's really never any need for back button to exit the app. Home button will take users to home screen and swiping in the multitasking menu will kill the apps if needed. As on ICS on new phones all the buttons are on-screen the back button could simply get disabled when user reaches the last activity if the app was launched from launcher icon. This would make some of the confusion to make away but still wouldn't solve all the problems.
Don't Make Users Think
Navigation is important. Users should always know where they will endup without thinking. Even a slight confusion in something so central as navigation can have big influence on general user experience. I don't think there are easy answers for this problem but I think it is a problem on the otherwise great Android platform. What do you think?
[Update 2011-12-25: I added a second part to this article to continue the discussion from comments and clarifying my stance on some of the issues: Android Back Button, Take Two]
[Update 2011-12-25: I added a second part to this article to continue the discussion from comments and clarifying my stance on some of the issues: Android Back Button, Take Two]
#1, #5, #6, and #7 are the same thing and are identical to behavior in a Web browser. Pressing the BACK button in a browser takes you to the previous Web page, regardless of how you got to the Web page in the first place. Pressing the BACK button in an Android app should take you to the previous screen state, regardless of how you go to the screen state in the first place.
ReplyDelete#2 and #3 are identical, insofar as the BACK button does not "terminate a long-running process". Most dialog boxes in Android have an on-screen cancel button, mimicking their Web counterparts. And, as I think you have pointed out, dialog boxes in general are bad for UX flow, so lots of experts are asking developers to try to minimize their use.
#4 will not exist on many devices. Those with on-screen buttons will have the BACK button replaced by a close-keyboard downward-facing arrowhead, as seen in 2011's Honeycomb tablets. This apparently does not even behave anymore like a BACK button from a programming standpoint. Admittedly, on some devices, notably Android 2.x devices getting the Android 4.0 upgrade, the BACK button will always look like a BACK button. However, even this should not be especially confusing to the user, as it follows the pattern from #1, #5, #6, and #7, where BACK returns the screen to the state it was in before whatever you just did, in this case closing the input method editor that you just opened.
IMHO, the "principle of least surprise" with respect to the BACK button is just that: return the screen to the state it was in before whatever the user just did a moment ago. Admittedly, that doesn't always hold up in practice, notably for Web browsers, but it should work for most other situations.
With regards to "Up", I suspect that the vast majority of apps (and users) will ignore this construct, for the reasons you cite.
You probably already read Tim Bray's take on this -- his BACK philosophy is similar to mine, though he is more pro-Up than I am:
http://www.tbray.org/ongoing/When/201x/2011/11/03/The-Back-Button
I think it is a little bit annoying for developers to build for a constant beta with changing concepts. It produces unsolvable situations and inconsistency. Google's "Beta" label is iconographic. It worked (and works) quite well with web apps where rolling out a new version does not involve the user or device.
ReplyDeleteThis iterative approach does not work well with an operating system and native apps.
About the back button itself: I guess it will be possible to do per-app graphic design with the buttons in the next Android version so the buttons itself can announce their functionality better. After all, they are on-screen buttons.
The history of the back button shows how much Android is a moving and evolving platform. It is sure confusing for both users and developers. I'm sure that in restrospect, Google engineers would do things differently than decisions taken years ago.
ReplyDeleteAn indentical article could be written on the menu button which is now becoming somewhat deprecated and replaced with on-screen menus, illustrated with the HC+ overflow menu, for the holy goal of "discoverability".
Now I can't wait for Android 6.0 where the Action Bar paradigm will be deprecated...
Another thing that I find very confusing in apps (and I'm a developper!) is the abuse of nested activities. IMHO the main activity should'nt spawn more that 1 level of activity. This can be achieved using tabs judiciously (instead of spawning zillions sub-activities).
I almost never find myself confused by the back button . There are a lot of ways to go forward but all back ever does is reverse them. The odd time I install an app that doesn't feel very native but that hasn't happened in ages.
ReplyDeleteUp it different, not sure about that. Need to actually experience more honeycomb app to get a grasp on it.
Thank you for the comments everyone. Very valuable insights from different point of views.
ReplyDeleteMark, thank you for pointing out the article. I hadn't actually read that one but I have seen Steven Van Bael's one that is referred from it. I think both of them miss the point (as do some points in your comment). While technically it is true that what happens in the OS is similar and consistent in many cases I'm talking about user's mental model. Users must be able to "simulate" the system in their head to understand what is going to happen. They do that by building a model of an app in their head. That's what we do with pretty much everything. For example, in case of a car we think that turning the steering wheel turns the front wheels. What happens in actuality is much more complicated but we don't care. The same is true here. All the different cases are making it difficult for users to build this model.
I think I failed to explain my point of view very well in this post. Sorry for that. I think I'll write a second part talking more about mental models.
I disagree with the main thesis of this post, I rarely had feeling that I'm confused what back button will cause (except one situation when I tried to "back" to previously selected tab). As for me a huge problem is how developers misuse stacking activities mechanism (which is strictly connected with 'back' button purpose). So many times I've been frustrated having dismiss deep stack of activities one by one because author haven't put "some layer of workflow abstraction" over raw stacking mechanism.
ReplyDeleteI would tend to agree with Mark's points. I don't think the typical user will form a mental model as complex as the true model. The back button is the "whatever was happening before" button.
ReplyDeleteOn the suggestion of always leaving the app through the home button, I think this *would* break the consistency of the back button. It would become the "whatever was happening before, unless I'm at the root of an app" button. It would also result in an additional two clicks (and a swipe) once the user has left the context of the application if they *do* intend to kill the app.
I find the up action quite powerful when you factor intents into the situation. It facilitates more navigation around the hierarchy without the assumption that the user entered the app through the front door. It's a shame that there's no way to get to the app home when up is showing though.
"All the different cases are making it difficult for users to build this model" -- huh?
ReplyDeleteHere's a similar roster of complaints about the BACK button in Web browsers -- the BACK button can:
1. Go back to previous page
2. Dismiss a dialog (e.g., classic HTTP authentication)
3. Go back to a previous Web site
4. Go back to the home page, if you were on the home page and chose a bookmark to navigate to beforehand
5. Pop up a dialog (e.g., when trying to BACK out of a StackOverflow page when you have started typing in an answer, presumably triggered via onbeforeupload)
6. Do nothing at all, if there is no place to go back to
7. Do nothing at all, because some developer is playing JavaScript games and is attempting to block you leaving their Web page filled with lovely ads or something
All the different cases are making it difficult for users to build a mental model of how Web browsing works. Clearly, this Web thing is a fail.
Oh, no, wait... :-)
I think the BACK button *can* be confusing -- on the Web or in Android -- but that's mostly where things violate the norm of "get back, get back, back to where you once belonged", to quote some mop-tops. That's why I get leery in support forums when people mess around with onBackPressed(), with an eye towards breaking the "BACK means back" model. Similarly, while I can understand the value of the StackOverflow "are you sure you really want to leave the page" stuff, it makes me a bit queasy .
I agree with the suggestion in the article. The app branding logo takes always user to the App top hierarchy(landing) screen. So we don’t need the indicator arrow on top left with the logo. I thought the arrow will take me to the previous page like we see in computer browsers even the function is doubled up with the physical back button. It is already in the guide lines but I think this indicator arrow is redundant.
ReplyDeleteThe physical back button/on screen back button should work with;
#1 Go back to previous screen (activity)
#4 Close on-screen keyboard
#5 Go to previous page on browser
#7 Return to previous app when on the last activity and the app was launched through intent from another app
#2 Dismiss a popup
This should put cancel button on the screen.
#3 Terminate a long running process
If it’s running in modal, need a cancel button. If user has a choice to do another activity on the same screen (e.g foursquare: while the app is loading the check in list, you can search), back button takes user to the previous page.
#6 Exit the running app when on the last activity
I agree with Juhani’s thought in the article. The button should be disabled.
I am new to developing applications for android platform and my first appplication uses tabs in main activity. When I select second or third tab and from there start new activities I usually accidentaly exit appplication using back button because I press back button when main activity with tabs is displayed. For now this is only situation where I found back button is confusing for the users. I am really thinking about redesigning my application to not use tabs for main activity becaouse of that.
ReplyDeleteI completely agree that Android navigation is extremely complicated to understand - not only by novice users but also by geeks. There is no logic. Looking at http://developer.android.com/design/patterns/navigation.html things get even more complicated... The result is that you never know what will happen.
ReplyDeleteI use to override the back button and present a dialog to the user asking him what he really wants to do. Unfortunately the home button cannot be overridden.
Ithink the problem is that the back button in android brings a new concept in interfacing, so the main problem may be the name of the button itself.
ReplyDeleteThe logic seems to me that back button is orientated under user actions, the main intent is to go back 'no matter from where to where'.
So you were in application that linked to another? back button will bring you to previous app.
Did you opened an application from home? back button will 'close' it and leave to home.
Clicked a link in a web page? back to previous page.
This back button in android, in my view, takes the tradicional 'inside application back' and moves toward a 'user actions back'.
I think the tab layout have a problem thou, the back seems to focus in user actions + screen, and switching tabs in a application is not a screen change, therefore it breaks the 'back' chain... then it starts to get confusing to the user.