Friday, March 30, 2012

Ajax

I'm one of those oddball people who have been playing around with AJAX (Asynchronous JavaScript and XML) since before it was AJAX, first playing around with it in IE (as an ActiveX object) and then actually incorporating it into a web application when the XmlHttpRequest object was released in various browsers.

My first 'real-world' example was in an application that enabled people to register for court-ordered courses provided by government contractors. Basically, when a case that involved minors was being adjudicated by family court, the court would order the parties in the case to attend a course and, like your driving course, at the end the student/participant was issued a certificate that included their case number.

In this application, because of the limitations regarding who could attend a given class, and the use of common names and familiar names (nicknames), there needed to be additional checks built in to verify identity. This, of course, posed a challenge for a couple of reasons...first, the check needed to be run while everything was being validated and second, the system of record was not the government contractor's but rather the government's system.

To build what I needed, I first built a server applet that would run on my server. This applet would take names and case numbers and would query the government's web interface to get the corresponding data and parse the response. This allowed me to run the validation when my registration app received data, but it did more than that - it gave me an interface that could be called using AJAX from clients connected to my registration app.

By adding an AJAX engine that connected to the applet I was able to create a valid document that could easily be handled in the registration app to prompt the user for more information when there were multiple matches or a simple confirmation when there was a single match. This is where the real learning took place.

What I learned in creating this app (more than 10 years ago now), and more specifically in writing the AJAX portion of this app, is that web apps can be ssslllooowww...slow to the point of distraction, and adding AJAX doesn't, contrary to a lot of opinion and belief held by marginally-informed people, make an app faster. To be sure, it can, but whether or not it does is not a foregone conclusion.

What can you do to build a good interaction that makes an app faster or at least not slower?

First, recognize whether what you're doing is going to improve the customer interface or if it will improve your interface. For example, my requirement was to confirm the case numbers in order to verify that someone was actually eligible to attend a specific class. Confirming that number with the court marginally improves the customer interface because they need the court information if they don't have it, and their registration is simplified if I could verify the information, but really the improvement was for me. That means the interaction had to be unobtrusive and also convey a sense of convenience and purpose to the user, otherwise the impression would likely be that the user was waiting for something they didn't need and therefore the app was 'slow'.

Second, the interaction needs to run behind the scenes so that the user can complete the interaction as quickly as possible. This seems sort of obvious, but in the real world we all know how the request/response model works and that it takes time. In my example, the request needs time to get to my server, my server needs time to process the request and send out the response, and the response needs time to get back to the user-agent, and the user-agent needs time to process the response. If everything was quick, this only took a few seconds. However, if that were a few seconds at the end of the form, it's going to look like the application is a few seconds slower than it actually is. So, put the AJAX interactions closer to the beginning of the form...in fact, put them as close to the beginning as possible and structure them in such a way that the longer a request/response takes the earlier it appears in the form.

Third, and this may be a little counter-intuitive, show something that indicates to the user that there's an interaction occurring. I know this sounds like the opposite of "unobtrusive", but it's really not. This is fairly simple with a little DOM scripting to show/hide a mask over a specific block. This will also give the user the impression that some information is being processed ahead of time, making it appear the app is faster (even if it's not).

Fourth, use event-driven programming. Create an AJAX object that fires an event when it gets the response back and the response is ready for processing. Then, have your callback function listen for the event to fire and you're ready to go. There are a few options here, one of the easiest to use is the CustomEvent object in the YUI library...other libraries have user-defined event objects and you can build your own (it's not that difficult). This approach not only kills the use of setTimeout and setInterval (which can easily be very inefficient and troublesome in the extreme) but it also will actually make your app a little faster.

This is not, by any measure, a complete list of what to do to build a fast AJAX interaction. Your app may require more tweaking to be be faster, but this should at least be a start. So good luck and happy coding.

No comments:

Post a Comment