Interest in Ajax continues to increase, which is somewhat
surprising considering that its constituent components have been around
for 5+ years. In fact, Microsoftwas one of the earliest to adopt Ajax (they used XMLHTTP in an earlier version of Outlook Web Access). Google, however, popularized the development technique by launching Maps, Gmail, and Suggest (hopefully, Microsofthas a big budget for extra chairs).

I’ve been captivated by Ajax, too. When well-implemented, Ajax-powered applications are undeniably impressive (see here); they seem to run fast, they look good, and no plug-ins are required.

However, there are at least three noteworthy problems with the use of Ajax in web application development.

First, Ajax introduces potential user interface issues. In
particular, poorly designed Ajax applications work in ways that aren’t
intuitive for the average user. For example:

• The back, stop, and refresh buttons don’t always work.
• Since Ajax applications generate pages dynamically, there generally
  aren’t static links available for bookmarking or sharing with others.
• Pages don’t always print well.
• Applications don’t run offline.
• Clicks and actions generally don’t get included into a browser’s history table.

For more detail, see Adam and Alex Bosworth’s posts here and here.
In any case, well-written Ajax applications minimize UI problems by
providing meaningful visual feedback to users. Also, it’s worth noting
that there are emerging solutions (often crude) to some of the above
problems.

Second, Ajax requires JavaScript and, for Microsoft’s Internet Explorer, ActiveX must be enabled (though there is a workaround).
I think this is a manageable issue as most browsers are sufficiently up
to date–though some companies and individuals have disabled JavaScript
or ActiveX by default for security or privacy related reasons (see here and here). The key is to design applications to degrade gracefully
(which is a fancy way of saying that web pages should work for new and
old browsers, even if the old browsers don’t support certain new
capabilities). Interestingly, Google fails in this regard. Try running Google Maps with JavaScript disabled. It won’t work (they could have produced a Flash-version like this one here–in some ways, it’s better than the original).

Third, Ajax developers need to be especially mindful of perceived
application performance. The goal, obviously, is to make applications
seem fast. One way to make that happen is to preload data as an
application starts; then, when a user clicks, there can be an instant
response. However, it’s sometimes impossible to preload an entire
dataset (think about the vast amount of data in Google
Maps), so developers need to make smart design decisions about what
data users will most likely want. A related issue is network latency,
or the time between a user’s click and the system’s eventual response.
If the wrong data was preloaded, there should be a visual cue
indicating that the user may have to wait until the right data is
collected from wherever it is stored.

Of course, some of these problems aren’t unique to Ajax-enabled
applications. However, that doesn’t mean the issues aren’t real. Where
some see problems, though, others see opportunity. For example, there
is a market for new development platforms for quickly and
cost-effectively writing, debugging, and managing complex,
enterprise-scale applications. Also, there is a need for better browser
standards, so that applications work consistently across different
platforms.

My sense is that we’re just seeing the tip of the iceberg when it
comes to browser-based applications–there are many more on the way, and
we’ll be increasingly amazed with what can be done. To that point,
we’ve recently invested in a very intriguing company in this area. I’ll
blog about them when I can. Also, I’m always interested in learning
about new startups, so email me if you have ideas.

posted by albertxu at 8:10 pm & filed under Web2.0 |