Yesterday I attended the 10th Sigchi.nl conference in Amsterdam, during which I had the pleasure of seeing Jared Spool, Jesse James Garrett, Bill Scott, Martijn van Welie, and Steven Pemberton in real live action. (Note to self: Jared and Steven are stiff competitors of Joe when it comes to being The Funniest Man at Web Conferences).
I'm not going to describe the conference in detail. Instead, I'd like to discuss an asynchronous communication question that popped into my head during Jesse James' presentation.
Part of his presentation dealt with Ajax, unsurprisingly, and he repeated the key point of his seminal article Ajax: A New Approach to Web Applications: asynchronous communication prevents the user's interaction with the application from stalling. When the user requests an extra bit of data, the app sends an HTTP request to the server, and even if it takes the server a while to respond, the user can continue interacting with the Web page.
This is of course true, as far as it goes; but the question that popped into my head is: do Ajax applications actually use this fact in practice?
Take Gmail. I click on a thread header, and the interface requests the entire thread—asynchronously, of course. Suppose Gmail is extremely busy and takes a while to handle my request—call it 10 seconds. Theoretically, I could now continue to interact with the Gmail interface while waiting for the response.
The point is: I don't do that. (Do you?) I have little choice but to wait for the server to respond.
First of all, my action is aimed at viewing the thread, and once I've decided to do that I have little reason to click on other stuff—it'd only distract me from the task I'm trying to accomplish. Secondly, if I did click on another link, the result of that action (another thread, or the Settings menu, or whatever) would occupy the same bit of screen real estate that the thread I originally wanted to see would; so the second action would effectively cancel the first one.
In other words, the Gmail interface, for one, doesn't use Ajax's advantage in practice, since it's pointless to continue interacting with it while a request is being handled. From an interaction point of view, Gmail could as well have used frames: a click in the navigation frame shows a page in the content frame, and the net result is exactly the same. (Of course, from a technical perspective Ajax is much sexier than frames.)
I'm curious if anyone knows of an Ajax application that is built for continuous interaction; an application that counts on the users taking other actions while waiting for a server response—or that at the very least allows them to view two or more server responses simultaneously.
I haven't seen one yet—but then, I don't pretend to be an expert on the countless Ajax applications that have hit the market in the last year or so.
Besides, I'm wondering if users are interested in this functionality. They want to accomplish something, so they click on a link and they wait for the interface to react; and whether the interface is asynchronous or not doesn't really matter. Of course this is just a theory I invented out of the blue—if anyone has actual data on user behaviour in a true asynchronous environment I'd love to receive a link.
In any case, I wondered whether asynchronous communication is all that it's cracked up to be from a practical point of view. If in practice it's not useful to initiate a new request while waiting for the response to a previous request, Ajax's main user interface advantage is kind of nullified.
Thoughts? Am I overlooking something obvious?
I’m speaking at the following conferences:
Comments are closed.