The Chatterbox

Using Ajax To Create A Better User Experience

I'm going to be starting a series in the very near future showing how one can use the concepts and coding behind what is commonly known as Ajax in your site construct to enchance user experience. But before I do I feel the need to explain my approach to using the capabilities available.

First, let's start off with a quick discussion/definition of what Ajax actually is.

At it's heart Ajax is nothing more than JavaScript. Really it's more than JavaScript -- it's a collection of inter-related web development techniques that can be used to create interactive web applications. But even this rather broad and often confusing definition doesn't explain why Ajax can be such an improvement over using html or any of the server side scripting languages such as php, asp, etc. So where does Ajax fit into the puzzle?

Well when you think of the Web, or more specifically Web Applications, it's important to remember there are two sides to the coin.

First you've got things that happen on the Server side of the equation. This includes how Apache processes and delivers pages, server side scripting languages, databases, etc, etc.

On the other side of the equation you have the Client side applications, which generally means Browsers and everything that happens in a browser that is independent of a (new) connection to a web server. In an Old World sense JavaScript would be considered to be a Client side application because JS does all of its work in the browser, which lives on the clients (users) side of things.

This is where Ajax is different from the JavaScript most people have been used to using over the years. Unlike things like Image Rollovers and the like, which take place squarely in the Client, Ajax also has the ability to communicate with the server to send and/or receive additional information. Ajax thus opens up a new world to web developers.

It's an important distinction. Whereas almost everything that didn't require a 3rd party application be installed (eg Flash, Java, ActiveX controls) could be broken down to one of the two groupings --Client side or Server side-- Ajax sits in the middle somewhere. It can and does effect changes on the Client side of the equation, but at the same time it can communicate with the server like a Server side application. And every browser supports Ajax natively, meaning no 3rd party application needs to be installed by the user to take advantage of the additional functionality.

This is where the power of Ajax comes from. It is neither Client nor Server side. It's a middleman. It's something else, something different. Yet doesn't require anything special of the user.

Now, how powerful is Ajax? In a word, very.

It can do everything JavaScript can do on the Client side. Plus it can do much of what Server side scripting languages can do.

But here's the deal ...

As far as I'm concerned just because Ajax can do a lot of the heavy lifting that Server side scripting typically does, it doesn't necessarily follow that web deveopers should use it to perform every single function that would normally be done by a server side script. Not only don't you need it to, but it's folly to depend upon Ajax to do all of the heavy lifting. Beyond that it's just bad coding and bad for business if you're running an e-commerce site.

Why? Well, because you can never fully depend upon what a user has available to them in their browser (Client side) application. So if you rely totally on Ajax to do the heavy lifting it is an absolute certainty your site will not work as expected for all users.

It's simply wiser from the development perspective to leave the heavy lifting to the Server side utilities, then use Ajax and its Client side abilities to update the browser. The beauty being that instead of having to update the entire page --as happens with solely Server side scripting languages-- Ajax can simply update the part of the page that needs to be updated when used in an Ajax compatible browser.

Read that again to make sure it sticks.

Server side applications (.php, asp, etc) requires a full page update when something happens. Ajax allows the user to stay on the same page, only updating the part of the page that requires an update.

At the same time, if you build your applications correctly, those users whose browsers do not support Ajax will still be able to use the site, because the back end Server side application is still doing all of the heavy lifting.

In the coder geek circles this phenomenon is known as Progessive Enhancement. Some also refer to it as being a situation where the code enables the application to degrade gracefully. Or in the Ajax circles some refer to the concept as Hijax.

How does it work?

It's simple really.

You have a back end Server side application that still does all of the heavy lifting, and on top of this you lay an Ajax application to provide a better user experience. The general concept comes from how CSS development has progressed over the years.

With CSS you have HTML (or XHTML or whatever) that provides Structure to the page. Then you use CSS to style all of the content that goes into the structure. Good use of CSS allows you to separate Structure from Style. To create a modular design that not only looks better, but works better and is much easier to maintain.

Correct use of Ajax utilizes this same idea of modularity, except that it keys on how the Client side and Server side applications mesh together to create a superior user experience. And also makes use of the CSS modularity mentioned above to style the content. Done correctly Ajax, or some would say Hijax since we're talking about something a bit more, allows we web developers to increase a site's interactivity, speed, functionality and usability.

Wow! That's a lot isn't it?

Yes, it's a tall order. But it's not really all that difficult to do. Here's all you need to remember to develop a site that is going to make use of Ajax:

1. Plan for Ajax from the very beginning.
2. Implement your Ajax at the very end.

Sounds simple doesn't it? It really is that easy if you can remember these two rules.

Planning for Ajax simple means that you need to create your basic page templates to be modular --as should already be the case if you're using CSS to style content-- but still have the Server side applications do all of the heavy lifting. Meaning even if someone comes to your site without an Ajax capable browser --say a Search Engine Spider or someone who uses a screen reader for instance-- they'll still be able to use your site. The only downside for these users is that they'll get a version that isn't quite as pretty, nor will they be able to stay on the same page as they communicate with the server. But everything will still work for them.

That's the key... Keep the initial page design as simple as possible, but very functional as you're developing your web application in the beginning. There's no need to pretty things up, because during Step 2 you'll be using Ajax and CSS to make everything pretty and provide additional functionality. It's already in your plan after all !

That's the basic concept you need to understand as we move forward. The moral of the story being that just because Ajax can do a lot of heavy lifting doesn't mean it should. In fact, I would contend that it shouldn't, because if you allow it to do all of the work you're going to be locking some very important visitors out of the best your site has to offer. Most notably the search engine spiders.

So remember the two rules and you'll be fine as we move forward to build some Ajax-enabled applications.

1. Plan for Ajax from the very beginning.
2. Implement your Ajax at the very end.

Got it?

Moving forward we'll start to develop some Ajax-enabled web applications. Starting off with some pretty simple stuff to get your feet wet. Eventually moving up to an Ajax-enabled, spider friendly shopping cart application.

Fasten your seat belts! This is going to be a fun (and hopefully educational) ride!