7

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.

5
  • 1
    The comment behaviour is because it's all done on-the-fly with AJAX, and when you go back to the page that data is not there any more. You need to fetch it again. Feb 26, 2015 at 16:27
  • 1
    That is a technical explanation. I am looking for a usability angle. Why would you revert the state, basically to 0-state when you go somewhere else and then back? Would seem much more logical to me to keep the things already as they are, especially because you already downloaded also the things you did with ajax. (btw this considers not only ajax)
    – Pieter B
    Feb 26, 2015 at 17:07
  • 7
    Unfortunately, the answer to "What's the reason...?" is technical. It may be poor UX, but improving the poor behaviour is complicated and technically "expensive" (storing data of previous state which may never be needed). Feb 26, 2015 at 17:11
  • 3
    You asked the reason and the reason is technical. When pages were relatively static back had a good UX. Now that web applications have evolved with more dynamic content back at times does not always line up with UX. On the other side dynamic content is a good UX. Back is a browser feature - that is not a button ON the web page.
    – paparazzo
    Feb 26, 2015 at 18:16
  • I just got access to Atlassian Jira at work and I have to say that in this app, which is a complex, modern web app for managing agile projects, they have implemented the back button perfectly, every time I click it I go back to the last page, perfect! so, it is possible and should be done :-)
    – Toni Leigh
    Mar 5, 2015 at 21:56

4 Answers 4

7

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.

1
  • One thing that got me thinking was if this was a website or a browser "problem".
    – Pieter B
    Mar 5, 2015 at 8:44
3

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.

1
  • 1
    so, for good UX, the developer needs to over-ride this and make the back button work as the user expected :-)
    – Toni Leigh
    Feb 27, 2015 at 13:20
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.

1
  • 1
    which is a shame with something as fundamental to web UX as the back button, i'd question any product manager who had such little time for UX on the web in 2015, they would be making a big mistake
    – Toni Leigh
    Mar 8, 2015 at 20:27
2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.