AJAX Patterns: Design Patterns for AJAX Usability

I’ve been putting together some AJAX design patterns.

Update (May 15, 2005): I’ve set up AJAXPatterns.org to keep working on these patterns. I’ve also cleaned up a couple of things here, although all future changes will occur at ajaxpatterns. Thanks to Leoglas for spotting two errors here.

Why AJAX Design Patterns?

AJAX holds a lot of promise for web usability, and the underlying technology has already delivered some stunning applications. But it’s no magic bullet. Careful design is always required, and it must be based specifically on the technology at hand. As AJAX emerges, we’re going to learn more about what sort of design works, and we’ll need ways of documenting this information and talking about it. Fortunately, the evolution of this particular technology will take place at a time when design patterns are well-entrenched in the industry, and design patterns are an excellent means of knowledge representation. Thus, it makes sense to begin cataloguing AJAX design patterns. These are some thoughts based on current examples and demo systems.

Patterns being patterns, there’s not a lot of unseen information here. Patterns are just a concise way to represent the knowledge embodied in the many AJAX applications that are out there. The point is to discover best practices by investigating how developers have successfully traded off conflicting design principles. AJAX is all about usability, so the patterns focus particularly on delivering usability in the face of constraints, most notably: user capabilities and expectations, bandwidth limits, the stateless nature of HTTP, the complexity of Javascript.

This is a work-in-progress. There should eventually be more patterns, more examples, more detailed explanations. And one more disclaimer: AJAX is a new term, but XMLHttpRequest and related technologies have been around for a while. I know that, but the introduction of a single umbrella term nevertheless constitutes a tipping point which is forcing web development to move heavily in a certain direction. AJAX is only a name, but names can be tremendously important.

Related Work

  • Thomas Baekdal’s AJAX Usability Guidelines contains some great advice and inspired me to write these patterns. What I’m doing here is not just stating different guidelines. Patterns ain’t principles, and the focus here is on patterns whereas the focus above is on principles. Both forms of design advice are vital. Here, I’m explicitly distinguishing between the two, because the patterns are intended to help designers achieve the principles. The principles here are heavily influenced by Baekdal’s guidelines.

  • fiftyfoureleven.com and AJAX Matters contain great collections of AJAX examples. You can’t have patterns without examples.

  • Joel Webber illuminates the technology behind Google Maps. Chris Justus dissects Google Suggest.

  • The recent AJAX podcast and blog entry covered some of the strengths and weaknesses of AJAX. The patterns here are supposed to guide on emphasising the strengths of AJAX without being struck by its weaknesses. The Polymorphic Podcast has also covered AJAX – prior to my podcast and is recommended as alternative overview on the technology.

Design Principles for AJAX Applications

  • Minimise traffic between browser and server so that the user feels the application is responsive.
  • Be clear on the interaction mode being used – regular HTML versus AJAX versus desktop application so that the user can predict what will happen next .. no surprises.
  • While avoiding confusion, borrow from conventions of HTML and desktop applications so that the user can rapidly learn how to use your application.
  • Avoid distractions such as gratuitous animations so that the user can focus on the task at hand.
  • Stick with AJAX wherever possible – just say no to entire page downloads so that the user’s experience is consistent.
  • Adopt AJAX for usability, not just to illustrate you’re hip to where it’s at so that the user is engaged, and not immediately driven away by your nod to website splash screens, <blink tags>, popup ads, and other usability disasters of websites which have gone to a place you don’t want to be.

Some (and eventually all?) of these principles above inform the patterns below. The patterns are about trading off among the principles, and also about resolving conflict between the needs of usability and other practical constraints, such as ease-of-development.

Architectural Patterns

Local Event-Handling You want the user experience to be dynamic and responsive, but it slows things down if you have to keep going to the server. THEREFORE, ensure most events are handled locally, resorting to server-side interaction only when there is no local facility. To increase the cases where local handling is sufficient, consider using Local Caches.

Local Cache You want to support Local Activity, but many events must be handled by resorting to data on the server. THEREFORE, maintain a local cache of information. The cache might be created on initialisation or accumulated after each query. When accumulating upon query, it’s probably worthwhile performing a predictive download.

  • Example: Websites have kept local information at hand for many years. Many forms cache a mapping from countries to states, for instance.

Predictive Download You want the application to respond quickly, but many user actions will require information from the server. THEREFORE, anticipate likely user actions and pre-load the required data. Note that this auxiliary information should ideally be downloaded after the main information has been loaded. A “background thread” might even be used to continuously monitor the user’s local behaviour, regularly pulling down information which might be useful.

  • Example: Google Maps downloads more than you ask, evidenced by the fact that you can move a little in each direction without forcing any new blocks to be loaded. Another way to see this is to compare what happens when you pan slowly versus quickly. Another example is International Herald Tribune, which caches entire articles to provide immediate gratification when you click on “next page” (an example taken from here. Google asks the browser to prefetch the first search result in case the user clicks on it.

Submission Throttling You want the application to respond quickly, but it will be overloaded if the server was accessed for every trivial input event. THEREFORE, instead of submitting upon each Javascript event, use the events to change local state. Store events in a buffer variable, or some DOM component, and frequently (e.g. once a second) poll to see if anything should be submitted. As a variant to periodic polling, check the time since last submission whenever a new Javascript event occurs. Note: If the period is long (e.g. 10 minutes), show the Synchronisation Status and consider allowing explicit submission as well.

Explicit Submission (An alternative to Submit Throttling.) You want the application to respond quickly, but it will be overloaded if the server was accessed for every trivial input event. THEREFORE, instead of submitting upon each Javascript event, require the user to explicitly request it, e.g. submit upom clicking a button. Ensure the user knows what’s been submitted with Synchronisation Status.

  • Example: Like many chat applications, the LiveChat demo requires you to click a “submit” button in order to complete your chat message.

Periodic Refresh You want the browser to be synchronised with the server, but information may change server-side after the user last made a change (e.g. because of another user on the same system). THEREFORE, the browser should periodically call the server so as to refresh any volatile information. Furthermore, indicate information staleness is with Age Displays.

  • Example: Open two browsers, and you’ll see that this chat demo polls the server for changes every few seconds.

Distinct URLs You want to let users send and bookmark information, but the application is dynamic and the results of XMLHttpRequest interaction will not alter the URL. THEREFORE, use a URL-based scheme or write distinct URLs whenever the input will cause a fresh new browser state, one that does not depend on previous interaction.

  • Example: A9 interacts via AJAX, but nevertheless provides a clean URL when you perform a new search. Google Maps has a “Link to this Page” link, which will always provide a link to whatever the user is looking at.

Display Patterns

Rich CSS You want the user-interface to be rich and colourful, but you have to minimise download size in order to make the interface responsive. THEREFORE, lean heavily on CSS to give a rich, graphical, appearance, without having to download images.

Embedded Text You want the-user interface to be rich and graphical, but you need plain text in order to support standard web functionality such as cut-and-paste and inspection by search engine robots. THEREFORE,integrate text into graphics, and rely on Rich CSS to show text when fancy styling is desirable.

Age Display You want the user to trust the system, but it’s possible some information on the browser is stale. THEREFORE, indicate the age of any critical information. Vary background brightness, for instance.

  • Example: SkyScanner is a non-AJAX price comparison site which shows how old its prices are. Many trading applications do likewise with stock quotes. I’m not aware of any AJAX examples at this stage; this pattern is purely speculative and likely to be relevant only to public websites which cannot justify frequent updates.

Synchronisation Status You want the user to rely on the system to capture the input, but not all input is immediately submitted because you are using Submit Throttling or Explicit Submission. THEREFORE, provide hints that indicate what’s synchronised and what’s pending. For instance, use a different background colour on text fields. This is important if you are using Explicit Submission or Throttling with a long period.

  • Example: Manoloweb’s wiki-like demo tells you when the edit has been submitted (although is possibly buggy as the message is always there?). (Note: Since web forms were born, many heads and fists have been banged against keyboards after information was lost to timeouts and shutdowns. AJAX is capable of solving this problem, and this pattern is part of the solution.)

Interaction Patterns

Nothing new here. All have been available in desktop GUIs and some in non-AJAX DHTML too. This is really just a catalogue of interaction styles that are becoming common idioms in AJAX applications and can benefit from XMLHttpRequest-driven interaction.

Drag-and-drop e.g. This demo

Popup data input

Popup information

Highlighting e.g. A9’s customisation feature highlights search plugins you select them.

Drilldown e.g. Betfair’s Sidebar Menu.

Auto-Completion Most famously, Google Suggest.

Coding Patterns

Browser-Agnostic Components You want to make the system interactive with sophisticated DHTML, but portability can suffer. THEREFORE, encapsulate units of DHTML activity into browser-agnostic components. A “component” may simply be a Javascript function with a bunch of if-statements, or a factory in an Abstract Factory hierarchy, or a server-side, Javascript generation object.

Server-Side Code Generation You want to make the system interactive with sophisticated DHTML, but sophisticated DHTML can be difficult. THEREFORE, use a server-side framework to generate the HTML and associated Javascript. Note that this pattern will become more useful as frameworks emerge.

Further Issues

… which will emerge as patterns.

  • RESTful architecture and treating server requests as API calls. There’s a lot of scope for XMLHttpRequest to be dealing with a generic, public, API. For instance, it didn’t take long before Google Maps had been recruited as a geographical API.
  • The “X” in AJAX. How should the response be structured?
  • Collaborative applications. How to deal with merges, pessimistic/optimistic locking, etc.

Your Thoughts?

I’m interested to hear what people think. Leave a comment or send an email to [email protected]

60 thoughts on AJAX Patterns: Design Patterns for AJAX Usability

  1. You forgot to explain “Synchronisation Flags”? At least I’m not sure what you mean and can’t find it.

    And google maps does keep an exact link available to the position your are looking at, (even after scrolling), that also includes your search terms! It’s at the right, ‘link to this page’. I used to be bugged (always linked to 1 zoom level higher then the one you had set) but that has been fixed.

  2. Hi Michael,

    Very interesting article and an excellent read. I do agree with the majority of your thoughts/guidelines.

    The things that are really interesting about this, is that each individual item is not that special. It is the combination that makes it brilliant. This is also why I like your patterns. Developers could pick a number of elements, combine them and make something really spectacular.

    XMLHttpRequest does and should rely heavily on client-side interaction and cache, but it needs two important things.

    1: The ability to work in separate work-threads, that is, client-side applications are really not good at multitasking. It is very hard to make you client side application do two or more things at the same time.

    2: Failure protection. By this I do not mean making sure the script works, but what if the user has used this for sometime. He has changed a number of things and then suddenly closes the browser? Well, if the application relies on client side cache then all the work is lost. This would be catastrophic, especially when web-applications become more advanced.

    Normal applications either stores the current state, allowing the user to get right back where he was – or alerts the user “are you sure you want to destroy all your hard work?”. Hardly any web-applications remember this. PS: if you can, do without the alert box, just save the users active state.

  3. Legolas,

    Thanks for the feedback. Synchronisation Flags is a typo and should be “Synchronisation Status”. Google maps link is indeed there: how could I have missed it? An interesting alternative design would be to actually show the URL on the page. However, it would probably be overly distracting. For the sake of RSS subscribers, I’m trying to avoid too many updates, but I’ll add it shortly. I’m in the process of creating a separate site to host these and other patterns (ajaxpatterns.org), so I can update at will.


    Glad to see this got back to you. While I’ve shied away from calling it a language at this stage, I think the interconnections are the true power behind any collection of patterns. So I’ve tried to emphasise how developers have been – or could be – combining different aspects of AJAX.

    Multitasking – and performance in general – may well be one reason to resort to the server, especially with the increasing trend of grid computing. Failure protection, likewise, is definitely an issue, and compromises must be made pragmatically. One thing that immediately comes to mind: The Local Cache pattern ought to distinguish between write caching, which is vulnerable to crashes, and plain old read caching.

    Saving state is interesting. AJAX-style applications should actually be able to prevent many of the disasters caused by users quitting the browser. Not always, by any means – as browsers can crash or the computer can be shut down. It just shows that developers need to take that into account in designing the breakdown between browser/server work. ie How long might a typical user be working on the browser without any updates? If a long time, maybe an Auto Backup facility is required, which would upload changes, just like on standard editors/word-processors.

  4. Pingback: Full(o)bloG » Blog Archive » sack!

  5. Pingback: Full(o)bloG » Blog Archive » sack!

  6. Pingback: Full(o)bloG » Blog Archive » sack!

  7. Pingback: Full(o)bloG » Blog Archive » sack!

  8. Pingback: Idiotprogrammer » Blog Archive » Ajax, Etc

  9. Pingback: Idiotprogrammer » Blog Archive » Ajax, Etc

  10. Pingback: devnulled: A blog by Brandon Harper » AJAX Design Patterns

  11. Pingback: :) derBumi.de » Blog Archive » Nein, AJAX ist kein Waschmittel…

  12. Pingback: :) derBumi.de » Blog Archive » Nein, AJAX ist kein Waschmittel…

  13. Pingback: meaningful chunks » Blog Archive » using ajax for creating web applications

  14. Pingback: meaningful chunks » Blog Archive » using ajax for creating web applications

  15. Pingback: WeBreakStuff » Pleasing Jacob Nielsen, Part 2

  16. Pingback: Mitayai » Blog Archive » ajax links from jason

  17. Pingback: Mitayai » Blog Archive » ajax links from jason

  18. I’m just becoming familiar with AJAX and have two issues that I wonder if you’ve got suggestions for. 1) How to prevent someone from using the URL in a XMLHttpRequest for their own purposes, basically robbing me of functionality? 2) If I have transformed XML into an HTML page and want to reuse that XML document with JavaScript inside the transformed HTML without making an additional server call (XMLHttpRequest), is there a way to do it?

    Thanks in advance for any ideas you have.

    — Michael

  19. MichaelR, (1) Well I guess the standard “Web 2.0” response would be “Just share it with the world and gain MINDSHARE“. But if you don’t buy that, consider a combination of things: strict legal notice, tracking by referrer and IP number and cookies (if someone hasn’t visited your site, why are they calling your web service?), email authentication, CAPTCHA authentication.

    (2)You can add the XML document as a node of an XHTML doc, if that’s what you’re getting at. See http://ajaxpatterns.org/XML_Data_Island.

  20. Pingback: Technology in plain English » Ajax Design Patterns -

  21. Pingback: Technology in plain English » Ajax Design Patterns -

  22. Pingback: Craig’s Musings » Blog Archive » Scrubbing bubbles and other cures for the common thin client application

  23. Pingback: Craig’s Musings » Blog Archive » Scrubbing bubbles and other cures for the common thin client application

  24. Pingback: WebWord » Blog Archive » AJAX Design Pattern: Read/Write Div

  25. Pingback: WebWord » Blog Archive » AJAX Design Pattern: Read/Write Div

  26. Pingback: robson.junior 2.0 » Juntão de Ajax

  27. Pingback: robson.junior 2.0 » Juntão de Ajax

  28. Pingback: Scriptorama » AJAX Pattern: Multi-stage download

  29. Pingback: Kamikaza » Blog Archive » Bookmark: AJAX

  30. Pingback: David Barkol : Recap -- MSDN Atlas Presentation

  31. Thomas,

    Yep, skyscanner was a trailblazer which existed since at least 2003 I think (definitely 2004), and a wonderful product. Fortunately there’s been plenty of travel sites coming up in Web 2.0 so there’s a whole lot more Ajax now.

  32. Pingback: Melastmohican’s Blog » Blog Archive » AJAX Patterns: Design Patterns for AJAX Usability

  33. We’ve been actively seeking and implementing AJAX tool sets into our on-line business management suite. Unfortunately we’ve found that time and again even organisations that have a significant amount of major contributors, like DOJO for example, have once again completely ignored generalization and true support for non-ASCII (e.g. non-English) languages. Implementing mulitple-language interfaces and the Unicode standard are hard enough on their own, but when the tools that are offered completely ignore these essential elements outright it becomes almost impossible to justify integrating them into our own software environment.

  34. Pingback: End of Silence - Freedom hating on the internets since 2002 » links for 2007-01-12

  35. Pingback: ArtLung Blog : Archives : » Daily Links

  36. Pingback: Japhy.at - Usability, Web 2.0 und das Leben in Wien » Archiv » del.icio.us Bookmarks vom 14.3.2007

  37. Pingback: Hello "Ajax" world! « Jack & Ajax

  38. “Ajax’s usability sucks, unless you keep it simple” there are a lot of problems when its used and the viewer has javascript turned off, or they are using a cell phone or ipod to view the pages

  39. Pingback: dykin's me2DAY

  40. Hi, great post. I come from java and find DP a great way to avoid unnecessary bugs. I’m nowadays implementing command pattern on PHP/AJAX. However, being a script language, it’s harder to work on DP.

  41. It’s a pity that all Ajax patterns described here and elsewhere do not start off with a fully functional example with no progressive enhancements.

    That is, with no CSS, no JavaScript, no Flash, etc.

    If the page communicates with the server then it would also be great to see the traditional, non-refactored server-side code, perhaps doing some server-side validation as part of its process.

    Only now are we in a position to add a better user experience. Refactoring the server code to separate parts of the process into modules (web services) that can now be shared with remote scripting from the client and progressively enhancing the client with CSS, DHTML and remote scripting.

    If we all followed this pattern, all sites would be totally accessible by everyone, no matter what their dis/ability.

  42. Willabee, as a big believer in unobtrusive Javascript, I fully support your views. The patterns above were written four long years ago, when the Ajax term had just been coined. The patterns on AjaxPatterns.org and in the corresponding book do embrace unobtrusive Javascript more. It’s not appropriate for all systems, e.g. full-blown games, but fortunately a major consideration within the web and Ajax community.

  43. Pingback: AJAX Design Patterns ! « Aleem’s Weblog

  44. Pingback: AJAX Design Patterns | KC-TUTOR

Leave a Reply