Why is 'Up Navigation' a recommended Android guideline?

Question

In android the recommended way to access your applications menu is to click on the logo in the top left-hand corner.

The guidelines also advocate re-using this touch area as an Up navigation, which means if I am two levels deep in an application with some tree structure, I must press up (and effectively go into another context) twice before I have access to the menu.

This seems like a really bad user experience and I am torn between not following the guidelines (thus not having an app that is as intuitive as it can be) or having this bad experience in my new application.

Perhaps I'm missing some point or have not planned my application well enough. Can you suggest a way (with an android UI) that I can honour the guidelines and have a better user experience?

It is not suitable to put an entire main app menu into the action bar menu (top right)

Edit : If you'd like to see this behaviour yourself, go onto the google play store app, click the apps category, then games, then in game offers, then a game title. Now if you want to compare to an app you have installed by navigating to 'My apps' it takes 4 presses

Answer 1

You're right the scenario you're describing really does not provide good ux. However, there're reasons (and a workaround) for this.

It is important to know that in earlier versions of Android, there were only two ways of navigation:

Back (the arrow) and Home (the house)

While Home was always getting you back to the home-screen (a global escape-hatch), Back was getting you one screen back. These two rules are still true.

This caused the following problem: when you moved from screen A over B to C, it would need two Backs to return to screen A. If you think of an app with more than two screens, this becomes a serious problem.

Also, circulations were pretty common: You navigated from A to B then to C and then to B again. Hitting Back will now lead you back to C, although you might expect going back to A (if you expect it or not depends on the context).

To overcome these problems, the Up navigation was added together with the ActionBar in Android 3.0.

Up introduced an in-app escape-hatch. When you click it, you would move to the hierarchical parent of the current screen. (See http://developer.android.com/design/patterns/navigation.html for more details).

Also, when you enter an app from another app (which is a quite common pattern in Android) Back will get you back to the application you came from, while Up will get you to a different screen in the newly opened app.

The last piece of history is, that the Navigation Drawer was added after the Up-caret. I guess that google saw implementations of a drawer in more and more apps and found it pretty useful. They added it into their support-libraries so that everybody could use it.

Now, go a little further with your example: "go onto the google play store app, click the apps category, then games, then in game offers, then a game title." Now, Scroll down and click on an app of the "similar apps" section. Repeat this multiple times. Tapping the "up"-caret will now send you to the "Games" overview page again., which is nice.

Since you can't put every possible screen of your app into the Navigation Drawer, you need other ways of navigation. But Back won't work in some cases, so you still need the Up functionality. Unlike the drawer which is provided by google as part of the support-library, Up is part of the Android platform. That's probably the reason why both is located at the same spot. There was no other "reserved" place to put it (and users new it should be there from other apps).

By the way: I don't think your use case is a quite common. I guess that users normally don't want to navigate from app details to "my apps". However, you can still access the Navigation Drawer by pulling it out from the side. There is unfortunately no way for the user to discover this feature (except trying).

Answer 2

You need to define why this pattern is a "bad experience" for your app.

Whether the pattern you are talking about is a good fit for your application depends on the information architecture you are creating. Understand the IA for your app and content then understand which patterns work well for your chosen organisational structure.

Many content based apps and websites use a fairly straight forward heirachical IA where hub and spoke navigation makes a lot of sense and is highly usable. The pattern you describe appears to be a good fit for hub and spoke navigation on a mobile screen.

Why does it work well? The old-school model of Information Scent is still very valid http://www2.parc.com/istl/groups/uir/publications/items/UIR-2001-07-Chi-CHI2001-InfoScentModel.pdf

The basic idea is that users searching for a peice of information will keep going forwards as long as they appear to be getting close to their aims (ie. there the information scent is getting stronger). When they choose a path that gets them further from their aims (lower information scent) they back up a bit to the last fork in the path and try a different route. User's rarely want to go right back to the start an begin their foraging again. (Unless they give up or complete their task and want to do another task).

The Android pattern used with the appropriate information structures provides a very good experience. Used with inappropriate information it'll provide a bad experience.

Define your information architecture, understand how users will consumer your content then choose an appropriate navigation mechanism that supports both.

(See also: Berry Picking http://en.wikipedia.org/wiki/Cognitive_models_of_information_retrieval#Berrypicking It's another great concept to help explain browsing behaviour.)