I've attempted to summarise the various articles into a series of bullet points (but I haven't bothered to bullet them; it seems a bit redundant when they are all bullet points).

The goal of this summary is to give clear directives to designers and developers that should improve the uasbility of their software. It's all very well to discuss the pros and cons of various approaches, but to be really useful we should provide concrete advice that designers can use immediately.

The following points are the ones that I think designers can (and should) apply immediately i.e. they don't require any action from other parties (such as toolkit designers) before they can be applied.

• Get a memory. Software should remember what the user has done in the past and configure itself accordingly. Use most-recently-used lists, and replace configuration options with memory.
• Build simple application-specific agents to automate repetitive tasks, like email filtering. More powerful (i.e. more general) )application-independent agents require improvments to the GUI and Application toolkits.
• Use noun-verb structured task design.
• Standardise user actions so that they always have the same effect, regardless of context. Shortcut keys always do the same thing. Single and double-clicking has consistent behaviour.

Various bullet points

Task Design and Human Performance

The most important consistency principle is: consistent interpretation of user behaviour. Shortcut keys should always have the same meaning. Visual elements such as scrollbars, buttons, spinners must also be consistent. Where possible, standardise location as well as behaviour (OK and Cancel are always in the same absolute screen location). This is far more important than a consistent visual appearance.

Do not accept personal opinion about what is fast or efficient. People's subjective beliefs are extremely suspect. Only user testing (and a stopwatch) will tell the truth. There is no substitute for user testing. (Well maybe there is. Extensive user testing is not always viable, especially when resources are limited or distributed. Some user testing is essential. More investigation needed here.)

Structure the design so it is noun-verb oriented rather than verb-noun i.e. users choose the objects first, then the action. This should help reduce the amount of modal behaviour in the interface.

Use splash screens on startup, and other tricks to reduce perceived latency (for example, save an image of the app at last use and display this as it starts up).

Use existing knowledge. Make your interface work in a way that can be mapped onto something else that the user will be familiar with (this doesn't have to be a mapping to a real-world object; a mapping to another interface idiom is also OK).

Avoid metaphors. Try to create visual idioms instead.

Avoid cognitive excise (excise = tax). This is the cognitive effort the user must make to manipulate the interface, as opposed the effort spent thinking about the task.

• Limit user decision making. Don't have the user make decisions that the program can look up elsewhere. Provide the user with the information necessary to form decisions quickly and accurately. Communicate through the visual design what are assumed to be the high-probability answers. Dialogues that ask questions should not use Yes/No; this forces the user to tke an extra mental step such as "Am I saying Yes to deleting this file, or am I saying yes to keeping this file?"
• Decrease data entry. Use defaults from wherever you can get them.
• Reduce machine manipulation. Can this task be combined into a single step, rather than requiring two? Is this second screen necessary?
• Design the task to match the user's mental model. Avoid requiring users to make mental translations of the way they look at a task into a form your machine can understand. The most direct and natural approach is dependent not only on the task, but on the profile of your users.

Help the user navigate. Provide a command history and a navigation history. Allow them to move backwards and forwards though both histories, and to re-visit arbitrary locations. For command histories, this means allowing any command to be Undone/Redone at any point, rather than having to unroll as stack of commands.

Avoid rampant customisation.

• Customisation has the effect of delegating part of the interface design to the user. They may or may not be qualified to do this. Users are not usability experts; we are. If a user can, by a few judicious choices, really improve the interface, we probably have done a poor job. Most users, if given a reasonable interface, just want to get their jobs done.
• The user must not only learn how to use a new application, but also how to customise it.
• Extra features add to the size of the software and the documentation.

Graphic Design, Layout, Presentation

Use spatial layout to convey information, such as task navigation and internal structure.

Humans use colour to divide the visual space at the earliest stages of visual processing. Use colour to highlight important information, and to group objects of the same type.

Apply Fitts' Law. Use screen corners and edges, and use large buttons.

Use objective language. Do not use promotional language; it incurs a cognitive excise.

For reports and other electronic documents:

• Summary first.
• One idea per paragraph.
• Highlight key words.
• Meaningful headings (headings are highlighted like key word