Making BACK Way Too Complicated

Last summer, I wrote a blog post, BACK Means Back, decrying some developer’s choices regarding the BACK button (e.g., “I need to override the BACK button to launch a context menu”).

Here I am again, this time, though, complaining about confusing new policies coming from Google itself. Google, it seems, wants app developers to lie to users, and that is difficult to fathom.

Let’s pretend that you are using a Web browser, like Google Chrome. Let’s pretend that you click on a link that opens a fresh browser tab. When you switch to that tab, the back button of the browser is disabled. That makes sense, as there is no history. One could argue that the back button might be enabled and would completely destroy the tab, but that might be seen as a bit too aggressive.

What Google wants, in effect, is for the back button to be enabled, and pressing that back button a few times in sequence would lead the users through Web pages that the user never visited that the Web site happens to want to show that, in theory, represents “the complete upward navigation path to the” Web site’s home page. In other words, the back button should represent fake browsing history, suggesting that the user clicked on some series of links (or whatever) to get to a particular point, when in fact they did nothing of the sort.

If Google did this with Chrome, I would expect a major “WTF?” reaction to come from the browsing public, not to mention having a handful of security researchers pointing out some pretty big holes in this scheme.

Yet this is what they want developers to now do for handling the BACK button in Android, for activities launched from notifications, home screen app widgets, and the like. At least, that is what they are asking developers to do in the Android Design site.

Moreover, the justification given by Google engineers (“BACK should not cross task boundaries”) does not make a lick of sense. By that argument, the BACK button can never lead to home screen. Yet, in their own example, the BACK button does just that. However, instead of it returning to the home screen immediately, we first lead the user to some activity that they never visited, and only then do we go to the HOME screen on the next BACK press.

Google’s recommendation here, IMHO, violates the Principle of Least Surprise. Users should never, from a single BACK press, have to ask the question, “WTF just happened?”. Yet, that is what Google is advising.

The overriding principle should not be “BACK should not cross task boundaries”. The overriding principle should be “BACK should behave like it would on a Web browser wherever humanly possible”, since that is where users first encounter the notions of BACK and HOME. BACK on a Web browser would never do what Google proposes BACK do in an Android app.

I like the Android Design site in principle. In practice, the fact that it has few justifications for its prescriptions and few implementation details means that it is doubly frustrating. That being said, I will generally advise developers to adhere to what is in the Android Design site. But I will not do so for things that, in my not-completely-unreasoned opinion, violate fairly basic UX concepts like the Principle of Least Surprise, unless somebody convinces me that the benefits are worth the attendant costs. I await convincing arguments in this case.

IOW, IMHO, BACK still means back.