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:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6"
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 1.5.0.6, 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.
To determine how many users have JavaScript enabled, add a NOSCRIPT section that loads a unique image, one that doesn't impact on the page, and then check the logs to see how often the image has been accessed. With recent high-profile script-based security violations at Google and elsewhere, you'll find that more people are disabling script as a security measure. Others may be using tools such as NoScript (http://noscript.net), a Firefox extension that allows you to enable JavaScript on a site-by-site basis. When designing your web content, expect that people will have script turned off, and unless the application is completely based on scripting, don't put up notices about how people should turn scripting on for a better experience; this has become the equivalent of an Ajax blink.
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.
What if my page readers had wanted the DHTML drop-down menu? If my site structure had been more than two levels deep, I would agree, but I wouldn't just implement the menu and then walk away. Dynamically generated navigation makes your site inaccessible for those who have turned off JavaScript, have difficulties using a mouse, or are using a text-to-speech browser.
Even if you find that 95 percent of your readers turn on script, use a mouse, or use a browser like Firefox, making your site inaccessible punishes those people who may already have enough challenges in their lives. Consider also that the most popular extension for Firefox is one that turns scripting off for sites by default (NoScript). You shouldn't make any assumptions about how many people are using JavaScript, either. Finally, search engine web bots, such as Google's and Yahoo!'s, can't follow script-generated links, and therefore won't pick up the material accessible only through the menu.
Some features may require JavaScript or the mouse. These might include online word processors, spreadsheets, or games, but should never include critical features such as the ability to navigate to main content pages and application documentation. Use the following recommendations when you are determining how to best incorporate your page readers' needs:
Forget the surprise rollout; ask your page readers what they'd like to see before you begin.
Consider beta testing a change in one portion of your site and soliciting feedback before rolling it out across the site.
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.
Get Adding Ajax now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
