Pattern Languages For Usability (PLUS)

Putting the Patterns in Context

My thesis was an investigation of design reuse in human-computer interaction. Several techniques were considered, including design patterns. But "design patterns" is a very broad concept; thus, three different approaches to design patterns were considered. The three resulting pattern languages are summarised here.

Published Papers: These are the most important papers published during the thesis.

• Index of All Thesis Papers, with full abstracts ...
• Usability Pattern Languages: The "Language" Aspect Surveys HCI pattern approaches to demonstrate that constraints on the scope -- e.g. internationalisation (sometimes referred to as "internationalization"), safety-criticality -- facilitate produce well-connected pattern languages.
• Principles for a Usability-Oriented Pattern Language Includes a summary/analysis of usability style guides.
• Brainstorming with Generic Tasks: An Empirical Investigation A non-pattern approach to design reuse: generic tasks, such as "Copy", "Preview", "Compose".
• Reusing Knowledge about Users Another non-pattern approach: organisation-wide user profiles.

The pattern languages are summarised below.

How the Languages Vary

At a superficial level, the languages vary in their scope, i.e. the type of system they can support. However, a deeper point of variation is their integration of HCI issues with detailed design/implementation. That is, the activities which would be performed by a requirements or HCI specialist, versus those which would be conducted by a software designer or programmer.

The Safety-Usability Patterns language is purely concerned with "high-level" system aspects - i.e. requirements, user-interface, usage context. (This language was developed in conjunction withth Andrew Hussey at the University of Queensland.)

The other two languages incorporate detailed software design, and in different ways. Planet begins with a number of high-level patterns, and then follows through to detailed design patterns which support their implementation. Thus, there is a distinct split between high-level and low-level patterns.

An alternative strategy to incorporation of detailed software design is followed by Multiple Model-View-Controller. In Multiple Model-View-Controller, each individual pattern is a hybrid of HCI and software design. Essentially, the language guides on developing scalable systems under the Model-View-Controller paradigm. This basic goal concerns detailed design, but each pattern also incorporates usability advice that developers should consider when architecting and implementing their MVC system. For example, how should typical user tasks (e.g. edit, create, remove) be supported under an MVC architecture? The solution takes into account software usability as well as code maintainability.

Planet Pattern Language For Software Internationalisation

• View The Language: View Planet
• Synopsis: Planet supports development of internationalised systems. It guides on development process, high-level design, and detailed software design.
• Credits: Developed under supervision of Lorraine Johnston.
• Pattern Summaries:
  • Global Data Model Encapsulate data required to support all cultures in a global data model, independent of the user-interface.
  • Preference Dictionary Encapsulate all of the user's current preferences, whether culture-specific or not, in a single dictionary (i.e. key-value pairs) entity.
  • Best-Guess Locale Create a ``global culture'' Preference Dictionary object which contains Universal Defaults. For each supported culture mentioned in your Export Schedule, create a Preference Dictionary object which overrides the global Preference Dictionary.
  • Independent View Create one or more views of the data model, and store the user's preferred view within the Preference Dictionary.
  • Expression Template Encapsulate each culture-specific expression in a template string. Store the template string in the culture's Preference Dictionary.
  • Flexible Strategy Create an abstract class which declares the interface for the algorithm, then create culture-specific implementations of this class.
  • Global Data Model Encapsulate data required to support all cultures in a global data model, independent of the user-interface.
  • Preference Dictionary Encapsulate all of the user's current preferences, whether culture-specific or not, in a single dictionary (i.e. key-value pairs) entity.
  • Best-Guess Locale Create a ``global culture'' Preference Dictionary object which contains Universal Defaults. For each supported culture mentioned in your Export Schedule, create a PreferenceDictionary object which overrides the global Preference Dictionary.
  • Independent View Create one or more views of the data model, and store the user's preferred view within the Preference Dictionary.
  • Expression Template Encapsulate each culture-specific expression in a template string. Store the template string in the culture's Preference Dictionary.
  • Flexible Strategy Create an abstract class which declares the interface for the algorithm, then create culture-specific implementations of this class.
  • Global Data Model Encapsulate data required to support all cultures in a global data model, independent of the user-interface.
  • Preference Dictionary Encapsulate all of the user's current preferences, whether culture-specific or not, in a single dictionary (i.e. key-value pairs) entity.
  • Best-Guess Locale Create a ``global culture'' Preference Dictionary object which contains Universal Defaults. For each supported culture mentioned in your Export Schedule, create a PreferenceDictionary object which overrides the global Preference Dictionary.
  • Independent View Create one or more views of the data model, and store the user's preferred view within the Preference Dictionary.
  • Expression Template Encapsulate each culture-specific expression in a template string. Store the template string in the culture's Preference Dictionary.
  • Flexible Strategy Create an abstract class which declares the interface for the algorithm, then create culture-specific implementations of this class.

Multiple Model-View-Controller (MMVC) Pattern Language

• View The Language: This work was done as part of my thesis, related to other concepts, and I am in the process of preparing a summarised form to place online.
• Synopsis: Patterns to deal with usability in safety-critical systems.
• Credits: Developed under supervision of Lorraine Johnston.
• Pattern Summaries:
  • MMVC Application Create a single Model to represent the state of the application at any time. Create a View of the Application Model which the user will execute when starting the program.
  • Domain-UI Separation Continue decomposing the Application Model until all Model classes are known and related to each other. Generate one or more View classes for each Model class, starting with the Application View.
  • Dependent Views When the View's Model is set, the View should store the Model, redisplay itself, and request the Model to send it property change notifications. At the same time, it should remove itself as a listener of any previous Models.
  • Model Summary Include controls on your View which summarise one or more properties of the Model.
  • Model Comparison Analyse user needs to determine when simultaneous Views are required. Then create these Views and use Dependent Views pattern to ensure they are synchronised.
  • View Placeholder When a containing View contains a contained View, (semantically) detach the two Views via a Placeholder, i.e. the containing View holds a Placeholder, and the Placeholder holds one object: the contained View.
  • Vector When there is a list of Models, use Vector Model and Vector View Catalog. Consider using these classes to support adding new Models, and editing or removing existing Models.
  • Vector Sort When the user requires lists to be able to be sorted in different ways, create Comparators to reflect the user's expectations, and pass them to Vector View Summary.
  • Model Chain When a View reflects a Model that is associated with other Models, request the View's Model to listen to the other Models.

Safety-Usability Patterns

• View The Language: Please refer to the papers page.
• Synopsis:A Software Framework, consisting of a pattern language and software library, for developing scaleable interactive systems.
• Credits: Developed with equal contribution from Andrew Hussey of the Software Verification Research Centre, The University of Queensland, while under supervision of Lorraine Johnston.
• Pattern Summaries:
  • Recover Enable users to recover from hazardous actions they have performed.
  • Stepladder Identify complex tasks and explicitly split them into sequences of simpler tasks.
  • Conjunction Reduce errors by requiring that the user perform tasks multiply.
  • Transaction Bundle several related task steps into a transaction, such that the effect of each step is not realised until all the task steps are completed and the user commits the transaction
  • Affordance Provide cues to an operator that enhance the likelihood that the operator will perform the physical actions appropriate to performing a particular action.
  • Separation Separate two controls (physically or logically) if they are operated in a similar way.
  • Distinct Interaction Distinct actions that can be confused, leading to hazardous consequences, should be accessed by distinct physical interactions.
  • Behaviour Constraint For any given system state, anticipate erroneous actions and disallow the user from performing them.
  • Abstract Mapping Provide an abstract representation of complex information so that it is comprehensible by the user.
  • Redundant Information Provide more than one way of viewing the information, so that the likelihood that it is misunderstood or ignored is lessened
  • Reality Mapping Provide a close mapping to reality where possible and supplement it with abstract representations.
  • Trend Allow the user to compare and contrast the current state with previous states.
  • Interrogation Provide ways for the user to request additional information.
  • Memory Aid Provide ways to record the completion status of steps.
  • Interlock Anticipate errors and place interlocks in the system to detect and block the hazards that would otherwise arise.
  • Automation Automate tasks which are either too difficult or too tedious for the user to perform.
  • Shutdown When shutdown is simple and inexpensive, and leads to a safe, low risk state, the straightforward solution is to shut down automatically.
  • Warning Provide warning devices that are triggered when identified safety-critical margins are approached.
  • Recover Enable users to recover from hazardous actions they have performed.
  • Stepladder Identify complex tasks and explicitly split them into sequences of simpler tasks.
  • Conjunction Reduce errors by requiring that the user perform tasks multiply.
  • Transaction Bundle several related task steps into a transaction, such that the effect of each step is not realised until all the task steps are completed and the user commits the transaction
  • Affordance Provide cues to an operator that enhance the likelihood that the operator will perform the physical actions appropriate to performing a particular action.

This work is licensed under a Creative Commons Attribution 3.0 Unported License.