Party Like it’s 1997: The Curse of the Back Button

Haven’t you heard? DHTML is cool again. Now, before y’all run out scriptin’ your own little cans of Asynchronous JavaScript + XML , let’s pause for a second and consider these observations:

  1. DHTML has inherent usability issues. These issues are still present to various degrees even in all new, slickest applications. As Scott Isaacs states in his post

    The user-interface issues revolve mostly around history and refresh. (For example – In GMail, navigate around your inbox and either refresh the page or use the back button. In Spaces (IE Users), expand and view comments and hit the back button.  I am willing to wager that what happens is not what you really want).

  2. DHTML usability issues are here to stay. Unless some visionary scripting genius strikes again, they will keep DHTML as an application platform in the category of audacious hacks. Of course, the usability undoubtedly will be sacrificed on the altar of coolness: “What? You can’t click back to the album from a picture on Flickr? Well, boo-hoo! What would you rather have, a clunky extra click or the wholesome goodness of Flickr? Fuggetaboutit!”.

So, what is the nature of these issues that Scott was talking about?

DHTML vs. Usability: The Crash Course

In the typical world of Web, clicking on a link makes the browser fetch request to a Web server and deliver a new page.

At the moment of the click, the page you are on is deemed departed and added to the browser history (so that you can click the back button to return to it later, if you’d like)

DHTML provides the capability to intercept a click and, instead of fetching a new page, stay on the same page and do something with it (like open a menu or unhide a section of the page, or make a creepy clown jump out from the bottom).

At this moment, we are faced with an interesting dilemma: even though we clicked on a link, we haven’t departed the page. So, how should the fact of the click be recorded in browser’s history? Is this just a click or  some kind of weird “virtual“ click? And, if the back button is clicked, what should occur? Should DHTML script recognize this fact and adjust the state of the page accordingly? Should the creepy clown retreat back beneath the bottom of the page?

While there are are various ways to answer these questions, the fact that remains is that browsers were not originally designed to account for that kind of state change. There is no definitive way to detect the event of clicking back button. Heck, you can’t even see where we are in browser history from inside of the page!

The issue was further complicated when the XMLHttpRequest capabilities were introduced. With XMLHttpRequest, clicking on a page may result in content being loaded from the server and added to the page without leaving it.

Naturally, this opened doors for the thinking that maybe the user never needs to leave the page. Glory! Glory! We can build entire Web applications that are based on just one page, which changes its entire appearance using nifty server roundtrips behind the scene. “But… what about my back button?“, asked the ordinary user.

Web Page Paradigm

Developers, I am here to remind you of the Web Page Paradigm, put in words so eloquently by Mark Hurst:

On any given Web page, users will either…

– click something that appears to take them closer
to the fulfillment of their goal,

– or click the Back button on their Web browser.

Now, please repeat after me:

The browser back button is an essential part of user experience and every effort must be made to make it operate flawlessly within your application.

There. Whether you develop DHTML applications as part of your job or just as a hobby, it would not hurt to memorize and stick to the statement above. Feel free to print it out and frame it. Or cross-stitch it. Or put it on a t-shirt (Now, there’s an idea!)

Of course, with the back button comes its buddy, the forward button, which must also work in complete accord with your application. In other words, your application must be “clickable” back and forth transparently, as if the user was visiting the old-fashioned, pre-DHTML pages.

As an extra caveat, consider the bookmarks. In the Web browsing experience, any page can be bookmarked. So, not only your application must be “clickable“, it must also be “bookmarkable“ (I don’t think that’s a real word).

As a person who spent a lot of time working in DHTML trenches and looking on the Web, I have to admit that I know of no application or technique that universally makes any DHTML application adhere to these principles in all major browsers. In my experience, you can only go so far with what we have today. From limitations like the absense of an event model that would allow DHTML to react to history buttons to bugs that disable even a possibility of establishing the correct current location, this  is a tough one.

But I can’t know everything. Maybe — just maybe — there is a workaround or a hack hiding somewhere that brings normalcy to DHTML Usability.

Leave a Reply