AJAX DOES A LOT FOR WEB USABILITY, HAS ALREADY DELIVERED SOME STUNNING APPLICATIONS, AND IS clearly the “in” thing at this time. But it’s no magic bullet. Careful design is always required, and it must be tailored to the technology at hand. By monitoring the state of Ajax applications, we continue to learn about what works and what doesn’t, and about how developers are succeeding in their design trade-offs. This chapter explains these lessons at a high level and introduces the patterns, which discuss them in depth.
Ajax is about improving user experience and delivering value to the organizations that own and use web applications. Here, we’ll look at the key attributes of an ideal Ajax application. Reality dictates that you’ll never get the best of all worlds, so you’ll have to make trade-offs based on how important you consider each attribute. The Ajax Patterns are intended to help you deal with these trade-offs.
Ajax applications should be as intuitive, productive, and fun to use as possible.
Development should be as efficient as possible, with a clean, maintainable code base.
Ajax applications should consume minimal bandwidth and server resources.
Ajax applications should provide accurate information and preserve the integrity of data.
Ajax applications should work for users with particular disabilities and of different ages and cultural backgrounds.
By studying existing Ajax applications, as well as any relevant precursors, it’s been possible to distill a number of important design principles for Ajax, which are shown in this section. The thinking behind the principles was a big influence on the pattern discovery process, and knowing them will help to apply the patterns.
We’ll begin by looking at principles of user-centered design, followed by those of software design. Of course, you can never fully separate those concerns, and they’re often in conflict with each other. Dealing with those conflicts is really a key concern of the patterns. Incidentally, it’s worth checking out a good online resource that takes the opposite perspective: Ajax Mistakes (http://swik.net/Ajax/Ajax+Mistakes) is a long list of Ajax mistakes and gotchas, as well as anti-patterns originally authored by Alex Bosworth and now maintained on a wiki.
Try hard enough, and you can do some very confusing things with Ajax, even more so as rich graphics become commonplace. Rather than reinventing the Web as we know it, use Ajax to build a “better Web,” an enhanced layer over what’s already there. Respect the conventions that users are already familiar with.
Further to the previous principle, Ajax is a richer brand of the traditional web site rather than a webified brand of the traditional desktop. True, desktop widgets like sliders are migrating towards Ajax, but only when they make sense in a web context and often in a modified form. We’re also seeing application categories like word processors head online as well, but again, the best products will be those that fit in with the Web rather than blindly replicating the desktop experience.
Subtle differences confuse people. If you’ve decided it makes sense to diverge from a standard or a common idiom, ensure your design is distinct enough to avoid confusion.
Affordances (http://en.wikipedia.org/wiki/Affordance) are as important as ever in Ajax. You may have a fancy new drag-and-drop technique for updating a form, but will the user even know it’s possible? Visual design, dynamic icons, and status areas all help here.
Avoid the start-stop rhythm of conventional web apps. Full page refreshes are a distraction and a time-waster. If used at all, they should be reserved for significant, infrequent activities such as navigating to a conceptually new place or submitting a large form.
Application preferences haven’t been very important on the Web. Why bother personalizing background colors for a shopping site you use once a month, especially if it means sitting through a tedious sequence of form submissions? But for some web applications, the user might be spending eight hours a day working with them, and customization suddenly feels a whole lot more useful. With Ajax driving the customization process, it’s a lot easier too.
Ajax makes the Web a lot more fun than it used to be. Techniques like visual effects, drag-and-drop, and periodic updates are sometimes labelled “gimmicks” or “eye candy,” as if users don’t actually enjoy those things. Applied with care and ideally, user testing, they can definitely add real value, even in “serious” applications.
Because Ajax is firmly based on standard browser facilities, there’s simply no getting around the many constraints imposed by modern browsers. If you seek the benefits of a rich web application that will run immediately on any modern browser, and you consider usability to be critical, then you can only use whatever hacks are necessary. You might well lament that Ajax development is inherently troublesome and pine for a cleaner way to get the job done (I know I do). But the point is that you don’t get a lot of say in what the vast majority of the world is already using, and will continue to use in the next few years. Maybe web development will be neater one day, but here in the present, the land of reality, it’s advisable to deal with the technology at hand and work around—or exploit—whatever cheap tricks are available if they ultimately enable useful functionality that would otherwise be unachievable.
The browser-server communication of an Ajax App is asynchronous by nature. This leads to several risks: users might not be told that a call has failed or timed out; calls might be processed in a nonatomic manner; or the browser might forget why a call was made by the time its response has arrived. As explained in several patterns, there are techniques available to monitor and control calls so that these situations don’t arise.
If there’s frequent network activity, you’ll want to think carefully about the size of the messages being passed back and forth.
When people talk about “how fast” their connection is, they’re usually discussing throughput rate; e.g., “a 4 megabit connection.” That’s great for downloading large content, but what about interactivity? Latency—basically the time for a bit to travel between browser and server—is usually more important than throughput rate (http://richui.blogspot.com/2005/09/ajax-reducing-latency-with-cdn.html). In web apps where the server may be halfway across the world, you can’t reasonably respond to each keystroke or mouse movement due to latency overheads. The challenge is to make the application feel responsive while reducing the frequency of interactions. Techniques like Submission Throttling and Predictive Fetch make the trade-off by decreasing frequency but increasing the amount of data sent each time.
Where a browser doesn’t support advanced features, Ajax applications should gracefully fall back to use whatever is possible. In an ideal world, the same functionality would still be available, albeit with less bells and whistles. But even if you need to sacrifice functionality—and you often will—it should be done in a graceful manner. (Think “polite error messages” and not “complicated stacktraces.”)
The Ajax Patterns show how people have used the design principles effectively in real-world Ajax applications. It might seem funny that we can have so many patterns about Ajax, a term that was coined only a few months before work on these patterns began. However, the ideas are not new; there were many Ajax features on the Web before the term came about to describe them. The healthy Net economy has helped a lot too, with hundreds of new sites now using Ajax, along with powerful tools (RSS, Technorati, Google, and wikis) to locate them as soon as they’re available.
With over 60 patterns, it’s useful to classify the patterns hierarchically. At a high level, the book is divided into four parts, each corresponding to a different focus area—Foundational Technology, Programming, Functionality and Usability, and Development. Beyond that, each part is divided into several chapters, where each chapter includes related patterns. For instance, Foundational Technology Patterns (Part II), includes Web Remoting (Chapter 6), which includes several patterns for web remoting. Here’s a summary of each part:
The foundational technologies are the building blocks that differentiate Ajax from conventional approaches, and this section explains typical usage.
These are the features of architecture and code that serve the software design principles listed previously. These include, among other things, design of web services; managing information flow between browser and server; populating the DOM when a response arrives; and optimizing performance.
These are the things that matter to users, including widgets and interaction techniques; structuring and maintaining what’s on the page; visual effects; and functionality that Ajax makes possible.
These are process patterns advising on best practices for development, as opposed to all the previous patterns, which are “things” that live inside an Ajax application. The practices are about diagnosing problems and running tests.
Figure 3-1 shows where
the four parts sit in the context of an Ajax application. Most
patterns—those in the first three parts—are about the
product, while the remaining part, Development patterns, is
about the process. Of the product-oriented
patterns, the Foundational Technologies explain how to use the crude
web technologies such as
XMLHttpRequest and the DOM. At a medium
level are the Programming patterns, guiding on strategies to use these
technologies. At a high level are the Functionality and Usability
patterns. Overall, the Foundational Technology patterns are at the
core of the Ajax Patterns language; the remaining three parts all
build on these, and are fairly independent from one other.
On the inside covers of this book, you’ll find an alphabetically ordered reference of all the patterns, providing summaries and page numbers. The introduction to each part of the book and to each chapter also contains some summary information.
In addition, the following pages contain pattern maps for each of the four high-level groups—Foundational Technologies, Programming, Functionality and Usability, and Development. The diagrams in Figures 3-2 through 3-5 follow these conventions.
Foundational Technology pattern group
Pattern A “leads” to Pattern B
Patterns A and B solve a similar problem, but in different ways
How much real-world evidence exists for the pattern, on a 3-point scale and presented graphically? It’s a rather subjective estimate, but use the following icons as a guide:
Suggests the idea is purely speculative
Suggests there’s at least a proof-of-concept or an early usage
Suggests there’s a few established examples
Suggests the pattern is in widespread usage
This is a sketch to set the scene for the pattern.
A story is a typical scenario to explain how the pattern is used or what the benefit will be to end users. This pattern has been implemented. Each story is based on a “persona”—a fictitious person (http://www.evolt.org/article/Practical_Persona_Creation/4090/56111/)—to make the story more realistic. (And quite frankly, talking about specific people lets me say “he” and “she” instead of obfuscating the text with gender-neutral language!)
A small cast of personae is used throughout the patterns. Their names are mnemonic in that they reflect the personae’s roles. It’s cheesy, but it will hopefully help you remember what these people do without having to refer back here.
The stories in Foundational Technology Patterns (Part II) and Functionality and Usability Patterns (Part IV) are all “Goal Stories”; they illustrate how users interact with a system once the pattern has been implemented. Here are the personae used in all the Goal Stories:
A Bill-paying citizen with a wife, 2.4 kids, and a dog named after a contemporary sitcom character.
A Doctor with geeky tendencies.
A Factory Floor Manager, often stressing about machine safety and worker productivity.
A Project Manager for a perpetually overdue IT project.
A Retailer of high-class fashions.
A Socialite with plenty of time for social bookmarking, social blogging, and social tagging.
A Student with plenty of time for music and other hobbies not related in any way to his studies.
A fast-paced financial Trader, dealing in any asset type where there’s a buck to be made.
Then there are the stories in Development Patterns (Part V), which show how a Developer uses a particular pattern. These are present in all the “Programming” and “Development” patterns, reflecting the nature of those sections. There are two aptly named developers who appear throughout these stories:
A senior Developer, skilled in the various Ajax-related technologies.
A senior Developer, also skilled in the various Ajax-related technologies.
The problem that is being addressed.
The forces that arise in addressing the problem.
A brief solution statement (the first sentence of the section), followed by an elaboration of the technique.
Each decision is posed as a question. The decisions are not a FAQ section to help clarify the solution—such material would belong in the solution itself. Instead, they are “reusable decisions”—that is, decisions that will often arise once you decide to incorporate this pattern. There is no precise answer given, because each decision must be made pragmatically. The description can only guide you in making the decision, first and foremost by flagging that the decision is there to be made. And beyond that, by alerting you to the variables involved and the consequences of going in one direction or the other.
Real-world examples of the pattern at work. Where real-world evidence is lacking, proof-of-concepts and libraries are used instead. Some examples may not be strictly Ajaxian but are included to illustrate a particular point.
A code example and walkthrough.
Where the system is an Ajax Patterns demo rather than an external application, it’s usually a “Refactoring Illustration” because an earlier version is being refactored according to the given pattern. This is explained further at the end of this chapter. Note that Martin Fowler originally defined “refactoring” as a code change without any user-observable behavior change. I am using the broader definition, now in common industry parlance, of a small, incremental improvement, which may well be externally visible.
Other patterns that solve the same problem in a different way. These are often, but not always, Ajax Patterns documented elsewhere in this book.
Other Ajax Patterns that are somehow related to this pattern, other than the alternative patterns that would have appeared in the previous section. Usually, this means the Related Pattern is a possible follow-up pattern. It may also mean the patterns are somehow similar; e.g., they rely on the same technology.
A metaphor to help remember the pattern. Some people will find this annoying (and should therefore skip over) and others might find it a helpful way to firm up their understanding of the pattern and help remember it later on.
Links to any original references and other useful material.
Most patterns in the collection were not just speculations, but were discovered from what others were actually doing. As well as the examples above and the initial Acknowledgments section, this section is a place where people can be acknowledged for their contributions.
The Ajax Patterns Demos appear in many patterns as Refactoring Illustrations and also in the Solution section. They’re all online at http://ajaxify.com/run/, and it would be worth trying them out. In addition, the full code base can be downloaded from that location; its installation is explained in the Appendix B. It includes the demos as well as completed code for Chapter 2. Note the demos have been tested on Firefox 1.5 and IE6, though most of them work on comparable browsers as well.
The server-side code is all PHP, but most of it is fairly trivial, so it should be fairly easy for all programmers to comprehend. PHP was chosen as it’s quite easy for anyone to set up, on any platform. Also, the language itself is fairly “generic” in that anyone with web development experience should have no difficulty following the code.
The demos are organized around a refactoring theme. For most of the examples, there is an initial, “embryonic,” Ajaxian application. Then, several parallel refactorings are applied to the same demo, each in a separate subdirectory. And each of these refactorings may have a further refactoring applied, contained in a deeper subdirectory. A tree structure emerges on the site, with each application having evolved in different ways.
For example, look at the evolution of Finite Cache Sum Demo (http://www.ajaxify.com/run/sum/xml/cached/expiry/), which has the path /sum/xml/cached/expiry/.
First, there is the basic demo at /sum/. Enter some numbers and the server responds with a sum. As a basic Ajaxian application—with no form submission involved—there are some foundational technologies illustrated here, but that’s about it.
Next, the sum is refactored to receive results in XML form, as a demo is done for the XML Message pattern. The “xml” prefix on the URL tells you its lineage.
One benefit of the new XML form is its convenience for caching, so a further evolution is a basic cache. This is a refactoring illustration for the Browser-Side Cache pattern.
Finally, the cache undergoes further improvement. This time, a concession to the laws of physics is made, and the cache is now of finite size. Unused elements expire. So here’s a further refactoring illustration for Browser-Side Cache.
This chapter has covered how people are designing for Ajax and introduced the Ajax Patterns. The pattern language (just like Ajax itself) isn’t a magic bullet, but a tool intended to improve your mastery of Ajax web development. You can use it as a reference for “quick-fix” problem solving, but you probably gain more if you also treat it as an educational resource to learn more about the recurring problems and solutions in Ajax. The remainder of this book constitutes the patterns themselves, divided into four parts according to their area of concern—Foundational Technologies, Programming, Functionality and Usability, and Development.