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.
|
