3.2. Designing for Ajax 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. 3.2.1. Usability Principles
Follow web standards 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.
The browser is not a desktop 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.
If it's different, make it really different 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.
Provide affordances 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.
Smooth, continuous interaction 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.
Customization 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.
Make it fun 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. 3.2.2. Software Design Principles
Embrace JavaScript Thanks mostly to the interest in Ajax, JavaScript (http://www.crockford.com/javascript/javascript.html) is no longer seen as a basketcase language to be avoided at all costs. It can actually be surprisingly powerful (cut the sniggering already!), provided that developers are willing to study the idioms, patterns, and idiosyncrasies.
Accept workarounds where necessary 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 aroundor exploitwhatever cheap tricks are available if they ultimately enable useful functionality that would otherwise be unachievable.
Tame asynchrony 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.
Develop for compatibility Where JavaScript programming still has issues is in portability. At a syntax level, JavaScript is reasonably consistent across browsers, as the ECMA standardization process (an effort to define JavaScript standards; see http://en.wikipedia.org/wiki/ECMAScript) has generally been respected by all the major browser makers. However, it's still a moving target, so older browsers of any variety simply won't support some features. Moreover, the DOM remains a serious portability concern. Despite gradual improvements over the years, there remain many subtle differences, and we're set for more divergence in the future. Developing for compatibility means being explicit about which versions are targeted, using portable libraries where available, and architecting so that portability concerns are isolated from core logic.
Reduce bandwidth If there's frequent network activity, you'll want to think carefully about the size of the messages being passed back and forth.
Deal with latency 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? Latencybasically the time for a bit to travel between browser and serveris 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.
Partition into multiple tiers As in any web architecture, Ajax applications should use multiple tiers to help separate concerns. This advice is commonly misinterpreted as implying "keep the presentation simple," a mistake that unfortunately leads to pathetically barren user interfaces. Don't be afraid to create rich, intelligent user interfaces with JavaScript; just be sure to develop for compatibility and ensure your business logic is separate from your presentation logic. In addition, practice "unobtrusive JavaScript" and "unobtrusive CSS." That is, keep your initial HTML page clean by referencing external JavaScript and CSS files; no embedded JavaScript or CSS. JavaScript and CSS should be kept apart too; where possible, the script should change an element's display by switching its CSS class rather than micromanaging style information directly.
Go easy on the browser Unfortunately, your Ajax App will probably end up being one of many things running in the client machine. This is exacerbated by the fact that JavaScript is pretty slow anyway, meaning that you have to exercise restraint in how much happens in the browser.
Practice graceful degradation 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 functionalityand you often willit should be done in a graceful manner. (Think "polite error messages" and not "complicated stacktraces.") |
