Navigation on mobile site - menu or back button?

Question

We have a mobile website, which is built as a single page application. We have tried to keep the back button alive by using anchors for different screens (it still feels pretty much like a paged website). Users can for example see a list of messages, go to one message, then go on to see the profile of the user. On the message and profile page instead of a navigation menu theres is only a link/button to "go back" (left arrow), which uses javascript:history.back() in the hope of not breaking the back button too badly.

Now we had the problem that we wanted to link directly (e.g. from mails) to a profile or a message. In this case the back button/link is meaningless, because there is no prior point within the site to go back to. But since there is no always-accessible menu on these pages, the user has nowhere to go.

Now, the question arose how to handle this. Is it better to fake a back location via javascript trickery (injecting a logical target for the back link), or rather do away with this back linking button in favor of a global navigation menu that can be accessed on every page and leave back navigation to the browser back button?

My instinct would be to leave back to the browser controls and have a consistent navigation menu on all pages. I would think having only the back button makes sense only in very select situations where a page doesn't make much sense on its own (like a page in a multi-step wizard). Our UX person argues that with the back linking button it is easier to go back to the list and read the next message (a navigation pattern that is found like this in the iPhone app for example). Having both hits against space constraints.

Are there any best practices I could read up on or point to for this kind of situation?

Answer 1

In my opinion, pages should never ever use Javascript back. Why would I want to click a back button on your page? There is already a browser function for that. I will use that if I want to go back. Links should link to actual places, not Javascript trickery that confuses browser interface with web navigation.

So, I would definitely prefer a menu in this case.

Although, I also think these use cases you are running into raise the question of whether a one page design is appropriate for your site. One page design, in my opinion, works well for flashy advertisement sites that are low on content. Such sites sort of make logical sense as one "page", because you could imagine all of that information displayed in print on one big page, like a poster. If the user scrolls down to read it all, they won't get lost.

Complex sites with multiple levels of content are just going to be confusing and frustrating on a single page. You clearly have a hierarchy going on (list of messages -> individual message), as well as different types of content (messages vs. user profile). What is the benefit of having this all in one big page? What happens if the user actually uses the scroll bar? Won't they wonder "why am I suddenly on my profile?"

Answer 2

Android

I think that Android Guidelines about navigation are an interesting and very useful read.

In particular, I think that it's helpful to refer to the difference between:

The Up button - which is used to navigate within an app based on the hierarchical relationships between screens. For instance, if screen A displays a list of items, and selecting an item leads to screen B (which presents that item in more detail), then screen B should offer an Up button that returns to screen A. If a screen is the topmost one in an app (that is, the app's home), it should not present an Up button.

The system Back button is used to navigate, in reverse chronological order, through the history of screens the user has recently worked with. It is generally based on the temporal relationships between screens, rather than the app's hierarchy.

So:

• When you have a hierarchical relationships between screens (if I've understood correctly, the first case you mentioned) you should use the Up button;
• When you want the users to navigate in reverse chronological order (if I've understood correctly, the second case with the direct linking) you should use the system Back button.

In the guidelines you find additional examples that I think will help you to sort it out.

iOS

iOS Navigation Guidelines distinguish between 3 different app structures:

1. Hierarchical
2. Flat
3. Content- or experience-driven

Depending on the app structure you can choose the navigation pattern that fits best (e.g., navigation bar, tab bar, page control).

More details and examples in the iOS Navigation Guidelines page.

I hope this will help :)

Answer 3

Since you seem to be using anchors already, instead of using a back button you could also implement a button that says "start" or "home" or "top" and let that link to the top of the page. This is less confusing for people that enter the page at a specific anchor point (email-use-case) and would also be js-free.

The button wouldn't have to be implemented on every section – instead you could place that button e.g. in a "sticky footer" or floating on the bottom right corner. (And this approach / this button could also be re-used in the desktop browser layout which can mean less coding would be necessary then in a js-approach.)

In my optinion having the menu (or at least a jump-link to a menu section) available everywhere is always a good idea. But it depends on your site's structure if that is really necessary – or if a "home" button would be enough.