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.
(Update: added a fourth pattern that I've used in several sites.)
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.
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.
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.
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?
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.
So we've encountered four Ajax use patterns:
Can anyone think of other Ajax use patterns? Can anyone say something useful about the third pattern?
I’ll be around at the following conferences:
Comments are closed.