Don’t break the back button

One of the golden rules of web development is “Don’t break the back button”.

The back button is one of the first concepts that somebody who is new to the web learns. It gives people the confidence to click on links safe in the knowledge that they can always return to where they were.

Breaking the back button is not a new problem. Jakob Neilsen has been banging on about it for longer than I’ve been using the web.

But, we keep finding new ways to break it.

I wrote recently that this is one of the unsolved problems with applications that use a lot of AJAX. Well, Julien Lecomte from the Yahoo! User Interface team has come up with a possible solution that he’s calling Browser History Manager.

This uses a combination of JavaScript hacks to fool the browser into thinking the page has changed, and so effects what happens when the user clicks the back button. Provided it’s coded smartly it also allows users to bookmark an AJAX page in a specific state, which is nice.

It’s good to see that people are working on this sort of thing, but to me it feels like a very hacky solution.

At what point does the fact we need to fix these sorts of problems cause us to re-consider the whole approach?

Something is happening

Today we added some Ajax-y goodness to the My Favourites page on Trade Me. This makes it much quicker and easier to save your favourite categories, searches and sellers. And on the page itself you can change the email frequency or delete existing favourites without a post back.

All good, and probably well overdue.

One of the lessons we’ve learnt with asynchronous buttons is the importance of an intermediate ‘Saving…’ state.

So, for example, as of today our ‘Save as a favourite search’ button starts out looking like this:

Save as favourite category

When you hover over it glows like this:

Save as favourite category

When you click, it immediately changes to look like this:

Saving

This makes it clear that the click was recorded and that “something is happeningTM“. Then we go ahead and make the asynchronous call to record this change in the database.

Finally, when the asynchronous call returns, we update the button to look like this:

Saved as favourite category

This is a simple thing, and very easy to implement. But, especially for people on slower connections, this can make the difference between understanding what is happening and confusion.

What other tricks are you using in your Ajax-based designs?

I think we’re starting to see some de-facto standards emerge, which is good news for users as all sites will tend to start working in a way that they are familiar with.

But there are still lots of problems which don’t have nice solutions.

For example, pages implemented using Ajax often break the back button. This is a problem as the back button is a concept that even the most novice web user quickly learns and relies on when they follow an incorrect link.

Also, using Ajax can cause the URL displayed in the address bar to get out of synch with the content displayed on the page. This makes it difficult to bookmark or link to the page. If you are relying on word-of-mouth to market your site then making it difficult for people to tell their friends (e.g. by sending them a link in an email) could be fatal.

A community site which documents these sort of simple common Ajax design patterns would be really useful. Is anything like this already out there?