All Ajax, All the Time
By Jonathan Goodyear
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.
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.
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:email@example.com or through his angryCoder eZine at http://www.angryCoder.com.