I made the longer argument here, but let me make it more succinctly. The chain of logic goes:
- The back button should only be used for navigating between apps, not within any application.
- The recent apps screen serves application switching more predictably than the back button (even under its most favorable circumstances), except…
- …the recent apps menu is not quick enough for the common case of switching back to the last app, so we need a quick button/gesture for this. I suggest a swipe up motion from the recent apps button (similar to the swipe up on the home button that currently takes you to Google Now). It’s debatable whether repeating this gesture should cycle you through all recent apps or just between the current and last app (I suspect current and last is the better behavior). Either way, this back-to-last-app allowance covers the most useful case for the back button: when an application switches you to another app–such as to display a link in the browser, compose an email in the mail app, or play audio in the music player–you should be able to get back to what you were doing previously with little effort or thought.
So the recent apps button with a simple new allowance is a better back button than the back button itself.
Now of course, claim (A) requires substantiation, which two members of the Android team do a well enough job providing here. The odd part is that they as much admit in passing that the back button is a bad in-app navigation mechanism and then spend the rest of the talk proudly describing the surprisingly convoluted scheme Android and its apps must conform to to deliver non-maddening back button behavior. Why subject developers and users to such headaches?
Android should ditch its too-clever-by-half task/activity paradigm in favor of the app/screen model expected by developers and users alike. If my app wants to open a link in the browser, that’s not a new activity, its just an app switch to the browser, just like on the desktop; going back to the app should be an ordinary matter of app switching requiring no special cooperation on any app’s part.
A problem that remains is deciding when apps should open to their last viewed screen or their ‘root’ screen: when I switch back to the app I was using 2 minutes ago, I usually expect the screen I was just looking at; but when I switch back to an app I haven’t used in a long while, I usually expect the app’s root screen. I’m not sure what exactly the timeout period should be, but I do know what screen I see shouldn’t depend upon how I open or switch to an app, whether through the launcher or recents list. It should be the responsibility of apps, not Android, to make their root screens easily accessible from any state.
Again, strangely, the Android team seems to have caught on to this, at least going by the example they’re setting in their own apps with the ‘Up’ navigation element now in the Gmail, Caldendar, and Youtube apps. Obviously some legacy apps rely upon the back button, so it should get deprecated like the menu button: back should only contextually appear on the bottom bar within those legacy apps. And of course, some applications might have their own in-app need for history navigation, e.g. the web browser. This in-app navigation, though, should be done with app-specific, in-app controls, not a universal button. Again, the Android team already sets the precedent here by including a proper back button in Chrome for Android.
The last remaining piece is to make app-initiated app switches visually distinct from mere in-app screen switches so as to keep the user oriented (and so the user can utilize the back-to-last-app action when it’s most needed). If an action in an app takes me to the web browser, Android should make it very clear that I’m switching to another app. One solution would be to replace the ‘recent app’ button icon with the icon of the current app, such that the user can always get a visual indicator of the current app; when switching apps, this icon would pulse or glow for a brief time to make the switch more noticeable.