Mix ’06 and Ajax Design Principles

‘Tis Goud reports from Mix ’06, Microsoft’s web bash currently happening in Vegas. One of the presentations focused on the most important thing about Ajax: Usability.

The session started with referencing two sites with information on:

Thomas’s guidelines were the first serious look at Ajax usability and a big inspiration for the Ajax Patterns.

The patterns and the principles were apparently distilled to this list:

  • Feedback
  • Predict
  • Preserve
  • Share
  • Controls
  • Separate

If anyone has more detailed info on this discussion, please let me know!

As it happens, the third chapter of “Ajax Design Patterns”, the overview to the patterns themselves, explicitly identifies principles on which the patterns were based. Principles and patterns go hand-in-hand, so any pattern language I’ve worked on always comes with a set of principles, an explicit reference point for people to grasp where the patterns are coming from. You can even (with some energetic hand-waving) look at the patterns as being defined around the principles: “These patterns are written such that if you follow them, your system will adhere to these principles”.

Anyways, the principles are broken into two groups: Usability Principles and Software Design Principles. Maybe I ought to podcast them sometime.

These are the Usability Principles for Ajax.

  • Follow Web Standards
  • The Browser is Not a Desktop
  • If it’s Different, Make it Really Different
  • Provide Affordances
  • Smooth, Continuous, Interaction
  • Customisation
  • Make it Fun

These are the Software Design Principles for Ajax.

  • Embrace Javascript
  • Accept Workarounds Where Necessary
  • Tame Asynchrony
  • Develop for Compatibility
  • Reduce Bandwidth
  • Deal with Latency
  • Partition into Multiple Tiers
  • Go Easy on the Browser
  • Practice Graceful Degradation

It’s funny. The very first thing I think of when I see stuff like this is along the lines “SHOW ME THE PATTERNS!!!!”. I’ve got no patience for motherhood statements like ‘Tame Asynchrony’. But the reason for this annoyance is because you usually see these kind of principles in the absence of any explanations, examples, or patterns. Once it’s apparent that the principles are merely a background to more concrete advice, their presence has been justified.

Leave a Reply