 |
ERCIM News No.46, July 2001 [contents]
|
by Len Bass and Bonnie E. John
Some facets of usability such as cancellation, undo, progress bars, and others require software architecture support. Because they reach so deeply into the architecture of a system, these facets must be built into the system from its inception rather than added after an initial system design and user interface has been achieved.
Achieving usability for a computer system depends on a number of factors. The functions provided by the system must accomplish the intended tasks, fit within the work context of the user, be understandable and clearly visible through the user interface. The input and output devices and layout must be correct for the target user group(s) of the system and their physical work environment. The software architecture must be designed to support the user in the achievement of the necessary tasks. In recent work undertaken at Carnegie Mellon University, we have focussed on determining the facets of usability that require software architectural support.
Software architecture comprises the earliest design decisions for a system and, consequently, they underlie subsequent decisions and are the most difficult to modify. In previous work, the focus was on supporting the iterative design process by allowing the presentation and input/output devices to vary. This was accomplished by separating the presentation from the remainder of the application. Separation is an architectural technique that restricts the impact of modifications. Separating the presentation thus makes modification of the user interface relatively easy after user testing reveals problems with the interface. This approach has been quite effective, and is commonly used in practice, but it has problems. First, there are some aspects of usability that are not affected by separation and, secondly, the later changes are made to the system, the more expensive they are to achieve. Forcing usability to be achieved through modification means that time and budget pressures will cut off iterations on the user interface and result in a system that is not as usable as it could possibly be.
Our approach is more proactive. We identified a set of specific usability scenarios that have software architectural implications. This set currently contains 26 scenarios. Although we make no claim, yet, that these scenarios are exhaustive, they seem to cover much of what people typically mean by usability (eg, efficiency, learnability, some aspects of user satisfaction). For each one of these aspects, we identified an architectural pattern that enables the achievement of the scenario. We then organized these scenarios and patterns in a fashion we will discuss after we introduce an example.
Consider cancellation. Users require the capability to cancel an active command for most commands. It does not matter why they wish to cancel, they may have made a slip of the mouse or changed their mind, they may have been exploring the effects of an unknown command but do not want to wait. Once a command has been cancelled, the system should be in the state it was in prior to the issuance of the command. One architectural pattern for achieving cancellation is for the system to maintain a thread of control separate from that executing the command that listens for the user to issue a cancellation command. Furthermore, the component that implements the issued command must save its state prior to beginning work on the command so that this state can be restored if the user does, in fact, cancel the command. The architectural pattern we have produced for the cancellation scenario discusses these and other aspects of supporting cancellation.
Other examples are undo, progress bars for feedback to the user, and propagation of known information to input forms. This last scenario would support, for example, requiring the user to input name or address only once and then automatically filling in this information in portions of the user interface that require it.
Once we generated our 26 scenarios, we then organized them in two separate fashions. We organized them into a hierarchy that represents benefits to the organization from applying these scenarios. For example, ‘accommodates users’ mistakes’ and ‘supports problem solving’ are entries in this hierarchy. Each scenario was placed into one or more positions in the hierarchy. The second organization was into a hierarchy of software architectural mechanisms. ‘Recording state’ and ‘preemptive scheduling’ are two of the items in this hierarchy. Again, each scenario was placed into one or more positions in the hierarchy.
The hierarchies were then treated as the two axes of a matrix and each scenario was placed in the appropriate cells. That is, if a scenario provided a single benefit to the users and required a single architectural mechanism to be in place, then it would show up in a single cell in the matrix indexed by its position in the two hierarchies. The figure gives a small portion of this matrix.
 |
| A sample of four cells of the benefit/mechanism hierarchy. The full hierarchy is 9 benefits by 13 mechanisms, or 117 cells. |
For the designer, the matrix can be used in two fashions. If the desired benefits to the organization are known, then the matrix can be used to determine which scenarios are relevant to that benefit and which software architectural mechanisms should be included in the system to achieve those benefits. If one scenario is to be included in the system, then an examination of the matrix will yield other scenarios that could be incorporated into the system at a small incremental cost.
We have used these scenarios in three different design or analysis situations on two commercial and one prototype systems. The systems were a large financial system, a driver information system, and a multi-user meeting support system. That is, we have applied these in a variety of different domains. In each case, the scenarios discovered issues in the user interface design that would have otherwise gone undiscovered, at least through initial implementation.
Readers wishing more information about this work are referred to ‘Achieving Usability Through Software Architecture’, CMU/SEI-TR-2001-005.
Link:
http://www.sei.cmu.edu/publications/documents/01.reports/01tr005.html
Please contact:
Len Bass ó Carnegie Mellon University, USA
Tel: +1 412.268.6763
E-mail: ljb@sei.cmu.edu