Ajax use patterns - QuirksBlog

Well, my previous entry Is asynchronous communication really being used? has certainly elicited some interesting comments. The answer was a resounding "Yes"; and the replies allow me to take a first stab at defining a few Ajax use patterns.

Sending data to the server

About 80% of the comments pointed out is that Ajax is excellently suited for sending data back to the server without refreshing the page. Digg, Gmail's save-in-background feature, and several applications that allow the user to save data were mentioned.

Not having to wait for a ponderous page refresh after you've saved something is a clear-cut interaction advantage of asynchronous communication. As far as I can see this is the most important Ajax use pattern of the moment.

The save action doesn't need new data from the server: the request just sends a command that the server must obey. Therefore there is no real response that changes the page the user is viewing—well, maybe a check mark or something, but nothing vital.

Refreshing data

The second Ajax use pattern is exactly the reverse: refreshing data independent of user actions. The example given was of a complicated fleet tracking system that was updated every once in a while so that people could monitor vehicle locations. The application automatically fetches data from the server (presumably with a fixed interval).

Although one might argue that this doesn't really constitute interaction—the new data is received whether the user takes action or not—it nonetheless uses asynchronous scripting to excellent effect: only one single data set is refreshed instead of the entire page.

Moving bits of text

Two more examples are chat apps and Google Suggest. Right now I have the feeling that they are aspects of the same use pattern, but since I can't yet define that pattern better than "moving bits of text around" you should feel free to disagree.

An Ajax chat application allows people to type messages while sending their earlier messages to the server and/or receiving new messages. Although this is a valid example of the benefits of Ajax, I'd like to point out that chat apps have always worked like this, and that Ajax only allows us to switch from an applet to JavaScript.

Google Suggest sends a request as soon as the user has typed in a few letters, and as far as I'm concerned this is the (as yet single) example of Ajax as I always supposed it would work: quietly but incessantly refreshing the page content based on repeated user actions; and the user can continue to take actions while the requests are running.

The similarity is that both applications work with tiny bits of text. The technical advantage is obvious: tiny bits of texts are downloaded speedily. I'm not quite sure of the interaction implications, though. Are such applications restricted to moving small texts because that's all the user can handle? Or has the application that uses this pattern to greater effect not yet been written?

New "pages"

The fourth use pattern is the use of Ajax to download new data and show the data in the page. Although it's quite popular nowadays, and it can have subtle advantages, it's necessary to point out that this use pattern doesn't differ fundamentally from just fetching new pages from the server by a standard HTTP request.

Sure, Ajax gives you more opportunities of seamlessly integrating the new data into your pages, but essentially the user sends a request and waits for the response before initiating a new action. Using frames creates essentially the same interaction pattern: content is updated, but main interface stays where it is.

In the end this will likely turn out to be the least interesting Ajax use pattern.

Conclusion

Can anyone think of other Ajax use patterns? Can anyone say something useful about the third pattern?

Comments

1 Posted by Jesse Skinner on 12 June 2006 | Permalink

I think what you mean by "Moving bits of text" is really a combination of the first two patterns. In both chatting and Google Suggest, Ajax is used to send something to the server (what the user is typing) and refresh the page (what others are typing or google suggestions).

I expect all patterns will involve some combination of the first two patterns, actually.

2 Posted by Shawn Lauriat on 12 June 2006 | Permalink

Not entirely certain of how to word this concisely and still coherently, but here goes: performing actions otherwise impossible by the client alone.

For example: if you want someone to enter an LDAP/FTP/IMAP/etc server's information you would want to test the connection before saving the data. Rather than using pattern 3 (which would hit the server way too much), provide a button or some other widget for the user to initiate server-side parsing and testing of the data provided before it gets saved and implemented.

3 Posted by David on 12 June 2006 | Permalink

Another thing I've used AJAX for that doesn't fit any of these patterns is retrieving data based on user input. Specifically, I've designed a customer-selection page; to load the entire customer list would be prohibitively slow, so the user selects criteria from different categories. Once the categories are sufficiently narrowed, an AJAX request grabs the smaller list of customers from the database and populates the select box. (There is, of course, an option to get the entire list, but if the user hits that, that's their own look out.) Of course, this doesn't require asyncronicity, but it's a smoother user experience than a series of forms would be.

4 Posted by ppk on 12 June 2006 | Permalink

Found this page:
http://ajaxpatterns.org/Patterns

This site tends to concentrate on technical and "low-level" interaction patterns like Highlight, Popup, and Data Grid.

Very interesting stuff, but right now I'm looking for more high-level, user-centered patterns.

5 Posted by Aaron Barker on 12 June 2006 | Permalink

Kind of along the lines of what David said above, many of the Google Map (or yahoo, or live) mashups refresh based on the user dragging the map around.

Instead of loading up the thousands of potential locations (point of interest or whatever the mashup is about) all at once, they only get the most recent XX entries from in the viewable area or the like. So you get a constant refreshing of data, but based on user interaction, not a set interval.

A great example is http://www.placeopedia.com/ where you see only the most recent 15 entries in your viewable area. As you zoom, or move around, it refreshes both the map and the list on the right side, as well as telling you how many are not shown (due to the 15 most recent limit).

6 Posted by Derek on 12 June 2006 | Permalink

Don't know if anyone mentioned this already. It's the AJAX replacement for the poorly supported "blink" tag.
http://cheese.blartwendo.com/web21-demo.html

7 Posted by Nadav Hareven on 12 June 2006 | Permalink

Shawn Lauriat (number 2) -
I think you misunderstood pattern no. 3:
It doesn't neccessarily mean sending every letter to the server, but rather sending something to it and receiving a response. What you want is exactly that - sending the server info, and receiving a "yes" or "no".

8 Posted by crusty on 12 June 2006 | Permalink

shawn lariat - how exactly do i query the vaibility of an IMAP connection with ajax? you are assuming that the same server that provides an alternate service also is listening on port 80.

ajax is useful for what it states - asynchronous connections to a server. beyond that its probably time to start thinking of other tools and protocols. in my opinion the web stack is hitting its limits.

9 Posted by Tanny O'Haley on 12 June 2006 | Permalink

I use pattern three to validate data that the user has input and pull data in response to user input. AJAX makes it easier to implement a "Windows" style application on the web where the application responds with "tiny bits of text" in response to user input.

I'm just not sure how this pans out from an accessibility point of view. A user enters a key field that has to be unique. AJAX is used to validate with the server that the key field (email address) is unique. The server returns a boolean response, the web page tells the user to re-enter or allows them to continue. This method absolutely does not work without javascript! However making the user post the whole form and returning an error is not an available option because of load. This is not an asynchronous operation since it determines if the user can go on with the form, it is synchronous.

An onsubmit handler and AJAX allow me to do local and server field validation. Again this requires a synchronous response as the onsubmit handler has to return a true or false value depending on whether or not the data should be submitted to a server.

Any links or information on a better way to do this would be helpful.

10 Posted by crusty on 12 June 2006 | Permalink

tanny - your point is something that has been brought up many times. the ajax folks refuse to deal with synchronous connections because they fear deadlock. yet javascript is incapable of dealing with threads from asynchronous calls in a way that lets the user avoid writing spaghetti code in callbacks.

narrative javascript (search for it, you'll find it) is one approach to this, but so far its just an exercise.

to properly address these issues, javascript needs features like continuations and preferrably coroutines. since it won't be getting these features any time soon, you are limited to debugging spaghetti code or working outside the web stack (i.e. embedding network connectivity in an otherwise more featureful app). this isn't as crazy as it sounds, between bittorrent, world or warcraft etc, its likely already that a substantive amount of internet traffic is outside of the web stack, and this will only grow.

11 Posted by Joost Diepenmaat on 12 June 2006 | Permalink

@Tanny, you could do:

onsubmit: call the (asynchronous) validation code and return false.

in the callback: if the email adress is valid, submit the form via javascript, otherwise, notify the user that the email isn't valid.

12 Posted by Richard York on 13 June 2006 | Permalink

Along the lines of what David said, I've used AJAX in the past for form auto-completion. For instance, type in a US zip code, and the city, and state are filled in for you. I also use AJAX for real time searching a la Mac OS X spotlight, that is to say a search that constantly updates as you type, but maybe that fits in with #4.

13 Posted by Shawn Lauriat on 13 June 2006 | Permalink

Nadav: good point.
crusty: I intended for server-side scripting to do the actual test.

14 Posted by Marc van den Dobbelsteen on 14 June 2006 | Permalink

How about?
- integrating 3rd party webservices.
- Webharvesting...

15 Posted by Alex Lein on 14 June 2006 | Permalink

I can only think one other, but mostly I think there will be only 3 usages in web-apps. Your 3 and 4 are really different implementations of the same principle, only the scale/frequency has changed.

The only other use pattern I might suggest is that of using an XHR to update environmental variables. The request requires a response but doesn't change the page in any way. The response only updates JavaScript objects or variables (perhaps with the use of JSON).

16 Posted by Nico on 15 June 2006 | Permalink

Again along the lines of Google Maps, I use AJAX to give people the option of navigating massive amounts of data, but only download from the server the small chunk they want to view at that moment.

One example of this is selecting a file from a filesystem (real or imaginary) on the server. The filesystem could have many thousands of files, so downloading the whole directory tree would be bad. With AJAX you can download the files from one directory at a time, as you expand/collapse a tree menu to find the file you want.

17 Posted by Josh Keele on 16 June 2006 | Permalink

You are overlooking the most obvious use: page loading progressively. Say you have a page where the user fills in a work order, and you need a select dropdown with HUNDREDS of options. You write a jsp to pull the options from sql and combine into a select, but if you use a simple serverside include to put that on your page, the user will be staring at a blue line going across his status bar for a long time before seeing ANYTHING on the page, so he may get impatient and think the site is down. If, on the other hand, you send him the page and then have the client code send an AJAX request to the jsp that creates the select list and places it in a div, the user is able to see something immediately and he gets a message "loading list" until ajax returns, so he knows the list is loading.

18 Posted by Duncan Kenzie on 20 June 2006 | Permalink

Along the lines of the last post- we use AJAX for building document trees, similar to a Windows Explorer tree. Instead of having to load every single node each time (which might be 2,000+ folders/docs) we load only the highest 2 levels of the tree. Then, as the user clicks on folders to drill down, we do AJAX requests to the server to expand those nodes. Another use is drag and drop page design - something Google is already using in their personalized page application. This involves letting the user drag portlets, or pieces of a page, anywhere they like to reorganize page content. As the user releases the mouse button, an AJAX call is made to update the server database to provide persistence for the new page layout.

19 Posted by Zukoff on 20 June 2006 | Permalink

I've created unlimited file uploads from one interface from ajax. It was useful, when uploading pictures to gallery. Looks like file downloader in Firefox and can retry upload if failed, shows progress bar.

20 Posted by blahblah on 23 June 2006 | Permalink

Talk about the saving data using ajax, did anyone have problem when sending data back to the server. Using typical http request I had no problem saving all characters entered by the user but when using xmlhttp request seems like there is certain limitation of bytes I can send with the request.

21 Posted by Bill Cash on 27 June 2006 | Permalink

More about GIS mapping and NOT Google Maps. I have built web applications that allow users to turn on and off the various data layers inside map images (highways, streets, cities, parks, forests, airports), and also to perform operations like zooming and panning. Drawing map images is a very costly operation because of the extreme complexity of the data -- huge database size, antialiasing, and labeling are just three of the issues. One reason Google Maps works so fast is that they have pre-drawn all these tiles, but the user cannot change things like having infinite levels of zoom or exactly what appears in the image or is labeled on the image. My application, however, does permit these things, even though they can be slow.

So: AJAX is used so that the user can perform multiple changes to the map image at the same time. For example, turning on highways, turning on rivers, turning on city labels, and zooming in to a particular area are all separate operations, and rather than waiting for each image to come back before performing the next operation, AJAX is used to permit the user to see "a little bit" of the changes at a time. That way the map feels faster.