This content is reprinted from Real-World AJAX: Secrets of the Masters published by SYS-CON Books. To order the entire book now along with companion DVDs for the special pre-order price, click here for more information. Aimed at everyone from enterprise developers to self-taught scripters, Real-World AJAX: Secrets of the Masters is the perfect book for anyone who wants to start developing AJAX applications.

Users as Testers
In a traditional software development environment, there's a clear separation between developers, testers, and users. Programmers create the application, then throw it over the wall to the testers. Testers exercise the application according to a more or less detailed test plan, reporting issues to the developers who may or may not fix them. Once all the bugs that are to be fixed are fixed, the testers declare the product ready for release and it's shipped to the users.

Even in a perfect world, there are issues with this model. Test plans are often incomplete or non-existent. Determining which issues are to be resolved is a source of conflict. Often, a hostile relationship develops between programmers and testers.

In the Web 2.0 paradigm, testers disappear; users are the new testers. Changes to the application are immediately published (or "pushed") out to the users. Users report bugs and developers fix them. There's the notion that if a bug exists but no one reports it, it doesn't really need to be fixed.

Users as testers is not a new idea. In his seminal essay, "The Cathedral and the Bazaar," Eric Raymond defined "Linus's Law" (named for Linus Torvalds, the creator of Linux) as "Given enough eyeballs, all bugs are shallow," or more formally, "Given a large enough beta tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone." Linus's Law is itself an extension of an idea that dates back at least to the early days of Unix, when AT&T distributed the source to all users.

The great leap forward provided by the Web 2.0 paradigm is that the user base is extended to anyone with a browser. The barrier to entry is almost non-existent: Web 2.0 applications require no effort to install or upgrade. The user points his browser to the appropriate URL and automatically gets the latest version.

A corollary to this ease of availability is that with so little time and effort involved in obtaining the application, the barrier to exit is similarly low. Web users are notoriously fickle. Furthermore, they're probably, on average, a bit less technically adept than members of an open source project. This has implications for how feedback is gathered from your users; if it's onerous, they are unlikely to provide it.

There are several mechanisms for obtaining user feedback:

• E-mail Link: This is the low-tech approach; you provide a feedback link somewhere in your application. When the user runs into an issue, or has a question, he sends you an e-mail. Presented with an empty e-mail window, however, all but the most committed users are likely to simply close the window. If the issue is big enough, or the question has them stumped, they're likely to close your application window as well.
• Feedback Form: This provides a bit more guidance to the user as to what information you care about. Assuming that your user has registered for your application and is logged in, you can probably avoid many of the repetitious fields that will discourage the form's use. Be proactive in terms of prefilling fields that describe the browser, application state, etc. The more you do for the user, the less the user will have to do and the more likely the form will actually be submitted. Where you can't prefill the fields, providing checkboxes, radio buttons, and drop-down lists makes things easier. At the same time, be sure to provide at least one text box so the user can express free-form thoughts, observations, and reactions. Just don't expect it to be filled in.
• Mailing Lists: While mailing lists have survived virtually unchanged since the primordial, pre-web Internet, they're incredibly useful. Don't underestimate the willingness of users to help each other and themselves. A mailing list will also help generate a feeling of community among your users. Before you know it, they'll be meeting in the real world for drinks and talking about designing T-shirts with your logo. How cool is that?
• Wiki: A wiki lets the user search for help and provide feedback. It's also a great place for you to post help text, feature descriptions (both existing and planned), and other information that draws your users into the development process. Wikis are easy to set up. We use MediaWiki, the system used by WikiMedia (www.mediawiki.org). An added benefit of having a wiki is that you demonstrate your willingness to eat your own Web 2.0 dog food.

Quality assurance is as rigorous a discipline as software development, perhaps more. Not only can a good tester uncover bugs that might otherwise lie dormant only to erupt at the worst possible moment (Murphy's Law still applies, even in the Web 2.0 Wonderland), testers are an invaluable resource for reproducing bugs that users find, and providing the specific steps to developers. This will significantly ease the effort required in resolving these bugs.

A well-designed test plan will expose flaws in the software. Automated testing, especially automated regression testing, ensures that the application will run in an environment other than the developer's workstation, and that nothing has been broken by fixing the bugs or adding features.

Of course, the exact mix of developer testing, quality assurance testing, and usr testing will depend to a large extent on the nature of the company producing the software.

In the wild frontier of Web development, where a small shop is creating the Next Big Internet Thing, there are probably insufficient resources for a formal QA process. Being on the frontier, the bar for acceptable stability and functionality is also fairly low, the tolerance of the user community for unstable software is fairly high, and the benefit of quick fixes and rapid development is paramount. This, in fact, is the fertile ground from which the Web 2.0 paradigm sprung.

At the other extreme, it's hard to imagine unleashing an unstable new version to the full scope of users in a corporate environment. In this environment, where there are ample resources and even requirements for a rigorous quality assurance process, the best one can hope for is to create a small pool of voluntary beta testing users. Only once the application reaches a satisfactory level of stability can it be unleashed on the full range of users. These users wouldn't be appropriate testers; they expect things to work well and consistently.

The key in this environment is to identify a group of users willing to trade the stability of a production release for the joy of collaborating in the development. Part of the change control process is first to deploy applications to a test environment; deploy to this environment and have your user testers collaborate from here. If you can publish a blog or wiki on the corporate intranet, this will enable your users, and potential users, to share in the process.

While the Web 2.0 paradigm allows for a more dynamic development process, it doesn't preclude the need for process. Quality assurance, version control, design, and other stalwarts of the prerevolutionary software development process still have a place and are, in many ways, even more necessary.

Real-Time Monitoring and Sampling
Hype aside, the Web 2.0 paradigm does enable users to be active participants in the application development process. We've discussed methods for gathering intentional feedback from them. Realtime monitoring and sampling are techniques for gathering feedback unobtrusively.

Let's say, for example, that you want to add a new feature to your application, and that this feature could be implemented one of three ways. You could send out e-mails or add a form to your application users soliciting their feedback. Chances are no matter how well you describe the choices, and even if lots of users respond, they may not have a full understanding of the trade-offs involved. More likely, they'll just delete your e-mail or skip the form altogether.

Another option would be to provide all three choices to every user and let them try each one and pick the one they like best. The problem here is that users presumably use your application to do something that matters to them. Helping you build a better mousetrap matters less. Again, you're likely to get a limited response.

This is where sampling comes in. You implement all three solutions and provide each solution to a different set of users. Assuming your users have logged into your application, there are any number of algorithms you can use to provide each implementation to different users. So far so good.

But where do you go from here? Again, you can provide some sort of intrusive method for gathering feedback and suffer the frustration of limited response. A better solution is to gather statistics directly for the use of each implementation. At its simplest, you might measure the use of each method. This can be measured on the server, tracking page and/or AJAX requests. The one most used wins - of course, you'll probably want to apply some statistical analysis to determine which one is most used.

JavaScript lets you collect even more statistics - the amount of effort as measured by mouse-clicks, keystrokes, etc.; the amount of time a user spends not interacting with the screen; whether the user consults the online help; how many users punt on the feature altogether. The possibilities are endless. AJAX then lets you post these results to the server in real-time as well.

In fact, it's possible to encapsulate this real-time client-side monitoring in a JavaScript framework and embed it in every page. Similar techniques can be implemented on the server side to gather other sorts of usage statistics.

There are a few issues to keep in mind, however. Real-time monitoring on the client should be limited to gathering the statistics. Processing on the client can be expensive in CPU and memory time. And there's always the danger that your user will move to another page or close the browser before you get the statistics.

Most importantly, be mindful of the statistics you gather. Be sure to limit yourself to data that's relevant to the performance and usability of your application. Nothing brings bad publicity faster than getting caught spying or even appearing to spy.

The data you gather will provide the kind of intelligence that no amount of user observation ever could. It's like watching over the shoulder of all your users at the same time.

Shadow Applications
Shadow applications are the set of utilities, both canned and custom, that the developer uses to analyze how the application is being used and performing. If real-time monitoring and sampling provide the raw material for user/developer collaboration, shadow applications refine that material, and other data, into meaningful information.

Shadow applications fall into two categories: infrastructure and domain-specific. Infrastructure applications let you analyze the performance of the commodity parts of the system: the network, the database server, the Web server, and the application server.

None of these applications are new to Web 2.0. Packet sniffers and network traffic analyzers have been around as long as there have been networks. Most database servers come with sophisticated analysis tools. The same is true of Web and application servers. As a rule, each of these servers generates log files, and you can configure them to capture more or less information in the logs. The analysis tools read these logs and provide a clear view of what's happening. If for some reason your needs aren't met by an existing analysis tool, you can always write your own. PHP and Ruby are excellent tools for generating Web content from text files. PERL is unmatched in its text-handling capabilities.

Adam Green discusses the value of infrastructure analysis tools in his article, "The Value of Simple Metrics, Closely Watched" (see the resources section at the end of the chapter). He gives two examples: one is of the pages-per-visit (PPV) metric as a measure of user commitment, server performance, and site navigation, in short "the user's approval of the Web site experience." The higher the PPV, the better the experience.

He also discusses how his company, having acquired Slashdot, experienced server overload. So it built a monitoring system that displayed database metrics, notably queries per page. Using this information, it was able to rebuild the schema, bring down the queries per page, and solve the performance problem. Even better, the developer in question was able to post the graph of the improved metric proudly on his door. Wins all around.

Recently, I worked on a Web-based order entry system for a client. The system started to perform slowly once there were more the 25 distinct line items in the order. Using much simpler tools (a PERL script that parsed the Apache and MySQL logs), I determined that the system was retrieving the order line and item records every time the order was accessed. Implementing a cache solved the problem.

As helpful as the infrastructure tools are for analyzing the performance of your application, domain-specific tools provide more intelligence about how your application is being used. By definition, these tools will need to be developed specifically for your system.

Unless you're a one-man shop, it's probably worth the effort to provide a Web-based interface to these tools so that your whole team has ready access to the results.

The specifics of what these tools do are dependent on the specifics of your application. In the order entry example above, I provided a tool to the customer that analyzed the sale of each item. Later, I added the ability to map this against the day and time of the purchase.

Marc Hedlund (see the resources section) relates the example of a report used at Flickr called the "Loneliest Users" report. This report detailed users who had uploaded photos but had no users in the Flickr social network. They could then connect with these users and teach them how to use the contact feature. This is the sort of collaboration that Web 2.0 is all about.

Permanent Revolution
One of the hallmarks of many Web 2.0 applications is that they are in a state of "permanent beta." This refers to the traditional software release process that divides releases into alpha (unstable, not feature-complete), beta (relatively stable, feature-complete) and gold (stable, feature-complete). The implication of a permanent beta is that the user should expect it to continuously grow and improve.

The Web 2.0 architecture enables this model of "permanent change" perfectly. Being browserbased, there's no need for the user to upgrade software on the desktop. The next time the user runs the application he gets the latest version. This implies that only one version of the application is deployed at any given moment. Anyone who has had to support multiple legacy versions as well as the latest knows that this is undoubtedly a good thing.

It's hard to imagine, however, the permanent beta model working in the corporate environment. Corporate IT departments generally have strict change control and risk management procedures. These procedures generally require that an application be first deployed in a test environment, rigorously exercised, and only then allowed to move into production. An application that requires daily or even weekly updates would simply not be acceptable.

A middle ground can be found, even here. The barriers to upgrades in the test environment are less onerous than apply to production. One should, therefore, keep "permanent beta" software for the test environment. When a release is stable and feature-complete it can be moved to production. This requires a fairly well-thought-out set of milestones, but between milestones, the benefits of a permanent beta can be reaped.

Yahoo! takes a similar approach; it provides both the stable and latest versions of applications. The user selects which version he wants to use. Once a version achieves a certain stability it moves into "production."

If you're creating an application that you'll be selling to others to host, you don't have the luxury of a permanent beta. And you'll be back in the game of maintaining disparate versions, especially if you sell the application to more than one customer. As Web 2.0 matures, it becomes more likely that successful applications will be licensed to, and hosted by, companies that don't create or maintain them. By maintaining a process that supports actual releases, you'll be ready for the big moment when you can start licensing your work of art to others.

Whatever approach you take, the Web 2.0 paradigm of a permanent beta doesn't eliminate the need for proper version control. In fact, the dynamic nature of the frontier makes it even more essential that you can revert to earlier versions, back out changes, and track revisions. Any release that's published to the user should be properly labeled and retrievable from the version control archive.

Public APIs
If there's a defining quality of Web 2.0, it's collaboration. On one level, it's the collaboration between users as well as between users and developers. To the extent that your application promotes this collaboration in a useful way, you'll be successful.

Collaboration also happens at a deeper level between applications. This is most evident in the emergence of "mashups," applications that aggregate content and services from a variety of sources. To play in this field, you have to provide an API.

There are other benefits to an API, most notably that it promotes looser coupling in your application. And, since your AJAX-enabled client has to talk to your server somehow, it makes sense to put the effort in to create a well-constructed API. In the spirit of eating one's own dog food, your client uses the same API that you publish to the rest of the Internet.

While your application may be in permanent beta, once you've published your API, you've effectively issued a contract. You may extend it by adding new methods, but if you change the existing methods you run the risk of breaking applications that depend on it. This means that you must take great care before publishing the API.

This is where using your API for your public application pays off. By developing your application along with the API, you're building a better API - both in terms of stability and usability. If possible, you should separate development responsibility: one team works on the client side of the application, the other works on the server side as expressed through the API. The collaboration between these teams will quickly shake out any awkwardness or instability in the API.

An API is also helpful in hiding dependencies on third-party services. Rather than having the client talk directly to these services, your server does the heavy lifting and translates the results into a format friendlier to your client side.

For example, you might want to pull currency exchange rates off a government Web page. If this were done on the client side, every time the application ran, it would have to pull down this Web page, parse the HTML, and convert this into JavaScript data. By having your server do this, you can download and process the information only when necessary; all the clients would then have access to this data.

In some cases, you might want the server to aggregate data from a variety of internal and external sources, providing a simple API call to retrieve the results. Some of these sources might be "old guard" technologies such as message queuing or even mainframes. And by wrapping access to back-end and third-party systems behind an API, you leave room to change these sources in the future.

An API also lets you implement transaction-processing logic so that it's transparent to the client. In the case of my order entry system, there were a number of back-end systems that had to be updated as a unit. If one of these updates failed, the entire transaction had to be rolled back. Not only is this process-intensive operation better suited to the server, it also enables the application to leverage existing transaction-processing tools.

Finally, if you work for a company that worries about issues like intellectual property, the API defines only the interface for the services; the implementation can be protected using standard system security.

On a more prosaic note, I prefer to have my API generate Plain Old XML (POX). Using standard serverside technologies such as XML Stylesheets (XSLT), this can then be easily translated into HTML, REST, SOAP, JSON, or even plain text. Your client application will probably want JSON to reduce the effort of interpreting the results; third-party applications are likely to prefer other formats.

Graceful Degradation
When you publish your application on the Web, you have no control over the browsers that access it. A lot of Web surfers use older computers and many companies still insist on disabling JavaScript. Moreover, if your application depends on launching new windows, you'll probably run into a fair number of users who've disabled pop-ups to avoid the Web spam embedded in so many sites. It's likely that your application won't work correctly or at all. There are several approaches you might take to address this.

The easiest solution is to punt. Let the browser inform the user that the page can't be displayed. Ever try running Gmail on an iMac running OS 9? It doesn't work. It doesn't even tell you why, it just doesn't. So if it's good enough for Google, with its billions of dollars and staff of geniuses, who are you to disagree?

The problem with punting is that you're likely to alienate potential users. In many cases, these are people who only need to tweak their browser settings for your application to work.

At the other extreme, you can attempt to detect all the various combinations and permutations of browser-induced problems and try to provide as much functionality as possible given these limitations. But trying to provide multiple levels of functionality is likely to double the development effort involved and severely complicate the code. And the more complicated the code, the buggier it's likely to be.

A fair and equitable solution, therefore, is to provide a static Web page that explains the minimum requirements for your application. When the user first connects to your Web site, you can retrieve the browser and version from the HTTP header - it's specified in the user-agent field - and redirect the user to this page.

Handling cases where JavaScript is disabled is also straightforward. HTML provides a NOSCRIPT tag that provides alternate content for a script that wasn't executed. Using this tag, you can easily redirect the user to your minimum requirements page.

Finally, to check whether pop-up windows are disabled, you can embed a simple call to window. open() in the onload method of your main page. If this fails (i.e., returns null), you redirect the user to your minimum requirements page.

Listing 10.1 demonstrates these techniques, where the minimum requirements are listed in "minimum. html" (not shown).

Listing 10.1

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <title>JavaScript Tester</title>
    <noscript>
      <meta http-equiv="Refresh" content="0; URL=minimum.html" />
    </noscript>
    <script>
      function testPopups () {
        var win = window.open("", "Popup Test", "hidden");
        if (win == null) {
          window.location = "Minimum.html";
        } else {
          win.close ();
        }
      }
      onload=function () {
        testPopups ();
      }
    </script>
  </head>
  <body>
    <ul>
      <li>JavaScript enabled</li>
      <li>Popups enabled</li>
    </ul>
  </body>
</html>

This mechanism provides meaningful feedback to the user, with minimum development overhead.

Summary
In the old days, developers were wont to blame "stupid user tricks" when users improperly used the application. The six practices described in this chapter promote the development of robust, user-friendly applications, exploiting the opportunities of the Web 2.0 paradigm while leveraging the vast resources of the paradigms that came before.

Additional Information
Marc Hedlund provided an excellent discussion of current Web 2.0 practices in his blog post, "Web Development 2.0." Much of this chapter found its inspiration from this post. See http://radar.oreilly.com/archives/2006/02/web_development_20.html.

Adam Green discussed using internal metrics based on Web site statistics in "The Value of SimpleMetrics Closely Watched": http://darwinianweb.com/archive/2006/248.html.

Eric Raymond has written extensively on the hacker culture and the open source movement. O'Reilly has published a collection of his essays as The Cathedral and the Bazaar (O'Reilly and Associates. Sebastopol, CA. 1999). His Web site, www.esr.org, is full of great content, including the New Hacker's Dictionary and many of Mr. Raymond's always engaging and sometimes less than politically correct writings.

This content is reprinted from Real-World AJAX: Secrets of the Masters published by SYS-CON Books. To order the entire book now along with companion DVDs, click here to order.