Ajax App
Time your website with
WebWait - from the creator of AjaxPatterns.orgFrom Ajax Patterns
| Revision as of 14:44, 27 January 2009 69.46.207.58 (Talk | contribs) heading fix ← Previous diff |
Current revision 66.87.4.154 (Talk | contribs) Fixed 404'd URL, corrected title. |
||
| Line 99: | Line 99: | ||
| = Footnotes = | = Footnotes = | ||
| - | [1] Harry Fuecks explains essentially the same distinction as [http://www.sitepoint.com/blogs/2006/02/15/two-kinds-of-ajax-html-vs-client-soa/ "Client/SOA" versus "HTTP++"]. Likewise, Craig Shoemaker contrasts "Ajax Applications" with "Ajax Websites". | + | [1] Harry Fuecks explains essentially the same distinction as [http://www.sitepoint.com/two-kinds-of-ajax-html-vs-client-soa/ "HTML++ vs Client / SOA"]. Likewise, Craig Shoemaker contrasts "Ajax Applications" with "Ajax Websites". |
Current revision
There's an archived version of this pattern available, taken from the Ajax Pattern book draft, showing roughly how it appeared before the page became publicly editable.
Evidence: 3/3
Tags: Ajax, Balanced, Client-SOA, DHTML, Fast, Fat, Interactive, Platform, RichInternetApplication, Rich, Thick, Web2.0, WebApp
Goal Story
Pam's begun entering staff appraisals into a new Ajax App. She's pleased to see the data entry is much faster: fields are validated as soon as they're filled out, searches are integrated into the form rather than in annoying popups, and the remaining form fields keep mutating to reflect what she's entered so far.
Problem
How can you create a rich application?
Forces
See the first chapter, Chapter 1, for more details on the forces driving Ajax.
- Users like working and playing in the browser and are now more willing to keep their data online, but are nonetheless frustrated with conventional "click'n'wait" interfaces.
- Companies like web apps running on their intranets because it makes deployment much easier, but continue to be burned by unusable web apps that don't deliver the same value as a comparable desktop app.
- Developers are now well-versed in the basic patterns of web architecture, and ready to take on new challenges.
- Technology has opened up new opportunities for the web: broadband and beyond is becoming ubiquitous in many countries; servers can process huge quantities of requests per second; storage is growing to the point where it's feasible for individuals to host most of their personal data online.
Solution
Produce an Ajax App - a rich application capable of running inside any modern web browser. The user fires up an Ajax App by typing in a URL, clicking a link, or activating a bookmark. The Ajax App is then downloaded into the browser and the user can begin working with it immediately.
Ajax is fundamentally a user-centered pattern. As mentioned in the first chapter, the major force driving Ajax is the needs of users and their organizations to get more out of the web. For too long, people have endured pages that take forever to load, widgets that make no sense, forms that conveniently "forget" their data when they take too long to fill out. There are good reasons for people to continue using a browser, as noted in Chapter 1, but it's in the interests of website owners and employers to do a better job at making that interaction productive and enjoyable.
Ajax aims to improve user experience within the constraint of respecting browser standards. Standard-based design obviously has the benefit of portability, but also has a usability component in itself; users interact with hundreds of websites, and appreciate consistency, a quality that quickly erodes when you rely on plugins, browser-specific features, and "creative" design ideas. Sure, incorporate a novel widget or a funky layout when it works, but for most things, the standard ways works best.
Non-standard technologies also break consistency; one reason Flickr began migrating from Flash to Ajax was because users want to right-click to save images, a standard broken by Flash. Again, don't be afraid to use a technology like Flash to achieve something standard browsers won't do - that's the whole idea behind the Richer Plugin pattern. Some people will say it's not an Ajax App if it uses Flash, but the definition here would include a mostly-Ajax App that delegates to Flash (or other plugins) to fulfill some specialised task. In any event, the definition really isn't worth arguing about (after all, you can define "Ajax" however you like); the important thing is to ask what helps users - sometimes, it's better to incorporate some Flash or Java, other times a desktop solution really is the best approach.
The standard technologies are discussed in Chapter 1. They include several well-established technologies: HTML, CSS, HTTP, CGI, and form submission, Server-side scripting. In addition, there are several more technologies that are only now becoming seriously popular and standardised in the browser: Javascript, the Document Object Model (DOM), the Event Model (DHTML), Web Remoting.
Decisions
Will your application be "Ajax Deluxe" or "Ajax Lite"?[1]
There are two archetypal architectures for Ajax, and all applications lie somewhere along the spectrum between these extremities:
- Ajax Deluxe
- Ajax Deluxe uses Ajax to the max: applications feel similar to a desktop in that the browser is driving the interaction - it mediates all interaction between the user and server, so there are no - or few - direct page refreshes. Similarly, there's no need for session tracking in the server, because in the absence of page refreshes, all relevant state can be retained inside the browser script. The server need not know about HTML at all, and might just offer generic Web Services. An example is the Ajax calendar, Kiko.
- Ajax Lite
- An Ajax Lite App feels more like a conventional web app overall, but one that's been sprinkled with Ajax here and there. For instance, Ajax might be used to validate a form before it's submitted using standard form submission, or to reveal some instructions on the page when a user requests help. An example is Delicious, which works fine on legacy browsers, but offers Ajax Suggestions for the many browsers that support it.
Which will you use? The Deluxe approach suits a development team with more advanced web programming knowledge and access to relevant tools and cross-browser libraries, and will generally lead to a nicer, more effective, user-interface. It also facilitates a well-partitioned architecture, since the presentation logic can be completely isolated inside the browser and the business logic completely isolated in the server. However, Deluxe applications may place a strain on the browser and network capabilities, and might not even be possible if the browser is outdated. Ajax Lite is a better answer for older browsers, since the Ajax features can usually be "turned off" to support graceful degradation.
What browser requirements will there be to run your Ajax App?
One of the reasons why Ajax has taken off now, in spite of people having tried similar things earlier on, is that browsers are now more consistent. For an Ajax app, you'll need to decide which browsers you're targeting and which browsers just aren't worth the effort. XMLHttpRequest is the main constraint, because it usually appeared later in a browser's feature set than other foundational technologies. Roughly, we're looking at browsers from around 2001 onwards. A [typical guideline is: Internet Explorer 5+ for Windows, Firefox 1+, Mozilla 1+, Safari 1.2+, Opera 7.6+. Other browsers such as Netscape and Konqueror might be considered too. Whether you'll support all these browsers, or just a subset, depends on how important the diversity is, how much expertise or library support you have, and how much time you can devote to testing.
How will you treat browsers with insufficient technologies for Ajax?
Building on the previous point, what happens when your application requires features not provided by the browser being used. As explained in Cross-Browser Component, you can either check for specific features or you can check browser versions. If you do the former, you have the opportunity for graceful degradation - to cut out one specific feature, or provide a simpler alternative. It's more work, but lets you support more users. The alternative is to give up and suggest the user upgrade browser, sometimes the only thing you can reasonably do.
How much processing power will be required of the browser?
A few early Ajax Apps have already been bitten by assuming too much of the client-side environment. Unfortunately, Javascript doesn't execute too quickly, especially when the user has lots of browser windows open, as well as a music player, mail client, and the usual array of resident background apps. There's no well-established guidelines here, so the main thing to do is simulate the kind of environments your app will run in, and test, test, test.
How much networking capacity will be required?
With Ajax Apps, there are two networking factors to consider:
- Throughput (Bandwidth)
- How much data can be transferred per second?
- Latency
- How much time between a packet leaving the browser and arriving at the server? (Or vice-versa.)
In some cases, Ajax actually reduces throughput requirements by avoiding full page refresh. Yet, it's still important to consider, because there can still be a strain caused by patterns like Periodic Refresh, which continuously pulls down new data. When you consider that some Ajax features (e.g. Live Search) require round trips to the server on just about every keystroke, you can see why latency is becoming a growing theme in web design. For smaller packets, which are common in Ajax Apps, >latency is actually a much greater source of delay than throughput, especially across long distances. Again, it comes down to benchmarking and deciding what's feasible. If a round trip takes several hundred milliseconds, responding to each keystroke will probably cause more frustration than joy.
Real-World Examples
Please refer to the examples in Chapter 1.
Code Example
Please refer to the code examples in ???.
Alternatives
Related Patterns
All of the patterns in this language relate in some way to Ajax. In particular, the Solution above points to the foundational technology patterns that really define what Ajax is all about.
Footnotes
[1] Harry Fuecks explains essentially the same distinction as "HTML++ vs Client / SOA". Likewise, Craig Shoemaker contrasts "Ajax Applications" with "Ajax Websites".
