Thursday, January 26th, 2006

Supporting the Back-Button: Tutorial on Dev2Dev

Category: Library, Programming, Usability

<p>Backbase’s Mark Schiefelbein has produced a tutorial on handling the Back-Button with Ajax.
He notes that the well-cited top 10 Ajax applications includes many examples that break standard expectations about the web. “As a direct consequence of the changes in how to use (D)HTML and HTTP, Ajax applications break the back button and other elements of the Web’s fundamental interaction style.”.

He summarises the basic approach, as discussed by Mike Stenhouse (Content with Style) and more recently Brad Neuberg (OnJava).

  1. Create history

    1. Save meaningful state
    2. Generate a corresponding URI
    3. Push the URI onto the browser stack

The state I want to save is every change to the select box. Therefore I’ll create a new URI that includes the select box state information.

To remain compliant with Internet standards, I’ll use the fragment identifier part of the URI. As stated in the IETF RFC 3986, “…Fragment identifiers have a special role in information retrieval systems as the primary form of client-side indirect referencing, < ...> the fragment identifier is separated from the rest of the URI prior to a dereference, and thus the identifying information within the fragment itself is dereferenced solely by the user agent, regardless of the URI scheme….”

Using the fragment identifier, I can create an “Ajax-URI,” composed of a client-side and a server-side part, separated by the hash (“#”) sign.

JavaScript provides the window.location() function to update the browser’s history and address with a URI. In addition, you can directly access the fragment identifier with window.location.hash().

According to the article, Backbase has builtin support for this trick. The framework takes into account subtleties too, such as the way IE ignores the fragment identifier when it comes to the back button (solved via IFrames). This Ajax forum demonstrates the technology.

Related Content:

13 Comments »

Comments feed TrackBack URI

This is what I call “Wrong use of AJAX”

Comment by Guillermo — January 26, 2006

I am not sure of how would that method degrades?

i.e. if you put the “real” location in the fragment portion (after the dash), then this information is only availlable client-side, hence only if javascript is enabled.

what if you bookmark this, deactivate javascript and try to come back? the local information is not transfered to the server => no degradation.

For it to be degradable, the state=location should be stored in a form transferable to the server without javascript.

In deed, in the forum example, why would you store the #forum/forum.html%3Fid=4[1] as a client-side information. It is something equivalent to a server-side information (the notation in deed reflects that).

This back functionality is important, but there is probably a better way to implement that in a “progressive enhancement” way. (see for example domscripting post on that matter)

Comment by Mortimer — January 26, 2006

It’s not without some wry entertainment that it appears that Backbase is *already* “Web3.0″ — they’re re-inventing what we provided in Dojo almost a year ago!

Comment by Alex Russell — January 26, 2006

Yeah, just love how they redirect you to a page that says:


Your web browser is not compatible with the primary Backbase site. Find out which browsers are supported at the Compatible browsers page.

when you try to access the forum. Great idea, you just told me that my browser sucks – here, buy something!

Thanks, but no thanks. There are better ways of playing nice with browsers.

Comment by Alexander Limi — January 26, 2006

But, Jep, if you support both, why do you have separate schemes for the url. Shouldn’t you have one url scheme, working when ajax/javascript is not available and being parsed by the javascript when ajax is on?

I am perhaps wrong, but I do not get the benefit of separating the two?

Comment by Mortimer — January 26, 2006

A single-page interface (loading new data into an existing page) is only possible when JavaScript is enabled, because it depends on the XMLHttpRequest object. The idea of a single-page interface is that the page is not reloaded when new information is displayed, so the URL cannot change, otherwise you get a page reload. Therefore, using the hash (#) is the only way to dynamically add information to the URL.

If JavaScript is switched off, you can only use a multi-page interface. In this case, you need to load a new URL to display new information. Of course, you can still use AJAX features with a multi-page interface, but if you want to use the back-button to navigate between different AJAX states you still need the hash URL approach: this doesn’t degrade, but if you can’t access the AJAX functionality, what is the use of navigating between AJAX states?

So the two approaches are separate, and there’s not much we can do about that: that’s the nature of the Web.

Comment by Jep Castelein — January 26, 2006

The idea of a single-page interface is that the page is not reloaded when new information is displayed, so the URL cannot change, otherwise you get a page reload. Therefore, using the hash (#) is the only way to dynamically add information to the URL.

Yes, you are right, this is the simple fact I was missing. Indeed, if you use the location() method, you will force a reload. So the url has to stay identical.
During a long instant, I was thinking that you were using location() without having the browser reload… but hey, this is not what the function does (but it would be nice if it could).

I finally get it. Thank you for the extensive explanation ,)

Comment by Mortimer — January 26, 2006

From the article: “In the traditional model every page refresh resulted in a URI update” — Not true.

From a comment: “A single-page interface (loading new data into an existing page) is only possible when JavaScript is enabled, because it depends on the XMLHttpRequest object. The idea of a single-page interface is that the page is not reloaded when new information is displayed, so the URL cannot change, otherwise you get a page reload.” — Partially true.

Let’s draw a line between single-load interface and single-address interface. Single-address interface does not have to be single-load. As the article shows, single-load interface does not have to be single-address interface as well.

The fact that browser adds every resource to a history list works well for hyperdocuments but usually a nuisance for web applications. I found a way to get rid of this behavior using redirection. Now Ajax provides it for free, great, use it. Instead if it, people try to reimplement hideous history list in Ajax. Incredible.

Don’t get me wrong, I am all for proper page reload and for navigating back and forth, but only when it makes sense! Say, you have a menu on a webpage. You select one item, than another, then another. Should all three actions be recorded as three locations in history list? Should I click Back three times to leave the page with the menu? Come on, this is ugly.

The same with form submission. If I made five attempts to submit a form, should I click back five times (sorry, six times) to leave the form? Would not it be easier to click only once? Each form submission is not a separate page, it is just an attempt to submit the *same* page.

Sometimes Back button is needed, but not always!

Comment by Michael J. — January 26, 2006

I think that you could create a degradable approach for this. If you have your server side code catch the information after the hash (if it exists) you could probably play with it any way you like whether it be redirection to a compatible page, or printing the correct information to the current page.

If the application developer is going to go through the trouble of implementing a back button functionality, it shouldn’t be that much more work to add in the server side code on the degraded page to deal with such events, especially considering how much effort has to be put into other aspects of the application, such as form submission and processing, in order for those to also be degradable.

Comment by Wesley Walser — January 26, 2006

Unfortunately the hash is not sent to the server, it’s client-only according to the standard.

Comment by Jep Castelein — January 27, 2006

Hi all,
(disclaimer: like Jep, I work for backbase )
@alex: fyi: what dojo delivered almost year ago, flash guys implemented almost 5 years ago.

http://www.robertpenner.com/experiments/flas/backbutton.zip

Also, don’t think it was rocket scince for us to do. Don’t get cocky ;-).

@michael: you have some valid points, but please see also the big picture: nobody says you should record every single click on every menu item; that you could do that is something completely different. (BTW: I believe I “know” you from Intellij scene?)

I think that article Mark provided was just to show how you could implement back button functionality: using selectbox to explain this was maybe bad idea because people are to much picking on it: “why would you want to save selectbox state”. Well, you don’t, imagine it is something else (e.g. a page you loaded). Choice was made to keep article simple and understendable, without to much JS code.
-m.j.milicevic

Comment by m.j.milicevic — January 28, 2006

[...] On a side note, issues surrounding AJAX and related technologies, have just started coming up. One for example is what happens to the Back button? [...]

Pingback by Alt.3form » Blog Archive » AJAX, AHAH, JAH love? — January 29, 2006

[...] Ajaxian » Supporting the Back-Button: Tutorial on Dev2Dev [...]

Pingback by r-echos » Blog Archive » Ajaxian » Supporting the Back-Button: Tutorial on Dev2Dev — February 22, 2006

Leave a comment

You must be logged in to post a comment.