Custom back button in page

Question

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

What I mean about 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 browser. Why should I add one in the page? User has to learn to use the browser.

My friend thinks that it is a good practice because it gives a better UI and a better UX in 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

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 4

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

Answer 5

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.