Back breaking sites

Question

What's the reason that so many site these days "break" my back button experience?

Even stack does this: I read a question expand the comments, scroll to the first answer, follow a link, decide I'm not interested and press back.

At that moment, stack will have unexpanded the comments section and I will land on another place as where I left the site. This is very uneasy because now I have to search again where I had left the page.

There are a lot of other examples I could name, like slashdot.org where you can expand the comments, but when you follow a link and go back, comments become unexpanded and you lose track of where you where.

Also a lot of sites have "integrated forums" like disqus where leaving the site brings you back to the top of the comments if you press back.

What's the reason for these site to implement an imo very bad back-button experience?

Considering, back is the most used button on the browser.

Answer 1

There are three reasons for this behaviour:

1. A lot of new web apps are utilising Javascript MVC frameworks and the concept of the single page app. In this context, in order tot make the sort of behaviour described work you need to use the history API. This is all very new technology and designers, developers and product managers are still getting to grips with it in many cases.

2. It is technically difficult to do. You need to expend time to mimic behaviour that comes out of the box in a simpler, older implementation. The time and money for this might not be available.

3. It is sometimes done for security reasons, for example, while following the steps to transfer money online where the service provider need to keep really tight control over the when and how the data is sent. Again, it is harder to get around security issues the back button might introduce than it is to just disable it

Having said all this, it does go against a pretty fundamental usability guideline, that one shouldn't hijack the back button. A website that really wants a strong user experience and doesn't have any security concerns (read that as all but one in a million) should make the back button work as expected as most users expect this to work.

Answer 2

I think the crux of the issue here is that while web browsers were very good tools for navigating web sites in the past decades, modern web sites work in fundamentally different ways, and the browsers we use are no longer necessarily the best tools for navigating them.

The simplest web site consists of a hierarchy of static documents with hyperlinks between them.

Example:

Home Page
    About Us
    Products
    Contact
    Help

When a user navigates this web site, they would start by requesting the Home Page from the web server. The web server would return an HTML document and other assorted assets that describe the entire Home Page. The user browses that page and clicks the hyperlink for the Products page. The browser sends a request to the web server for that page. When the browser receives the new web page from the web server, it discards the entire Home Page and replaces it with the Products page. If the user decides they want to go back to the Home Page, they can click the Back button. This tells the browser, "Discard whatever page I have open now and put back the page that I was on last."

Let's take a closer look at how web browsers and web servers interact in the example you described.

You click a link on Stack Exchange to view a question. Your web browser sends a request to the Stack Exchange web server requesting the web page for that question. The web server finds the page and returns it to the browser. You scroll down and click to expand a comments section. The browser sends a request to the web server for those comments, but when those comments come back, instead of discarding the current document and replacing it with a new document containing the comments, it just inserts the new comments into the current document in the appropriate place.

If you were to navigate to another page and then click the Back button, your web browser would see that the last document you accessed was the page for the question, but it would not know about any of the modifications you had made to that page (like inserting the new comments).

This is an example of how a web site can behave in a way that is fundamentally different from the way web sites were originally intended to work. Instead of viewing one document at a time, we are actually requesting lots of little fragments of documents and assembling them in the browser.

So what is the reason that so many web sites break the Back button? It is because the Back button works by loading the last page requested from the web server, and many modern web sites are designed using a paradigm where web pages are built dynamically in the browser from fragments of other pages.

Answer 3

As several folks have commented on the question - it's a technical reason.

However, as with most technical reasons, there are technical solutions (in most cases - secure apps are a whole different kettle of fish!). They're probably costly, slow or otherwise nasty in some way, but it's not an impossible problem.

The real reason sites break the back button come down to prioritizing the investment of development effort, and aren't technical at all. Simply put - it tends to be too low a priority to receive effort, or because some of the bad smell (by which I mean things that make developers go "hmm... it works, but it sounds dodgy. don't much like that.") that goes with it is perceived to be worse than the problem.

There are several ways around the back-button issue (as evidenced by sites & browser based intranet tools that don't have the problem), but they cost (time, money, maintainability) to implement and don't really come with a wow factor.

So the reason isn't technical.

Technically it can be worked around. The problem exists because it costs too much to invest time and effort (both in initial creation and in maintaining it) to fix, and so is a way down the queue - possibly far enough that it'll never happen.

A lot of the time it's not considered to be worth that investment, or is perpetually on the "we should fix that someday" list.

To sum up: Fixing it isn't a priority. Other things are priorities. So we'll do other things. In places where that's not the case, it gets fixed.

Answer 4

For most web sites, it is very hard to justify breaking the back-button. Even shopping carts, bank money transfers, etc, can be made idempotent, so refreshing, back, then forward, etc doesn't cause unexpected behaviour.

There are some scenarios where the back-button cannot be supported. For example, I worked on an extremely complex web application a couple of years ago, where fully supporting the back-button, in all scenarios, would have been extremely difficult and perhaps impossible.

Rather than spend a lot of time figuring it all out, it was decided to switch the back-button off. In the end, nobody complained, as the applicatin provided sufficient context-driven navigation that the back-button wasn't missed.

I get that many people would say that you should never mess with the back-button, but for me that's too rigid.