Accentuate the Positive (Navigation)

To quote Juhani Lehtimaki:

If it takes almost an hour to explain developers how to handle back it simply cannot be easy enough for users to understand. To me the biggest problem with the back button is its inconsistent behavior without any visual hint of the currently active state of the back button.

The BACK button, like many things, is simple in simple cases, and gets complicated in complicated cases. Google’s recent efforts seem to have focused on trying to handle some complicated cases, and that’s perfectly fine as far as it goes.

However, in many apps, there is a simpler solution: avoid making BACK be a load-bearing part of your navigation. Rather than have users rely on BACK (negative navigation), make sure you have means to allow users to tell you where in your app they want to go (positive navigation). Use BACK for “get me outta here” requests (e.g., escaping a modal dialog) and system-defined navigation (e.g., closing the input method editor), and try to have BACK make sense in other cases, but worry more about ensuring users can more positively state what they want to see.

The action bar can be a key tool for helping with this, by giving your app a common spot for navigation elements (buttons, overflow menu items, etc.). If need be, investigate using the “side navigation” or “ribbon” pattern used by various apps, if you feel that your navigation options cannot reasonably fit within the action bar, or would not be intuitively obvious when shown in action bar-sized icons and such. And elements like ViewPager can allow for positive navigation within a peer set of elements (e.g., swiping through contacts), without relying upon the BACK button. And so on.

This may also involve heavy use of FLAG_ACTIVITY_REORDER_TO_FRONT, so you avoid creating extra copies of activities for each navigational request from the user. Or, if you are using lots of fragments in fewer activities on tablets, implement the appropriate transactions that allow you to keep the fragment around (e.g., attach and detach) so you can reuse it later if navigation requests warrant.

If you think about the Web apps that you use, ponder which of those you find yourself using the browser’s BACK button, and which of those you do not. Then, see how you can take the design lessons from the ones that do not rely upon BACK and apply those to your app.

After all, the user can only be confused by BACK if the user ever presses it.