Over a million developers have joined DZone.

Android Back Button, Take Two

DZone's Guide to

Android Back Button, Take Two

· Java Zone ·
Free Resource

Download Microservices for Java Developers: A hands-on introduction to frameworks and containers. Brought to you in partnership with Red Hat.

It thought I'd write a follow up to my previous post about Android back button to clarify my stand on it and explain my point of view a little better. Also, I want to thank anyone who contributed thoughts to the discussion in the previous post. I find it the discussion very fruitful.

Firstly, I'm not against the back button. I don't think back button should be removed. I think it makes navigation on the phone much easier than how things would be without it. I believe that user experience even with the current, in my opinion flawed, approach is much better than for example iOS single button approach.

While I'm not the only one who has written about this the other posts I've seen against back button behavior have been somewhat biased and therefore haven't managed to start a discussion about the topic but have sparked an argument instead. Even my precious post have been posted to twitter saying that from what I wrote somehow follows: "Android UX fail" or "Android UX is Shit".

That said, I still think it could be improved and I think it is currently flawed. What I want is a discussion about the back button. Hence this post. This post is meant to continue the discussion from the comments in the previous post.

Mental Model
But first, I want to clarify what I mean when I talk about mental models because I think mental model theory is the core behind my argument. I know this is probably very familiar to most of the people reading this blog but I still want to take a second to talk about them.

While the mental model theory can be taken pretty far but in this topic it can be simplified a bit for us to be  able to reflect about Android's back button and related issues. On the very basic level a mental model is a model in in users' head simulating the app's functionality. I think the easiest analog is the way we think about car steering. When we drive a car we're able to steer using the steering wheel because we have a model of understanding how it works. We think that the steering wheel is connected to the front wheels and turning the steering wheel turns them.

While in fact our mental model in the car example is not true (in modern cars the steering wheel is not physically connected to the front wheels at all) it doesn't matter. Because our mental model corresponds exactly how the steering function in real world steering a car is very easy for us. We don't even have to think about it.

The same applies to everything else we do including any softwarere use. We, as users, build a working model into our head telling us how the app functions. We are able to simulate the functionality and predict how the app will respond to our input. Whenever we're unable to predict the app's functionality or the actions don't match our expectations we feel that the app isn't behaving like it should. This is how usability problems manifest themselves. Simply mismatch between real world and our expectations based our internal simulation, the mental model.

We form our mental models the same way as we learn as kids. The real world works consistently. When we throw a ball it always follows the stame trajectory and we form a model we can apply to throwing other things without having to understand how gravity really works. It is consistency that makes learning easy for us.

Difference Between Implementation Model and Mental Model
As a respond to  Christoffer Du Rietz's article about Android buttons Tim Bray and Steven Van Bael have written very good articles about the same topic talking about the back button functionality. To me both of these responds demonstrate a problem. While they are factually correct I think they talk about a little bit different thing that what my point in this issue is. They both explain how the button works very consistently technically. To me that isn't important. What is important is that it looks and feels to consistent to users.

Beware of Anecdotal Evaluation
Whenever reading about usability problem the normal reaction is to think if this applies to me. I do it all the time and I keep hearing it over and over again on blogs and at my work. Unless you're writing an app for Android developers it is very unlikely that you think about apps same way as your users do. Be aware of difference between you and your users.

Always remember:
You are not your user!

Browser vs. Operation System
As Mark Murphy pointed out in the comments back button is very familiar to us from browsers. Although it is possible to find technically similar cases in the browser world for most of the cases I've listed they are conceptually very different from user's point of view. Browser back never interferes with keyboard or exit the browser. Also, a browser uses fairly clear pages metaphor where back fits very well.

An OS has much more interactions than a browser and an OS is pervasive and must support all apps. A small flaw in an OS will spread through the whole system.

In ICS release Google fixed one button related UX problem in Android. The menu button. The problem was that as the menu button was a hardware button there was no way to indicate if there's menu options available on any screen. For users only way to figure out if the menu button is active was to press it and see if a menu appeared. The fix came in form of on-screen buttons. Menu button simply isn't visible when there's no menu available. Brilliant, job well done.

On Honeycomb when the on-screen keyboard is open back button icon changes. This small change makes it very clear that it no-longer will take user to the previous page but dismisses the keyboard instead. On ICS it doesn't change anymore.

In my opinion this line of change could be taken further. Could the on-screen back button have more visual indication of its function? Would it be better if users could associate certain icon to certain functionality.

I still think that back button should never take user out from the app. In ICS it should get disabled or hidden when it would take user back to the launcher or home screen. Then again when the app is launched from an intent the back button could indicate that visually for example using the calling app's icon or something similar. I think that user's should not have to care about killing the apps, ever. Even if they do I think that is an edge case that can still be supported by the multi-tasking menu swipe.

As I said before I'm not advocating removal of back button. Neither am I thinking that existence of the back button is ruining Android user experience. I think it is a very useful and we're better off with it than without it. I do think, however, that it could be improved.


From http://www.androiduipatterns.com/2011/12/android-back-button-take-two.html

Download Building Reactive Microservices in Java: Asynchronous and Event-Based Application Design. Brought to you in partnership with Red Hat


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}