Custom back button in page

Question

I had a discussion with a friend about adding a custom back button on every page in a website.

What I mean by a custom back button is a link or a button, that will do just onclick="history.back();".

I think that this is useless and a bad practice, because there is already a built-in back button in the browser. Why should I add one to the page? User has to learn to use the browser.

My friend thinks that it is a good practice because it provides a better UI and a better UX to the user.

Is there any guideline about such things?

Answer 1

I don't think there's any reason to have a back button that does the same thing as the browser's back button. (It's generally safe to assume by this point that your users know how to click back. Just make sure that your site functions in a way that the in-built browser back button will work.)

However, you may want to include an up button, as explained in Android's Design Guidelines. The back button built into Android functions similarly to the back button of a conventional browser, while the up button for each app instead goes to the next higher level of app/site hierarchy.

Answer 2

Generally a button which does the exact same thing as the browser's back button is unnecessary (make sure it works correctly though), but I can imagine some situations for which it could be useful.

1. When your site focuses your user's attention primarily away from the browsers back button
2. When using the browser in full-screen mode.
3. For mobile browsing. (The android back button does not do exactly the same as the browser back button).

So you'll need to study how your users would use your app/website and base your decision onyour findings

Answer 3

Best practice is NOT to use a back button unless it is necessary.

If you are building a "wizard" (the user has entered a next/previous flow), a back/previous button could be desirable.

If the site architecture is very deep and has pages buried within pages that take several steps to navigate to, a "breadcrumb trail" may be more useful than a nondescript "back" button.

You have to ask your friend, what problem is the back button trying to solve?

In all usability studies that I have conducted and observed, users will overwhelmingly select the browser back button - even when an alternative back button is provided.

...

Historically, "Back" buttons were considered good usability because many browser-based applications did not have functional back buttons. In other words, the "Back" button would return the user to some unexpected location or it would throw an error. This led to heavy back button usage, and a lot of misconceptions about back buttons being good usability, when in reality they were a workaround.

In some older products, or products that do intensive db queries, this problem often lives on. For a shiny new product that is architected in such a way that the browser back button works, you should carefully evaluate the need for this extra button - and use it sparingly if at all.

Answer 4

"Back button" is a feature and as with any other application's feature, its usefulness will depend on many details like what is the application doing, who are the users, what other features are there etc.?

To have a constructive judgement, one needs to list all pros and contras, which I will attempt here.

Pros:

• Extra convenience. If placed and displayed right, an in-application Back Button can be more convenient to use. Browser's native buttons are often tiny. Even more important for people with disabilities.

• Customization. An application disigner has the advantage to design a button optimized for the application. A more advanced application can even let users customize their buttons. Browser designer can only make it one-for-all solution.

• Extra functionality. Here only sky is the limit. There is so many ways to make a custom Back Button behave better for user based on current application state, user's data, third party data etc etc.

• Smooth in-application experience. It is always smoother to stay within application. Jumping to Browser's Back Button is fundamentally a switch to another interface breaking this smoothness.

• Crystallising difference of purposes. The purpose of in-application Back Button is to go one step backwards in application. That is, I want to use it when I don't want to leave the application. In contrast, the in-browser Back Button is the one I use to get out of the application. Two very different purposes.

• Reliability. Many applications actually break browser's Back Button behaviour. Then I rather rely on in-application one, where I expect the developers to do better job.

• Lower cost. Yes, designing proper non-breaking behaviour for browser's Back Button can be costly. Think of the in-application routing. Libraries (like Backbone.js for example) have whole new components (Routers) just for that purpose. In contrast, with other buttons in place already, adding one more does not require major change.

Contras:

• Redundancy? Here it really depends on details. Maybe if your desktop is already cluttered with buttons, but then you may need to rethink your design in the first place. But if you only have very few buttons, would adding one more really hurt user experience?

Answer 5

Shouldn't your question be, "How to figure out what the user wants?" You may want to factor in what they're willing to pay you to build as well.

Don't predicate a feature request on the notion that the user just needs to be a better user/have more IT knowledge. Trust me, your competition will gladly cater to their needs. Some people decide what computer to buy based on what is easier to use which in their mind equals better.

We can debate this all day long and get nowhere. Ask the users, but keep in mind:

If you want to put in some custom code, this may be a good feature especially if your website is really an application. Some web apps explicitely tell users not to use the back button.

Is the next generation of browsers going to handle going back in history the same way? When your users upgrade and the back button no longer works, they're going to blame you. You'll try and blame their browser. Be prepared to lose that fight.

Answer 6

If the user is filling in a multi-page form, backward and forward buttons are useful.

If the built in browsers button don't work well (e.g. require resubmitting data) then you should redesign your site to make them work.

Additional back and forward buttons adjacent to your form may have multiple affects:

• Enabling navigation between the steps of the form without moving attention from form

• Showing the user that the back and forward functionality works in your site

• The back and forward buttons can be limited to the scope of the form (e.g. no additional back button except on page 2+) and thus prevent accidental exit from form. This is particularly useful in mobile devices, where too many click on back to cause accidental close of tab/browser

• Make sure these additional buttons do act the same as the browser's otherwise if the user does click on the browser's button, unexpected behavior may occur