In the jaded world of Web browsing, few things surprise anymore. From fast lookups to streaming video, the bar keeps getting raised. Which is why Google Maps (maps.google.com) is so startling. Google didn't invent mapping software, any more than it invented the search engine. But in both cases, it has done a superb job of re-inventing them.

Enter "Anaheim" on the Google Maps site and a street map comes up. Drag the map southward-it scrolls smoothly-to Harbour Blvd and Ball Rd. Then zoom in-the map refreshes quickly while the control lever stays fixed to the screen. There, you can see the blank space occupied by Disneyland. Click on the "satellite" button and the map is replaced with an image taken from space, with Main Street, Space Mountain, and the trees of the Jungleland ride all clearly visible. Click on the "Hybrid" button and the names of the nearby Santa Ana Freeway and S. Disneyland Drive are superimposed. Disneyland provides a good working demonstration of Google Maps because for many people, it is terra cognita-known terrain. But you can do this for just about anywhere in the U.S., from the skyscrapers in Manhattan to Mono Lake on the eastern side of Yosemite. Inevitably, Americans trying out the site search on their address. I can just make out the rooftop of my house, surrounded by trees, as well as the reservoir about an hour's walk over the ridge.

What is striking about Google Maps is not just the clean design-you can pretty much figure out how to use this by just clicking away-but the lack of page refreshes. This is a Web application with the look and feel of one residing on a CDROM. The secret is a set of development tools that have come to be known as Ajax, a term coined by Jesse James Garrettt of Adaptive Path, a San Francisco Web design firm. Garrett defined Ajax as a combination of tools: * XHTML markup language and CSS stylesheet language for presentation

• The Document Object Model for dynamic display and interaction
• XML and XSLT for data interchange and manipulation
• XMLHttpRequest for asynchronous data retrieval using
• And the JavaScript programming language.

(The term Ajax stands for "Asynchronous JavaScript + XML." Garrett wrote that he was looking for "something shorter than "Asynchronous JavaScript+CSS+DOM+XMLHttpRequest'" when discussing the approach with clients.)

This combination of technologies essentially creates a middle layer-Garrett calls it an "Ajax engine"-which mediates between the user and the server. Whereas the traditional synchronous model resembles a sine curve, alternating between user activity and server response, the Ajax asynchronous model disassociates the two. The user issues a series of requests and the engine engages the server on the user's behalf.

"Every user action that normally would generate an HTTP request takes the form of a JavaScript call to the Ajax engine instead," Garrett writes. "Any response to a user action that doesn't require a trip back to the server-such as simple data validation, editing data in memory, and even some navigation-the engine handles on its own. If the engine needs something from the server in order to respond-if it's submitting data for processing, loading additional interface code, or retrieving new data-the engine makes those requests asynchronously, usually using XML, without stalling a user's interaction with the application."

Applications developed with the Ajax approach include Orkut-Google's social network- Google Groups, Google Suggest and, of course, Google Maps. Flickr, the massive database of user-contributed images, is another Ajax application, as is Amazon's A9 search facility.

Ajax patterns

On his Ajax Patterns website, freelance programmer Michael Mahemoff characterizes Ajax-developed applications as having a continuous feel, with real-time updates without the page reloads of conventional Web applications, as well as a responsive, informative GUI more characteristic of an online application. He notes that Ajax technology is not proprietary, requires no plug-in, and is not browser-specific, assuming the browser has been updated over the past four years or so.

"Google's triad of projects-Suggest, Maps, and Gmail-is really what captured everyone's attention," Mahemoff wrote in an email correspondence. He says that the Oddpost mail client and news aggregator was an early example of the Ajax technologies at work. Developed in late 2000, Oddpost and Oddpost.com were acquired by Yahoo in 2004. The combination of "the Web, the DOM, and the asynchronous calls make for quite a different paradigm than what most people are used to. It's not especially difficult (though some feel that way), but it's definitely different. Now that these technologies are being combined, there's a lot of experimentation and monitoring going on to see how to best achieve it."

One such effort is Mahemoff's own Ajax Pattern site, AjaxPatterns.org. In his blog, Mahemoff writes that Ajax "is no magic bullet. Careful design is always required, and it must be based specifically on the technology at hand. As Ajax emerges, we're going to learn more about what sort of design works, and we'll need ways of documenting this information and talking about it."

Ajax applications: from Sabre to Amazon

Sabre Airline Solutions-which licenses a portfolio of 60 applications to 225 airline customers-has used Ajax to build LiveGrid, which puts large sets of data into a window, saving users from having to continually request additional pages. In the process, it created an open source JavaScript library called Rico with "full Ajax support, drag and drop management, a cinematic effects library and a growing set of rich Ajax enabled behaviors."

LiveGrid raised eyebrows at the O'Reilly/Adaptive Path Ajax Summit last May. Tom Foremski wrote on his SiliconValleyWatcher.com blog: "Ironically, one of the most impressive demos was not from the Web 2.0 companies, but from Sabre, the travel reservations company, which demonstrated an Excel-like data grid holding hundreds of thousands of rows being browsed and sorted in real time."

Sabre developers have cited several advantages to LiveGrid: the interface is familiar, easy to use, with the ability to show users how much data they are viewing compared with the complete data set. Users don't have to configure how much data they want to see on a page. They just scroll. The developers also candidly noted a few drawbacks: two scrollbars-around the window and the page itself, and limits to scrolling if the data gets too large.

Why did the development team use Ajax? One reason was software compatibility. "We had put a certain amount of investment into a standard GUI framework that we could utilize across our applications," says David Endicott, Sabre Airline Solutions' vice president of airline products development. "For us, Flash would have involved re-working some of that, and I didn't want to go through a bunch of re-works. Ajax fit very naturally into that approach. With some of the Ajax components, we literally dropped them into our framework and got instant results."

Development team member Darren James says that Ajax "seemed to be a natural fit in terms of being a ubiquitous, native solution that doesn't require plug-in installations." Another advantage of Ajax is that it's not particular about the technology on the server side. "The back end can be Java-based, it can be .NET or PHP-it doesn't matter from an Ajax perspective. As long as the request comes back that meets the requirements of what the client expects, it doesn't matter what's on the other side. The nice thing about Ajax is that it doesn't care." I asked him whether Java applets could provide this kind of functionality. James dismissed the idea. "I think applets were ahead of their time, but they were heavy and clunky, took a long time to download and never caught on."

Another company using Ajax is Amazon. "In the past, browser applications have always been about filling out and submitting forms-then getting a whole new page back," wrote Amazon spokesperson Drew Herdener in an email correspondence that summarized the thoughts of Amazon developers. That's inefficient because there's a lot of repetitive information that gets retransmitted each time. "Ajax applications provide a more responsive user experience by enabling more frequent, finer grained interactions. It lets the application track the user's expressed intentions much more closely."

An example is the Amazon diamond search page, which displays six characteristics for the gem-shape, price, carat, cut, color and clarity, each with a sliding lever. The first has checkboxes, the others, sliders-and as you move them, the system keeps searching for diamonds that meet the criteria. "Move a slider and see the effect," Herdener says. "Click a check box and see more details immediately. Overall, everything feels faster because your interaction loop with the server is so much tighter." Amazon developers view Ajax as a return, of sorts, to client-server development, "only the client is implemented in JavaScript, screen rendering is done by manipulating the HTML Document Object Model, and requests to the server are done using HTTP requests. The XML part is not, strictly speaking, necessary," Herdener says.

The RIA alternative: Macromedia

Ajax is a member of a broader class of Web programs known as "rich internet applications," or RIAs. Macromedia first introduced the term in 2002 and remains a principal champion of the concept. Jeff Whatcott, Macromedia vice president of product management, says thatMacromedia's Flash Platform and Ajax have a lot in common. Both take advantage of asynchronous communications, requesting data in the background as needed. "That gives the user a more intuitive experience, where you don't feel like you're jumping from page to page to page," Whatcott says. Both also use flavors of JavaScript for procedural scripting, and both use XML as a format for encoding data as it is transported. "We also support more sophisticated data encoding methods, like SOAP and AMF," he says, referring to Macromedia's proprietary Action Message Format, as well as the Real Time Messaging Format (RTMF), a Macromedia protocol useful for moving streams of data such as stock quotes and Webcam images.

The Flash Platform is the core runtime of the Flash Player, Macromedia's widely propagated plug-in "that is on 98 percent of all desktops and is binary compatible across all of them regardless of browser or operating system," says Whatcott. "The challenge with Ajax is that it really doesn't have a 'mommy.' There isn't a standards body or a vendor that defines the runtime environment. Ajax is really a way of using the capabilities that are somewhat common across many browsers, and so by definition it is limited to the lowest common denominator in browser technology." Unless a programming feature is supported by most browsers, developers can't implement it without effectively excluding some users. "So if the latest version of a browser implements, say, binary SOAP, you still can't take advantage of that until most browsers on most desktops also support it." Whatcott argues that even with its all its resources, Microsoft took about four years for version 6 of Internet Explorer to reach 80 percent market share, whereas Macromedia's new Flash Player reached 80 percent in just 12 months. He says that the smaller download size accounts for the difference.

"If you just want to eliminate page refreshes, Ajax is great. But if you want to, say, blend audio and video into an integrated canvas, the Flash Platform has far more capabilities-because those capabilities are built in. Can you have video on the browser? Sure-but it's an island of video, not interactive." Another Ajax disadvantage, says Whatcott: no integrated development tool comparable to Macromedia's FlexBuilder or Flash authoring tool. "As developers dig themselves into Ajax, they're going want things they can't have. That will lead them straight to our doorstep. But at the same time, there will be a lot of Ajax development out there."

Indeed, there will be. The question for programmers building RIA applications is whether the "lowest common denominator" is good enough for what they are trying to accomplish. Is the difference enough to matter? At this writing, none of the three applications linked on Macromedia's RIA page clearly demonstrate the Flash Platform's advantages over Ajax-at least from a user's point of view. Meanwhile, some Ajax proponents argue that the disadvantages of requiring a proprietary plug-in often outweigh the advantages. And while some programmers say that Ajax technologies can be difficult to work with, the group as a whole seems unconcerned about not having a central organization behind the technologies. The fact that these technologies are non-proprietary is key. Ajax also has something else in its court: Google's showcase applications. The Flash Platform has nothing so highly visible. This may be more about perception than substance: Google has a lot of programming resources at its disposal, and what works at Google Labs may be less practical elsewhere. Even so, perception counts.

Sidebar: Some Ajax Design Principles From Michael Mahemoff

Programmer Michael Mahemoff's website, AjaxPatterns.org, documents a set of Ajax design patterns-high-level descriptions for solving problems. He also suggests a set of design principles (reprinted here with permission) that were heavily influenced by Thomas Baekdal's Ajax Usability Guidelines:

Minimal Traffic:

Minimize traffic between browser and server so that the user feels the application is responsive.

Explicitly Ajax:

Be clear on the interaction mode being used - regular HTML versus Ajax versus desktop application so that the user can predict what will happen next.

No Distractions:

Avoid distractions such as gratuitous animations so that the user can focus on the important things.

Established Conventions:

While avoiding confusion, borrow from conventions of HTML and desktop applications so that the user can rapidly learn how to use your application.

Continuous Interaction:

Stick with Ajax wherever possible - just say no to entire page downloads so that the user's experience is consistent.

Mahemoff also stresses usability over flashy graphics for their own sake. He warns against driving the user away through "website splash screens, blink tags, popup ads, and other usability disasters of websites which have gone to a place you don't want to be. The user's time should be spent thinking about the task at hand rather than the intricacies of the interface."

Sidebar: A Conversation with Jesse James Garrettt

Jesse James Garrettt is the director of user experience strategy and a founding partner at Adaptive Path, a San Francisco Web design firm. His latest book, The Elements of User Experience, was published in Japan earlier this year. Garrettt coined the term "Ajax" in a February 2005 essay: "Ajax: A New Approach to Web Applications."

What got you interested in this combination of technologies?

We kept getting clients who wanted Web applications that were rich, dynamic and responsive, but not done in [Macromedia] Flash. At the time, the mainstream thinking was that you were just out of luck. But then there was Gmail-a Web application in which you didn't have to wait for page refreshes every time you performed an action. That is really the big advantage of Gmail over previous-generation web-based email applications. Gmail demonstrated that you could have an application with the same kind of responsive interface as a Flash or desktop application, but using native browser technologies.

When you look at the Ajax technologies, what was the turning point that made them so useful in combination?

You can't describe it as a sudden transformation. It has been more gradual. A lot of Ajax-style features were implemented in applications several years ago. But Gmail was the first application to demonstrate that you could build an entire application this way-not just a single feature. Over the past five years, we've seen a gradually increasing maturity and sophistication in each of these technologies. That "Ajax moment" for the industry was when these different technologies reached maturity. Now, something is possible that wasn't really possible before.

Why didn't your clients want to use Flash?

There were several things. One was the plug-in issue, although Macromedia will argue that their plug-in has as broad a market penetration as the most popular browsers. However, when something does go wrong with the plug-in, which does happen sometimes, nobody knows what to do. There is no clear course of action for somebody whose Flash plug-in doesn't work.

What do you mean by "goes wrong?"

Sometimes Flash content simply doesn't display because the plug-in itself has gotten misconfigured or corrupted in some way. That is a much more likely case than that of somebody who never had Flash installed on their machine.

You have said Adaptive Path still uses Macromedia. When do you use which?

We're still discovering the boundaries. I would favor Flash in any situation where you had to do any substantial data visualization or where you needed to do a lot of direct manipulation of data. That's the kind of thing that Flash is very well suited for and is difficult or impossible to do with an Ajax application.

How does Ajax compare with Java applets?

They are both solutions to essentially the same problem: how do we create a rich, dynamic experience for the users in an interface that's delivered over a network. There have been a variety of different solutions to the problem. Java applets are one of the earliest solutions. Ajax is another form of an RIA. It's a browser-native RIA.

Some have called Java applets "clunky, heavy" Do you agree?

Yes. The amount of data that has to be pushed to the client for a minimal Java applet is pretty substantial-whereas with Ajax, and to a lesser extent, Flash applications, can push a little bit of data to the client to get the application started and then push other data down later as is needed. With Java, you had to load the whole thing at once at the beginning of the session. As you wait for all that Java code to download, you wind up staring at the blank gray box in your browser window where the Java applet is eventually going to fill in.

Michael Mahemoff, who runs the website Ajax Patterns, has a list of design principles that emphasize simplicity. Does that resonate for you?

It does. One of the things that made the Web so successful is that what you learn from the first Website you encounter can be applied to the next. You learn from the medium as you use it. That's not so true with Ajax because a lot of Ajax functionality is custom-developed for the application. That means the user doesn't have the conventions of the rest of the Web to rely on. What we really need are new conventions, ways of communicating. People are so used to clicking a button and seeing the page refresh as an indication that something is happening. If we don't have that as a way of communicating to the user, we need some new convention that's going to serve that purpose.

Is Ajax in need of some kind of consortium or standards body?

I don't think a standards body is especially needed here. Ajax is in the hands of the Web development community now, and I don't see a significant risk of the kinds of problems that sometimes come about when a technology is not standardized.

So the O'Reilly/Adaptive Path Ajax Summit was more about showing the state of the art than the state of the standards.

Yes, it was about bringing the community together and getting people talking to each other. One of the many remarkable and unexpected consequences of my essay was that people started coming out of the woodwork, sending me emails saying: "Hey, I've been doing this kind of stuff. I didn't have a name for it before, but I've been working on some stuff along these lines too." We thought it would be great if we could bring these people together who had all been working in isolation on these very similar problems, letting them exchange ideas, show off what they've been doing and bounce ideas off one another. We've seen a lot of community momentum coming out of that event.

Your essay on Ajax was good demonstration of how an idea can be accelerated by the Internet. You invent a term, and suddenly there's a whole movement behind it.

Yes, but anybody who thinks that something like this can be planned is underestimating the challenges involved. This was a fortunate combination of circumstances. I don't think this wave of interest in ideas is something that can be engineered. It was more a matter of making a statement at precisely the time that people were ready to hear it.