Back Draft

 

All Ajax, All the Time

 

By Jonathan Goodyear

 

It s official. Ajax (Asynchronous JavaScript and XML) usage has become the new standard by which Web interfaces are judged. Postbacks are so yesterday, right? Perhaps, but the path from complete screen re-painting to dynamic screen changes may not be as smooth from the end-user side as it is from the technical side. And even the technical side has its own set of problems.

 

I first wrote about Ajax last summer, shortly after the term was coined by Adaptive Path (http://www.aspnetpro.com/opinion/2005/06/asp200506jg_o/asp200506jg_o.asp). In that article, I mentioned that both the components of Ajax and their usage were not new or innovative. What was new and exciting was that some big-name companies like Google were using Ajax to make their Web interfaces much more responsive and desktop-like.

 

The other key element that made Ajax newsworthy is that some developers and organizations began making component libraries to abstract away the intricate JavaScript necessary to make asynchronous calls to the server and update user interface elements in the browser. Less experienced developers could now use Ajax in their Web applications. In September of last year I wrote about Microsoft s plans to bring Ajax to the Microsoft developer masses through its Atlas project (http://www.aspnetpro.com/opinion/2005/09/asp200509jg_o/asp200509jg_o.asp). The recent release of the Atlas Control Toolkit is a great start in that direction (http://atlas.asp.net/default.aspx?tabid=47&subtabid=477).

 

Now that everybody s going Ajax, though, some interesting issues are cropping up. From a technical perspective, third-party ASP.NET control vendors are discovering that it can be pretty hard to do all of the housekeeping necessary to keep happy an architecture designed around the Postback model. Specifically, Viewstate management has been a huge headache. If Viewstate is not brokered properly, it can either get corrupted and throw exceptions or cause control states on the page to get out of synch.

 

Another issue is that control vendors need to learn how to interact with other vendors Ajax-enabled controls that they may host or be hosted within on a given ASP.NET page. They can t rely on their customers sticking to a single control vendor, and there are a lot of ways to skin the Ajax cat. There is very little in the way of standards so far. Expect a lot of point releases and service packs as the vendors wade through the treacherous waters of this first round of Ajax-enabled controls. I suspect that it will get much easier in the Orcas (code name for the next version of Visual Studio .NET) timeframe, when Microsoft will focus more on building Atlas/Ajax functionality directly into the ASP.NET infrastructure. Then, third-party control vendors can climb out of the plumbing and go back to doing what they do best: building innovative controls.

 

That brings us to the end-user side of the equation. This is the part that matters the most. As developers, we care a lot about how Ajax-enabled applications are built; but the end user could care less. They just want applications that work and that are intuitive. The intuitive part is where a lot of first-round Ajax applications fall short. For example, a common Ajax-like thing to do is to update one control on a page based on a selection made in another control. In the past, the user knew that something was happening because the screen completely re-painted. Sure, it was inefficient. But, in a way, it was comforting to know that something was happening. We ve all been conditioned to expect this behavior.

 

The asynchronous nature of Ajax makes it very difficult to tell if something happened or not. The change may be subtle, and you ll miss it if you blink at the wrong time. Or, the change may not even be visible (e.g., items hidden in a DropDown control may change). As an end user, this can be very confusing and disconcerting. To combat the problem, more visual cues are necessary; perhaps highlight the next step in the process, so the user knows that the Web application did something and is now waiting on more input from them.

 

A second issue that is even worse is that some Ajax operations may not be quick to execute. This could be because of network bandwidth or performance (at the client or the server). It could also be because the task just takes a long time to complete. Either way, because the screen doesn t have to re-paint, the end user may not realize Ajax is quietly taking care of business in the background and attempt to move on to something else before the Ajax task completes. This can lead to bizarre application behavior. Developers of e-commerce Web sites will recognize this issue as similar to the one where customers repeatedly refresh long-running credit-card payment processing pages.

 

One suggestion to combat this is to provide a clear indicator that processing is happening. This can be as simple as an animated GIF, or as complex as an Ajax-enabled progress bar. Because the screen doesn t have to re-paint, few end users are going to notice that the browser s processing icon in the top right-hand corner of the window is spinning (or doing whatever it does in your browser of choice). A second suggestion that can be used in combination with the first is to use JavaScript to disable controls on the page that may cause problems if clicked before the Ajax task is complete.

 

A third end user issue I ve seen is dialog hell an endless series of JavaScript alert boxes to communicate validation states and other messages with the end user. Because Ajax allows you to easily pop up an alert box based on logic on the server, some developers of Ajax-enabled Web applications now think it is an open license to use them. Microsoft s new adCenter Web application (its foray into managed keyword advertising, similar to Google AdWords) does this quite a bit (http://adcenter.msn.com). There is a reason why alert boxes weren t used before they re annoying! Almost as annoying as regular browser pop-ups. This is definitely not the way to solve the end user communication issue. JavaScript is still just as capable of enabling the display of nicely formatted HTML status panes as it always was. Let s stop the alert box madness before it takes hold. An exception to this is the JavaScript confirmation box. Ajax makes intelligent confirmation boxes a snap, and I like the idea of having to confirm before doing something that is potentially stupid in a Web application.

 

As you can see, there are some initial growing pains on both the technical and end user sides of the Ajax equation. That is to be expected with the adoption of any new methodology or concept. There are definitely some bright spots, though. The latest release of FogBugz by Fog Creek Software makes fantastic use of Ajax to streamline the application s efficiency and usability (http://www.joelonsoftware.com/articles/FB4.5.html). Hopefully we ll all quickly learn from our mistakes, and more well-designed and intuitive Ajax-enabled Web applications will find their way into our daily work and personal lives.

 

Jonathan Goodyear is president of ASPSoft (http://www.aspsoft.com), an Internet consulting firm based in Orlando, FL. Jonathan is Microsoft Regional Director for Florida, a Microsoft Certified Solution Developer (MCSD), and co-author of Debugging ASP.NET (New Riders). Jonathan also is a contributing editor for asp.netPRO. E-mail him at mailto:jon@aspsoft.com or through his angryCoder eZine at http://www.angryCoder.com.