What's the terminology for bad practice around emulating browser functionality in your website?

Question

Background

We've just updated one of our 10-year old web applications and in doing so have removed a "back" and "forward" button on the main menu. Our reasoning behind this change is that the web browser has a back and a forward button, so why duplicate the functionality?

One of the users has mentioned this and asked if they can have the buttons back. I'm torn because I clearly want to keep the users happy, but on the other hand, I'm pretty sure it's bad practice.

Question

Is there some terminology or rule for this bad practice, or a design mantra or something I can quote to the user? I'm looking for something they can look up and read more on if they want.

I'm sure I've heard of something before, possibly related to the general training of users (e.g. if most sites on the internet do something one way, I'd be mad to do it a different way..).

We may well end up adding the buttons back in to appease the user, but I'm now curious...!

Answer 1

I think what you need to realize from your users is that they don't really trust the browsers back-button on a web application. They have tried this behavior at their internet bank, with the result that they got thrown out and needed to sign in again. And at an internet bank, it’s a real obstacle.

That’s why your users want it back – their experience and distrust of browser back-button. There is also a great answer to a related question on the topic: answer to “Is a 'back' button needed on a web form?” where you can read more about it.

Another notion is that you should keep your web site consistent. Then your users won’t have to worry of the change since all the controls they are used to, still are there. You can change style, but have a pretty good reason changing functionality. If the back button works as expected? Sorry, stick with it – as your user said. Listen to what Jacob Nielsen says on “Top 10 Mistakes in Web Design”:

8 Violating Design Conventions

Consistency is one of the most powerful usability principles: when things always behave the same, users don't have to worry about what will happen. Instead, they know what will happen based on earlier experience. Every time you release an apple over Sir Isaac Newton, it will drop on his head. That's good.

If there is a term for bad practice? The only one I can think of is breaking web conventions, which almost always is bad.

Answer 2

Arguments against replicating browser functionality often take the stance that it is better for people to learn how to use the features of their own browser and that, if browsers are too difficult to use, it's not our responsibility as web designers to solve those problems.

The idea behind "teach a man to fish" is that, while you could include lots of these features in your site, the user will have to re-learn how to do those things on every site they visit (and some sites might not include those features at all).

The issue of replicating browser functionality often comes up in discussions around Accessibility, particularly when it comes to the infamous text resize widgets. This article, for example.

There are of course some situations where it does make sense to duplicate browser functionality, for example a back button in a form process. Another prime example is when we might include a 'print' button in a web page. On the face of it that seems unnecessary, but it can be useful in situations where you want to prompt the user to print something important, such as a receipt at the end of a transaction.

Answer 3

Well, you're not really emulating the "back" and "forward" functionality of the browser, are you?

The browser's back button navigates to the previous unique URI requested by the user. The back button of your web app directs the user to... Well, whatever logically is one step "previous" to the current view in your web app. These may overlap, but are virtually never equal in the modern dynamically-generated web-application.

That's why users don't trust the "back" button on their browser; its definition of "back" is very often not the website's definition of "back". When you develop your site, you know what "back" should be. The browser, not so much.

This is kind of a flip of the "principle of least astonishment". When designing a UI (a system in general), it should be designed to maximize the value of the target user's past experience and intuition, and thus minimize the number of "surprises"; UI elements the user thought would perform one task or behave in one way, but instead did something very different. Here, though, the browser's back button is known to users to be a source of astonishment. It is thus a greater surprise to see a web application that trusts the Back button (by being designed so that it functions properly) than to see one that does not trust it and includes "previous" and "next" links in the UI of the page itself.