Usable AJAX Web Applications

From: Anthony T. Holdener (2008) Ajax: The Definitive Guide, Sebastopol: O’Really

The usability of an AJAX Web application refers mainly to how easy the application is to navigate and manipulate, and how intuitive it is to the end user. If an application is usable, it is

  • Structured … organised in meaningful and useful ways. Related parts of a page are placed together and unrelated parts are separated, based on a clear model that the user recognises…
  • Simple… common tasks should be easy to accomplish. Communication between the application and the user should be basic in nature, avoiding technical and complicated language and jargon.
  • Tolerant … flexible in how they handle mistakes … allows for easy cancelation and backtracking of user submissions and navigation… gracefully handles incorrect user input, and does not break or produce errors from such cases. Most important, tolerant Web applications make every effort to prevent most errors from reaching the user, and instead make reasonable assumptions about user intent and act accordingly.
  • Reusable … reduces the amount of information the user needs to remember and rethink each time she reacts to a pge or control on the application. Consistent navigation tools, site structure, naming conventions, and so on allow the user to navigate the application without stopping to think about every action. Being reusable boils down to being consistent.
  • Receptive … of user feedback – whether it takes the form of criticism, suggestions, or praise. … A receptive developer (…) thinks about the user, and designs with that user in mind.

p. 141 – 2

You should follow these six principles when designing Ajax Web Applications:

  • Minimalist and aesthetic structure (Personal Comment: What is an aesthetic structure???) … An application’s structure is the most important aspect of its usability.
  • Flexibility and efficiency
  • Consistency
  • Navigation
  • Feedback
  • Documentation and Help

p. 148

You should ahere to the following four factors when designing an applications’s page layout

  • Balance
  • Density
  • Focal point
  • Consistency

p. 158

Faceted Search

  1. Decide on your filter value-selection paradigm—either drill-down or parallel selection.
  2. Provide an obvious and consistent way to undo filter selection.
  3. Always make all filters easily available.
  4. At every step in the search workflow, display only filter values that correspond to the available items, or inventory.
  5. Provide filter values that encompass all items, or the complete inventory.

G. Nudelman: Best Practices for Designing Faceted Search Filters

Juggling with Excel, Omnigraffle, Numbers, Keynote, and Powerpoint

You want to compile a presentation using graphics from across different applications like Excel, OmniGraffle, and Numbers? Apple Keynote turns out to be the most flexible tool in order to bring everything together.

  1. Write and structure your presentation in an outliner tool (e.g OmniOutliner).
  2. Create Keynote document. Choose or create appropriate master sheets. Avoid decorative bullets for lists – they might cause problems to export as Powerpoint.
  3. Copy and paste text (“match style”) from outliner into Keynote – section by section in order to avoid formatting confusion in Keynote.
  4. After having completed one or two pages, export a test .ppt document to review in Powerpoint. If there are export-problems, delete master sheet(s) that cause the rouble (most likely tose with fancy bullet points). The same applies, if the exported .ppt version does not look exactly the same as in Keynote.
  5. You can easily copy and paste charts from Excel and (individual or multi-selcted) graphics from Omnigraffle into Keynote. Both charts and graphics are vector-based and fully scalable in Keynote.
  6. I found Keynote to be the only application that allows placing formated data-tables from Apple Numbers (when it comes to presenting tables, I prefer Numbers to Excel, it is so much quicker to produce presentable data!). Copying and pasting a data-table into Keynote will transfer the object into a fully editable Keynote table.
  7. Export final presentation to Powerpoint. Why? In order to make it editable for proof-readers, project-managers or other non-Mac users (e.g. clients)! If all-too fancy styles and features have been avoided (see 2.), the presentation will look exactly the same and re-touching is not necessary. Tables placed from Numbers into Keynote will appear as formated table in Powerpoint and can be edited.
  8. Before printing out from Powerpoint, check ‘Page Set Up’ to reflect correct settings for the printer

Interestingly, graphics imported from OmniGraffle into Powerpoint will remain scalable (unless it is already a bitmap graphic), whereas if you directly import them into Powerpoint, they are transformed into a non-scalable (and somewhat blurry) bitmap image.

Note: If you have copied and pasted a complex table from Omnigraffle into Keynote, you might find it pixelated in the final Powerpoint document. In that case, export the Omnigraffle document as a Visio file,. open Visio on the PC, copy the table and paste it into Powerpoint.

Web copy

    Some rules about how to write for the Web:

  • Use a tone of voice that reflects each brand’s personality.
  • Always use plain English and avoid technical or marketing jargon.
  • Use active and direct verbs to make the copy dynamic and lively.
  • Use short words, sentences and paragraphs to keep the copy punchy and easy to scan.
  • Use “we” and “you” to make the copy welcoming and personable in tone.
  • Keep the copy short (ideally 250 words per page, up to a maximum of 500) and break it down into bite-sized chunks and paragraphs.
  • Highlight key points and break up pages using bullet points.
  • Use headings to introduce short paragraphs so users can decide whether they want to read these.

Workshop: Card Sort

The aim of a card sort is to establish consensus among people about how content should be grouped and categorised. A pile of cards with topic items represents the content of a website. People sort these cards into groups and provide a label for each newly formed category. The group-discussion reveals difficulties in establishing consensus as people’s views on topic items tend to differ considerably.

An online card-sort allows to involve a larger number of people and provides statistical confidence in the result. People do the exercise individually on the Web. The aggregated results of the card sort reveal patterns (clusters) of related items, which form the basis for a content model and the site-map.

    To consider when doing the card sort exercise:

  1. Categories should be mutually exclusive (e.g. Red, Green, Blue – Better not: Red – Soft – Blue)
  2. Categories can have subcategories (will be formed at a later stage in the process)
  3. Put easy cards first; add the difficult cards later.
  4. Avoid ‘Miscellaneous’ as a category.
  5. If you can’t find consensus for one item, the majority vote decides.

Workshop: Rapid Prototyping

A prototype is a visual outline of the interface and an efficient way of experimenting with ideas. It is built to be tested with users in order to get better ideas. A rapidly built prototype helps designers to fail faster and to succeed quicker.

    The three mantras of rapid prototyping:

  1. Think user! Put yourself into the shoes of the user and consider needs, expectations, and constraints.
  2. Start broad – go narrow! Don’t get lost in details.
  3. Be pragmatic! Don’t get emotional with your ideas. There is always more than one solution to a problem.


What to consider when doing a prototype:

1. Page lay-out – How can I organise content on the page effectively and appropriately?

    Think about:

  • The layout-grid for this page
  • Meaningful sections and different levels of headlines
  • Other content items: Images, Featured items, Comments, Ratings …

2. Signposts and Navigation – How can I facilitate site- and page-navigation that is consistent, easy to understand and helps users finding stuff.

    Think about:

  • Menus and subsidiary menus
  • Contextual links (from within the recipe)
  • Buttons where necessary
  • (Meaningful labels for the menus, if not produced in the card-sort workshop)

2. Functionality – What do I need to offer in order to give the user maximum value for visiting the page.


  • Comments and ratings
  • Sharing content with others
  • Printing a recipe
  • Finding similar items
  • Anything else?

OmniOutliner (v 3.5) Printing Problems

I love OmniOutliner and it has saved me lots of valuable time for all the projects I’m working on. A really annoying bug, which the Omni guys haven’t been able to fix in version 3, is printing (either to PDF or on paper) a document that has multiple columns. In some instances, what you will get is only a SUPER MACRO view of the upper left corner of your document. I haven’t figured out the logic behind this bug, but it occurs again and again, and it happens when you have changed the Page Setup from portrait to landscape or vice versa. You won’t be able (?) to fix the bug with just changing settings.


  1. Change Page Set-up to the format that you need.
  2. Export the document in OmniOutliner 2 format
  3. Close the document and open the exported document in version 3 (you will be asked to upgrade the document)
  4. Voila. When you print now, you The only annoying thing is that you might have to fix design issues caused by down/upgrading.

Using diagram-styles in OmniGraffle

Theory: OmniGraffle creates automatically a diagram from any OminOutliner file – just great for creating and iterating/changing sitemaps. You open the OO document in OG and you will be asked to select a certain diagram-style from a list that contains pre-defined or self-created diagram-styles (which is essentially a small sample of the model-diagram that you save in a particular format in a particular folder).

Praxis: This works fine if the diagram is rather small/simple AND if you are happy with either strict top-to-bottom or left-to-right arrangement. Auto-Diagramming is useless if you need to assign different arrangement directions for individual levels (a necessity to fit a complex sitemap on one page). If you create a diagram-style with both horizontally and vertically arranged layers, you will realise that these ‘subtleties’ will be ignored. Applying this style to a diagram will force all layers to follow (usually?) a top-to bottom arrangement. You will end up moving objects around, fiddling with automatically created connection lines and spending probably more time changing the diagram than you would by just creating one branch manually and copying/pasting/editing this branch to the remaining sections of the sitemap.