The Bad Old Days, or, I Walked a Hundred Miles to School, in the Snow, and It Was Uphill Both Ways

Back in the late '90s, people started to use the term "Dynamic HTML," often shortened to DHTML, to describe the use of JavaScript to manipulate HTML in the browser. Basic DHTML meant rollover images that changed state when you moused over them or drop-down menus that cascaded down from the top navigation. More complex DHTML concepts included dragging-and-dropping objects, hiding and revealing content, and even whole games built purely from HTML, images, and JavaScript.

The problem with DHTML, of course, was that it was tremendously hard to do. More accurately, it was tremendously hard to do well in a cost-effective way. It was certainly possible to do some of the simpler functions (drop-down menus, mouseovers) in a reliable cross-browser, cross-platform way. But anything more complicated than that quickly ran into the problem of alternate browser implementations: for example, using the "layer" tag for Netscape 4, but the "iframe" for Internet Explorer and newer Netscape/Mozilla browsers. Similarly, Internet Explorer 5.x and later supported document.getElementByID() as did the Mozilla-based browsers, but Internet Explorer 4.x relied on document.all, and Netscape 4.x on document.layers.

The whole experience got confusing rather quickly, leading to a number of different alternatives.

Many individuals coded applications or sites directly to a single browser, leading to the phenomenon of "Best Viewed in..." badges on sites. (I thought this behavior had gone the way of the "blink" tag, but Wal-Mart's recent digital download site exhibited similar behavior - for several weeks following the launch, the site greeted Firefox visitors with an apology: "We're sorry. Our Web site requires the browser Internet Explorer version 6 or higher. It appears that you're using Firefox, Safari, or another browser that Wal-Mart Video Downloads doesn't currently support." In early March, however, it appeared that the problems had been rectified.)

Some JavaScript developers learned to create applications with a series of if-then statements pointing to specific versions for specific browsers, replicating the functionality in each major "supported" browser. Sometimes this led to unanticipated results, as when the tests were too specific (looking for a particular version of a particular browser) they often broke when new browsers were released. (Smarter developers learned to test for specific functionality, rather than looking for a particular browser version - but this could still lead to a number of code branches for different browser levels.)

Some Web designers found an alternative in Flash. Flash enabled designers to create animation, use sound, and create interactivity on the page without having to worry about browser versions and platforms. Because Macromedia (now Adobe) is the sole supplier of the Flash plug-in, it can offer complete control over the experience for both developers and users. Designers who resisted the urge to create monster intro movies and used Flash judiciously as a supplement to an HTML page, rather than as a replacement for it, found great power in the ability to add interactive elements and animation without having to decipher the complexities of DHTML. (A number of these first-generation Web designers abused Flash's power, creating unnecessary animation, breaking the very interface conventions new Web users so desperately needed, and sticking "introduction" movies in front of Web pages, leading to the birth of the infamous "Skip Intro" button. See www.skipintro.nl/skipintro/ for a humorous version of the problem.)

Finally, a significant number of information architects and Web designers simply learned to avoid DHTML altogether, or at least to avoid any of the "more complicated" functions. I remember seeing statements of work for Web development that either specifically excluded anything but the most basic DHTML or noted that DHTML use would increase risk and cost. If you didn't have the right JavaScript- and browser-savvy resources as part of your Web team, it was undoubtedly safer simply to stay away.

None of these approaches, of course, solved the core problem, or provided a repeatable, cost-effective (in terms of development and debugging time), standards-based, plug-in independent, cross-browser solution to browser-side interactivity.

There's Got to Be a Better Way: AJAX
The solution, as readers of this publication undoubtedly recognize, came in the form of AJAX. As I've written in an earlier article in these pages, Jesse James Garrett's essay became such a pervasive meme precisely because it appeared to cut the Gordian knot that had long plagued Web development using JavaScript. What Garrett's "AJAX" did was to give a name to a series of approaches that had been many years in the works:

As the user base of the old Netscape 4.x applications waned, and the availability of new platforms rose, developers were emboldened by the relative ease of developing cross-browser standard applications with rich interaction in JavaScript and CSS, more and more developers started to create AJAX applications. Garrett's essay crystallized this movement and gave it a name.

While Garrett referred directly to the use of Asynchronous JavaScript and XML, the name is commonly applied to all kinds of uses of JavaScript for interactivity: some entirely synchronous, and many bypassing XML in favor of data representations like JSON. The point really is that the AJAX label effectively negated the fears associated with DHTML, and signaled to the development and design communities (as well as the customers who write the checks for site development) that it was now possible to build client-side interactivity without immense pain.

Buoyed by the excitement over the Mozilla project, and the relative stability of the Document Object Model (DOM), a number of frameworks emerged to make AJAX-style development easier, abstracting away the plumbing to handle multiple browser implementations and interpretations.

We have to be wary, however, of the assumption that just because developing AJAX-style Web applications has gotten easier, we've gotten better at developing them.

Just as word processing software doesn't (in and of itself) improve one's writing, having access to frameworks that facilitate AJAX-style development has increased the potential for users to develop truly both good usable applications and horrible unusable applications.

How can we avoid the "Skip Intro" phase of AJAX development and move right into the mature, stable, usable application era?

First, Do No Harm: Don't Break the Back Button
It's crucial that while AJAX can make Web applications more like desktop applications, it should not remove the strengths of Web applications in the process or interfere in the fundamental architectures of the Web.

This means, first and foremost, not breaking the conventions of back button use, bookmarking, and link sharing. Granted, these conventions may have different meaning in different applications, but they should be thoughtfully considered and only disrupted for a specific rationale. Full AJAX applications that provide rich interactive functionality but aren't conceptually linked to a page-based interface may not be able to support the conventional use of the back button. If the interface has no notion of pages, and is all in a single HTML page, what sense does the back button make?

For example, Zimbra's Collaboration Suite, a Microsoft Outlook- or Lotus Notes-style e-mail client and calendaring system, doesn't "support" the back button in the sense of allowing the user to click on the browser's "back" button and somehow change the interface to the last viewed page or last entry in the browser history. Because the entire application lives in a single page at a given URL, allowing the "normal" function of the back button would result in jumping back out of the application.

However, Zimbra doesn't simply disable or hide the back button. Instead, the application pops up a confirmation dialogue (the same dialogue is used for other browser-actions that would navigate away, like clicking on a bookmark, or typing a new address in the address bar) as shown in Figure 1.