The amount of Ajax functionality that you introduce to your site depends on more than just how much you're willing to add and maintain. Even the niftiest technology is going to fall flat if it doesn't provide an added value, or worse, locks your users out of the site. What you will discover, though, is that if you listen to the feedback from your client base, you'll be able to use a little scripting and a few in-page web services to really increase the usability of your site.
The first step in your Ajax makeover is discovering all you can about the people who visit your site so that you plan accordingly. Your best friends in this regard are your site's logs. The following log entry is from one of my sites, and it is a fairly typical example:
5x.x2.x8.xx0 - - [31/Aug/2006:03:09:27 +0000] "GET /wp-content/themes/ bbgun/bbgung.png HTTP/1.1" 200 90338 "http://burningbird.net/wp-content/themes/bbgun/ style.css" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20060728 Firefox/18.104.22.168"
This log displays the date, the resource accessed, and a string containing information about the client's operating system and browser. In this case, the browser is Firefox version 22.214.171.124, and the operating system is Windows. Another line from the log is:
x0.xx3.1xx.xx4 - - [31/Aug/2006:03:14:48 +0000] "GET /wp-content/themes/ words/eyesafe.png HTTP/1.1" 404 9058 "http://burningbird.net/" "Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1b1) Gecko/20060707 Firefox/2.0b1"
This client is using Firefox 2.0, the first beta release, and the operating system is Mac OS X.
This information will help you determine which user agents (browsers and mobile devices) to support, and will allow you to compensate for the image, image resolution, font support, and tool support differences that exist between operating systems.
You can look at a logfile directly or you can use one of a variety of web tools such as AWStats or Webalizer to analyze the log. You can find these and others just by searching for "logfile analyzer" with your favorite search engine.
Other resources you can use to explore web access are the sites that track browser statistics, such as the W3 Schools at http://www.w3schools.com/browsers/browsers_stats.asp or The Counter at http://www.thecounter.com/stats.
I once asked readers at one of my sites which specific uses of Ajax they'd like to see on the site. One of the options I listed was a drop-down menu that popped open either when the mouse was over a top-level menu item or when the item was clicked—a quite common use of DHTML frequently extended to Ajax.
Surprisingly, the behavior of the drop-down menu wasn't especially interesting to my readers. They tended to be more interested in having control over their interaction with the site than they were controlling the navigation between pages.
Now, if I had a more complex site structure, the menu might have been more essential. However, the difference between what I thought would be important to the page readers and what they actually reported demonstrates that you can't assume what your page readers will want. Before you begin the process of adding Ajax to your site, it's a good idea to get your readers involved—ask what they want to see, or test new technology in specific places and solicit feedback. Don't be surprised, though, if you have to change both your assumptions and your implementation plan.
Forget the surprise rollout; ask your page readers what they'd like to see before you begin.
Balance requests against the amount of work required; the more moving parts the more things can break, and no reader likes a broken page.
Listen to people. If you roll out a change and it doesn't work, be prepared and ready to pull it back and try something else.
Now that you have a better idea of your page readers' environments and preferences, it's time to develop a plan for adding Ajax to your site. The difference between adding Ajax to a small site versus a big one is in the number of hours it will take, not in the steps you take.
The object that you change first is dependent on your reasons for adding Ajax. For instance, if you have an extensive customer application with lots of form pages, this would be an ideal place for adding Ajax; it's an isolated application that could have big returns in terms of satisfaction, quality of response, and resource use once it's Ajax-enabled. Ajax can also improve the overall performance of the application, making it even more of a win-win situation.
Other target areas are any pages where your readers have the ability to update or modify information. Adding Ajax to make the changes in-place can add enormously to the client's satisfaction, while still being completely accessible.
Providing JIT help or feedback is an excellent use of Ajax. Just make sure that the same information is available if scripting is disabled or if clients are using a text-to-speech browser.
The addition of visual elements should not be your highest priority, but it's a legitimate use of Ajax. These changes can add a nice "Wow" factor with minimum disruption of the site's primary functionality.
Ajax should be added gradually, and you should back the site up before you add even one line of code. If you do need to add something globally, like a new Ajax-enabled menu that will appear on all of your site's pages, encapsulate the code into a file that can then be incorporated into all your pages—such as a header file that's incorporated into each page using server-side functionality.
Minimize the amount of code you'll add to each page by organizing code into libraries and including only the desired library on each page. Or consider using one of the freely available Ajax libraries. Several Ajax libraries are covered in Chapter 3 and are used throughout this book.
When creating your plan, consider the following:
This is a nag, but can never be said too much: back up your site before you start and when each addition is published.
Determine your starting point; an isolated application makes a good candidate.
Examine areas where your site or application is already interactive and explore how Ajax can be used for improvement.
Make liberal use of JIT help and feedback, providing alternatives for clients who have scripting disabled.
Visual effects to enhance or accompany existing functionality add sparkle and effect, usually at minimum cost.
Look for opportunities to encapsulate reusable chunks of code, such as menu functions or online help.
Use existing libraries.