Usability and software architecture - Taylor & Francis Online

BEHAVIOUR & INFORMATION TECHNOLOGY,

2001,

VOL.

20,

NO.

5, 329±338

Usability and software architecture BONNIE E. JOHN and LEN BASS Carnegie Mellon University, Pittsburgh, PA 15213, USA; e-mail: [email protected]

Abstract. The role of software architecture with respect to usability has evolved over the past 20 years. The architectures of the 1980s and early 1990s assumed that usability was primarily a property of the presentation of information. Therefore, simply separating the presentation from the dialogue and application made it easy to modify that presentation after user testing. A more popular belief in the 1990s was that usability concerns greatly aVected system functionality as well as the presentation. This emphasis took attention away from architectural support (beyond separation). Achieving the correct functionality for a given system became paramount. It is our observation that even if presentation and functionality of a system are well designed, the usability of a system can be greatly compromised if the underlying architecture does not support human concerns beyond modi®ability. This paper will present a new role for software architecture in usability, preliminary research and practice stemming from this role and a research agenda for the future.

1. Introduction The fundamental goal of human ± computer interaction (HCI) is to improve the usefulness and usability of software systems. To that end, over the past 20 years researchers and practitioners in HCI have borrowed methods and theories from many disciplines and adapted them to the needs of interactive system design. Psychology, human factors, ethnography , graphic design and computer programming are just a few of the disciplines that have contributed to HCI. To eVectively borrow the most useful concepts, methods and theories, HCI professionals must keep an eye on related disciplines and notice what’s new, what’s `hot’, what’s matured into a truly useful tool, and what seems most relevant to HCI. One example is the recent panel at CHI 2001, `Patterns: What’s in it for HCI?’, and a companion special-interest-grou p meeting, where people discussed the application of design patterns from architecture (Alexander 1977), which has become widespread in the software engineering community in the last ®ve years

(Gamma et al. 1995). Another example is the topic of this paper, the role of software architecture in HCI. The relationship between software engineering (SE) and HCI has evolved over the last 20 years. Both ®elds have made headway towards creating useful and usable software systems. Both have explored many avenues to create high-quality software. In our opinion, however, these disciplines have proceeded too independently. Though the independence may have been necessary, even bene®cial, in the past, we believe it is important to re-examine the inarguable interdependence dictated by building the software artefacts that require the contributions of both ®elds. It is time to re-examine the relationship in order to move forward more eVectively. To illustrate, we will present an account of the history, current state of aVairs and the future of the relationship between usability and software architecture, two core concepts from the parent disciplines. Both ùsability’ and `software architecture’ are terms with varied de®nitions, almost as many de®nitions as there are authors writing about them. In addition, the ®elds of HCI and SE use similar terms diVerently. Therefore, we de®ne terms here for the purposes of this paper. We refer to the usefulness of a system as a composite of all aspects of the system that contribute to whether it accomplishes its task of truly aiding the people it was designed to serve. These aspects include its functionality (does it perform a needed service?), correctness, availability, performanc e and usability, to name just few. Usability is the attribute of a system that, assuming it performs a needed function, makes it easy and pleasurable to learn and use. We like Tom Carey’s notion: ìf your computer were a person, how long `til you punch it in the nose?’ (as quoted in Hix and Hartson 1993: 3) A usable system never deserves a punch. The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships

Behaviou r & Information Technolog y ISSN 0144-929 X print/ISSN 1362-300 1 online # 2001 Taylor & Francis Ltd http://www.tandf.co.uk/journals DOI: 10.1080/0144929011008168 6

330

B. E. John and L. Bass

among them. It is the earliest artefact in the development lifecycle that can be analysed in any meaningful or quantitative way. We now give a brief history of both usability and software architecture through the 1980s and 1990s to set the stage for our reporting of current research and future needs.

2. 1980s Prior to 1980, neither usability nor architecture were of much concern to the builders of software systems. Most systems were monolithic and both the user interface and the architecture were more emergent than designed. Getting the computer to do useful work at all within the con®nes of memory and processor speed was still the main challenge. Consequently, it was very hard to change a system in any meaningful way after it was built; speci®cations were top-down using a waterfall method of development, and user-testing, a technique from human factors and cognitive psychology, was used by the larger and more enlightened organizations (e.g., IBM and the Bell System). User testing gave rise to requests to change the user interface of a system once it was constructed. Since the construction of the user interface had to be done within the software architecture of a system, the initial connection between software architecture and usability came from the construction and maintenance of the user interface. A study performed within IBM during the mid-1970s (Sutton and Sprague 1978) attributed more than 50% of the cost of constructing and maintaining a system to the user interface. This led to the ®rst two major thrusts in the relationship between software architecture and usability: separation and user interface tools.

information and interaction with the system through a command-line or widgets. Thus, separation of the user interface from the remainder of the system plus user testing came to be viewed as a panacea for creating a usable system. If you totally separate any two things, they can no longer speak to each other directly. Thus, the user interface architectures that arose in the early 1980s had three fundamental portions: the user interface, the remainder of the system, and something to mediate between these two portions. The two primary usability architectures of the early 1980s were the Model-ViewController and the Seeheim architecture. Both of these architectures exist and are used today so the connections between usability and software architecture established twenty years ago were not erroneous, they were just not su cient as we will argue later. 2.1.1. Model View Controller. The Model-View-Controller (MVC) grew out of concerns of object-oriented programmers and is focused on the presentation of an individual object on the display. As originally described (Krasner and Pope 1988), the View determines the output of the object, the Controller determines the input to the object from the user, and the Model determines the actions of the object. A descendant of MVC is named PAC (presentation, abstraction and control) (Coutaz 1987, Bushmann 1996) where presentation determines both input and output, the abstraction determines the actions of the object, and the control mediates between the presentation and the abstraction. The distinction between these two software architectures is often lost in practice and so you will see references to MVC when what is meant is PAC. PAC introduced some other subtleties that we will not go into here. The focus on an individual object means that there are many MVCs within a system, one for each object. This is intended to provide for easy changes to the individual objects.

2.1. Separation of user interface A standard technique in engineering is the separation of concerns. This is manifested in software architecture as separating and isolating those portions of the system that are likely to change. If these sections are isolated behind an application-programmin g interface that does not change, then the rest of the system is not impacted by the changes that are expected to occur. Since the user interface is a portion of the system that is often modi®ed after user testing, separating the user interface from the remainder of the system simpli®es changes and makes them less costly. This was supported by a general perception in the early 1980s that the interface is `skin deep’, involved primarily with the presentation of

2.1.2. Seeheim. The Seeheim architecture (PfaV 1983) is focused on separating all of the presentation from all of the remainder of the system. Whereas MVC is focused on individual objects, Seeheim views the system in terms of layers. There is a layer where the presentation is managed, a layer where the remainder of the system is managed and a dialogue layer that mediates between the two other layers. The Seeheim architecture is seen today in the World Wide Web where all of the presentation is managed by a portion of the browser and in three tier architectures where the user interface is separated from the business logic that, in turn, is separated from the database.

Usability and software architecture The focus on managing the entire user interface from one layer is intended to provide for easy system-wide changes to the user interface. For example, changes in the output device, changes in particular widgets, and the use of user interface toolkits are all facilitated by placing all of the user interface logic in the same layer.

331

viewed by practitioners as more cumbersome than normal programming languages and they added an additional programming model beyond that of the programming language that practitioners resisted.

3. 1990s 2.2. User interface tools Once the user interface has been separated from the remainder of the system, regardless of the particular architecture, it then becomes feasible to construct tools to support the construction and maintenance of the user interface. There are two types of such tools, oriented toward diVerent portions of the separated system: user interface builders and user interface management systems. 2.2.1. User interface builders. A user interface builder constructs the presentation portion of the system. It assumes that the presentation will use a ®xed collection of interactors. Each interactorÐsuch as a dialogue box, a scroll bar or a text boxÐsupports a particular aspect of the interaction between the user and the system. These interactors are usually manifested in a user interface toolkit or framework. Since the interactors are independent from any particular system, they can be used independently both in a builder and in the ®nal system. The builder provides a graphical rendition of the user interface so that the interactors can be positioned and sized interactively. The user interface builder saves a description of the constructed user interface so that it can be used (usually in a quite easy fashion) by the ®nal system. User interface builders are a routine portion of the modern construction process. Each user interface builder has its own mechanism to support communication with the remainder of the system but there are few constraints on the remainder of the system and the dialogue (or controller) is outside of the purview of the user interface builder. 2.2.2. User interface management systems. User interface management systems (UIMS) (e.g. Bass and Coutaz 1991; Olsen 1992) construct both the presentation and the dialogue portion of the system. Most of them had an interactive user interface builder incorporated within them but they also attempted to constrain the interaction with the remainder of the system. That is, they provided the means for constructing both the presentation and the dialogue (or controller) of the system. UIMSs remained as research vehicles and never reached general practice. The means that they provided for constructing the dialogue (or controller) ended up being

The software development world entered the 1990s assuming that the problem of usability had been solved relative to the architecture of the system. Separation plus user interface tools supported rapid prototyping and iterative design. Software engineering assumed that rapid prototyping and iterative design of the user interface was su cient to produce a usable system, and, judging from the development practice, so did the HCI professionals. This premise allowed both communities to proceed independently, because both believed the answer already to be embedded in their systems and processes. Thus, HCI and SE went their separate ways. In the mid 1980s, Newell had preached to the HCI community that design, not testing, is where the action is (Newell and Card 1985, which reproduced the arguments in Newell’s plenary speech at CHI ’85). They refer to the `panacea’ of rapid prototyping and iterative design as being insu cient to produce truly useful systems. 1 This idea seemed to take hold of the HCI community in the 1990s. Looking back at the CHI conferences, for instance, the proportion of papers reporting empirical results of tests of diVerent aspects of interfaces (e.g. diVerent menu con®gurations or diVerent input devices) shrinks in comparison to papers describing prototypes of innovative systems. The ®eld concentrates instead on HCI involvement in the functionality of a system in addition to the design of information presentation and interactive widgets. This direction of the HCI ®eld acknowledges that human ± computer interaction is more than screen deep, and reaches into the application modules of a system to de®ne what tasks it can accomplish. Methods were developed for understanding work in context (e.g. contextual inquiry, Beyer and Holtzblatt 1998) and using that understanding to inspire and guide functional requirements as well as interaction design. However, there are extremely weak, if any, links to the architecture of the system in this HCI work. UIMSs are abandoned as a research topic and never become prevalent in industry. HCI professionals are rarely trained in software architecture design and, frankly, do not understand its implications for the ultimate usability and usefulness of a system. In parallel, the concept of software architecture takes oV in the SE world. A ¯urry of books was written on the subject (e.g. Shaw and Garlan 1996, Bass et al. 1998)

332


and the ®rst Working Conference on Software Architecture was held in 1999. Rather than simply describing the emergent structure of a system, the architecture becomes an object of deliberate design and analysis in methods like SAAM (Kazman et al. 1996) and ATAM (Kazman et al. 2000). Architectures are designed and analysed to facilitate the realization of quality attributes. Quality attributes are those aspects of a system that are of value to the organization building or buying a system. Software engineering in the 1990s focused on technical attributes like performance, availability and security, or process attributes like modi®ability and maintainability. Although usability is mentioned occasionally as a quality attribute, some authors explicitly declare that it is not related to architecture beyond the aforementione d separation in support of iterative design. For instance, our own writing re¯ected this view: many aspects of the quality of usability are not architectural; making the interface clear and easy to use is primarily a matter of getting the details correct . . . Although these details matter tremendously to the end user and in¯uence usability, they are not architectural because they are almost always encapsulate d within a single component. This localization aVects modi®ability but not usability. (Bass et al. 1998) Thus, by the late 1990s, the software development world has arrived at a view of system construction that includes design at several levels, e.g. presentation, dialogue, functionality and architecture (®gure 1). Quality attributes are used to guide that design from the SE side, but usability is not routinely included in the list of quality attributes. HCI professional s in¯uence design at the levels of presentation, dialogue and

functionality. But the fundamental premise that usability is not architecturally sensitive beyond separation of the UI remains in force and prevents either discipline from exploring further the relationship between usability and architecture.

4. 2000 We have reached the 21st century, and the 20th year of this journal, with much improved computer systems. More people, with a broader range of training, are using computers than ever before. This level of usefulness and usability was unthinkable two decades ago. However, there are still problems in the systems that permeate our lives. In the desktop computing world, for instance, applications are still not routinely usableÐwe still want to punch many of them in the nose (or, for the less aggressive among us, we blame ourselves for not being able to use the things). We ®ght with our text processors to put the pictures in the right place. We start an o ce pool when our organization switches ®nancial systems, wagering about when the ®rst trip expense report will be processed successfully. Usability is such a constant annoyance for many of us that we turn to joking about it rather than punching the monitor. Even when the functionality ®ts our needs, the software development process based on rapid prototyping, user testing and iterative design seems to have stopped short of delivering usable products to our desks (and laps and handhelds). In addition, the role of many HCI professional s seems to be squarely in the arena of testing or evaluation. For example, the Usability Professionals Association is 1600 members strong and their conference contains many presentations about testing and evaluation techniques

Figure 1. Software system design in the late 1990s. (Software engineers participate in all aspects of design ± white background ± whereas HCI professionals ± hashed background ± are not involved in the design of the architecture. Usability concerns are brought to bear on presentation and interaction design, but also do not reach to the architecture.)

Usability and software architecture and how to communicate test results to eVect change. The panel at CHI2000 entitled `Scaling for the Masses: Usability Practices of the Web’s Most Popular Sites’ revealed user testing as the main, and sometimes only, technique used by the organizations hosting these sites. The Human Factors and Ergonomics Society has an active community concerned with computer systems and the presidential address in 1999 called yet again for an end to `sweeping up after the parade’ (Woods 1999). The dominant software development process, with its reliance on and support for iterative testing and redesign, forces the usability professional into the role of `nag’, an unhappy position ®lled by Human Factors personnel since the 1940s and recreated in the computer age. It is undeniable that the HCI and SE work of the past two decades is good work. Separation of the UI and user interface tools are an enduring part of the development landscape because they do facilitate the programmers ’ job. User testing and iterative design has become routine because they do produce more usable systems. But these advances have not gotten us beyond wanting to punch a lot of the computer systems we encounter. Most of the computer systems in our world do perform functions that are necessary or at least desirable, but it seems to be little details that elicit that negative response. Not being able to copy-and-past e errors messages from a dying application into an e-mail message to the help desk; frantically hitting the cancel button after a slip of the mouse with no response; this is the level of annoyance that permeates our days and lowers the quality of computer-base d lives. Given that our fundamental assumptions have brought us to this state, it is time to re-examine those assumptions . As quoted above, Bass et al. (1998) wrote, `making the interface clear and easy to use is primarily a matter of getting the details correct’. We agree! But they continue, Àlthough these details matter tremendously to the end user and in¯uence usability, they are not architectural because they are almost always encapsulated within a single component’. This is the fundamental assumption we have challenged in the past two years. Perhaps many of the details important to usability are not encapsulated within a single component. Perhaps many are architecturally sensitive. Perhaps the test-and-redesign development paradigm is ¯awed because early architectural decisions preclude good usability and no amount of user data or nagging about it will be able to change the architecture by the time user testing is complete. In recent work undertaken as a collaboration between the Human ± Computer Interaction Institute and the Software Engineering Institute, both at Carnegie Mellon University, we have focused on determining what facets of usability, if any, require software architectural

333

support. We generated a list of general usability scenarios by surveying the literature (e.g. Nielsen 1993, Newman and Lamming, 1995; Gram and Cockton 1996, Shneiderman 1998), by personal experience and by polling colleagues for their ideas. We ®ltered the scenarios by determining if a reasonable implementation needed to reach beyond a single software component devoted to the UI, that is, if it required architectural support beyond separation. For example, a scenario about the language used in error messages being clear to the user would not require additional architectural support because changing the words in an error message resides only in the UI component. However, a scenario about cancelling commands requires the cancellation command to interact with both the user and the application components of a system. Our set of architecturally sensitive usability scenarios currently contains 26 scenarios about individual use of desktop systems. Although we make no claim that these scenarios are exhaustive, they seem to cover much of what people typically mean by usability (e.g. e ciency, learnability, some aspects of user satisfaction). For each one of these scenarios, we identi®ed an architectural pattern that enables the achievement of that scenario. An example can be found in the appendix. Once we generated our 26 scenarios and their architectural patterns, we then organized them along two dimensions. Using a bottom-up process (a nity diagram, Beyer and Holtzblatt 1998), we organized the scenarios into a hierarchy that represents usability bene®ts to the organization from applying these scenarios. For example, àccommodates users’ mistakes’ and `supports problem solving’ arose as entries in this hierarchy. Each scenario occupies one or more positions in this usability bene®t hierarchy. The second organization was into a hierarchy of software architectural mechanisms. `Recording state’ and `pre-emptive scheduling’ are two of the items in this hierarchy. Again, each scenario occupies one or more positions in the architectural mechanism hierarchy. The hierarchies became the two axes of a matrix and each scenario was placed in the appropriate cells (®gure 2). For the designer, the matrix can be used in two fashions. If the desired bene®ts to the organization are known, then the matrix can be used to determine which scenarios are relevant to that bene®t and which software architectural mechanisms should be included in the system to achieve those bene®ts. In addition, if the solution to 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. Readers wishing more information about this work are referred to Àchieving Usability Through Software Architecture’, CMU/SEI-TR-2001-

334


1, aggregating data; 2, aggregating commands; 3, cancelling commands; 4, using applications concurrently; 5, checking for correctness; 6, maintaining device independence; 7, evaluating the system; 8, recovering from failure; 9, retrieving forgotten passwords; 10, providing good help; 11, reusing information; 12, supporting international use; 13, leveraging human knowledge; 14, modifying interfaces; 15, supporting multiple activity; 16, navigating within a single view; 17, observing system state; 18 Working at the user’s pace; 19, predicting task duration; 20, supporting comprehensive searching; 21, supporting Undo; 22, working in an unfamiliar context; 23, verifying resources; 24, operating consistently across views; 25, making views accessible; 26, supporting visualization. Figure 2. The matrix relating usability bene®ts to architectural mechanisms.

005 (http://www.sei.cmu.edu/publications/documents/ 01.reports/01tr005.html). We have used these scenarios in three diVerent design or analysis situations: a large ®nancial system, a driver information system (both commercial products) and a research prototype of a multi-user meeting support system. In each case, the scenarios were a jumping oV point for architectural discussions embedded in a software engineering process that traditionally used quality attributes but had not been developed with usability in mind as one of those quality attributes. The ®nancial system and meeting-support prototype were targets of the Architecture Trade-oV Analysis Method (ATAM, Kazman et al. 2000) to discover risks to achieving the quality attributes important to the developing organizations. The driver information system was being designed using the Attribute Driven Design (ADD) method

(renamed from the architecture-base d design method and documented in Bachmann 2000). ADD is a design method explicitly devised to satisfy quality attribute goals. Through the discussions, the software designers discovered issues in the system design that would have otherwise gone undiscovered, at least through initial implementation. An interesting point about the two commercial systems is that both projects had valued ease of use from the inception of the project and both had had usability professionals designing the interface; the ®rst hired an outside consultant and the second had in-house professional s from three companies co-operating on the interface design. The discussions spurred by our architecturally sensitive usability scenarios uncovered issues that the usability professionals had not yet brought to the table. Furthermore, they did so early enough that the architectural design could anticipate the needs and

Usability and software architecture facilitate rather than preclude achieving the project’s usability goals.

335

Note 1

5. Into the future Our analyses of general usability scenarios and our experience using them in software engineering processes have led us to conclude that many facets of usability are indeed architecturally sensitive and we retract our earlier statements that usability can be con®ned to a single software component. We believe that many annoying aspects of systems are captured in our scenarios and the reason they persist in so many computer systems is that architectural decisions that preclude them are made early and without regard for their usability implications. We believe that architectural decisions that facilitate, rather than preclude, usability could be made if both software architects and usability professionals understood the relationship between architecture and usability and brought that understanding to the design process early enough to do something about it. We believe that it is possible to treat usability in the same fashion as software engineers do the other quality attributes and that usability ®ts naturally into existing software architecture design and analysis processes. However, the work is not complete by any means. Let us not make the same mistake we made 10 years ago when we assumed that the architectural research of the 1980s had solved all the problems of usability. One obvious area for future work is to extend the general scenarios we collected to include multi-user and oV-the-desktop scenarios. We need to develop and document analysis techniques for usability that can produce meaningful information at the level of architecture. Another area of research is to understand the relationships between usability architecture patterns and those of other quality attributes. For instance, what are the eVects on reliability, security, performanc e and modi®ability of implementing the architectural pattern for cancellation? Likewise, what are the eVects on usability of the architectural patterns used to achieve other attributes, for example, what are the usability impacts of a ®rewall? Finally, we need to get usability concerns routinely integrated into software architecture analysis and other software engineering processes. In sum, we call both the HCI community and the SE community to action. We need to bump `design is where the action is’ up to the architectural level for HCI professional s and have software engineers treat usability as a ®rst-class quality attribute. We need to examine `what’s in it’ for both ®elds to collaborate more closely, to the bene®t of computer users everywhere.

Newell and Card’s solution was to develop psychological theory in a way to allow it to drive design. The majority of the HCI ®eld took a diVerent turn, but the battle cries `design is where the action is’ and `systems are the coin of the realm’ were used by all factions moving away from user testing.

References ALEX ANDER, C., ISHIKAWA, S. and SILVERSTEIN, M. 1977, A Pattern Languag e (New York: Oxford University Press). BA CHMANN, F., BASS, L., CHASTEK, G., DONOHOE, P. and PERUZZI, F. 2000, The Architecture Based Design Method. CMU/SEI-2000-TR-001 ADA375851 (Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University). BA SS, L. and COUTAZ, J. 1991, Developing Software for the User Interface (Reading MA: Addison-Wesley). BA SS, L., CLEMENTS, P. and KAZMAN, R. 1998, Software Architecture in Practice (Reading MA: Addison-Wesley). BA SS, L., JOHN, B. E. & KA TES, J. 2001, Achieving Usability Through Software Architecture, CMU/SEI-TR-2001-005 Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University. BEYER, H. and HOLTZBLATT, K. 1998, Contextual Design (San Francisco, CA: Morgan Kaufmann). BUSCHMANN, F., MEUNIER, R., ROHNER T, H., SOMMERLAD, P. and STAL, M. 1996, Pattern-Oriented Software Architecture ± A System of Patterns (New York: Wiley). CO UTAZ, J. 1987, PAC, an object oriented model for dialog design. In H. J. Bullinger and B. Shackel (eds), HumanComputer InteractionÐINTERACT’87 (Amsterdam: NorthHolland), pp. 431 ± 436. GAMMA, E., HELM, R., JO HNSO N, R. and VLISSIDES, J. 1995, Design Patterns, Elements of Object-Oriented Software (Reading, MA: Addison-Wesley). GRAM, C. and COCKTON, G. 1996, Design Principles for Interactive Systems (London: Chapman & Hall). HIX, D. and HARTSON, H. R. 1993, Developing User Interfaces: Ensuring Usability through Product and Process (New York: Wiley). KAZMAN, R., ABOWD, G., BASS, L. and CLEMENTS, P. 1996, Scenario-Based Analysis of Software Architecture. IEEE Software, 13, 47 ± 56. KAZMAN, R., KLEIN, M. and CLEMENTS, P. 2000, ATAM: Method for Architecture Evaluation CMU/SEI-2000-TR-004 ADA382629 (Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University). KRASNER, G. E. and POPE, S. T. 1988, A cookbook for using Model-View-Controller User Interface Paradigm in Smalltalk-80. Journal of Object Oriented Programming, August/ September, 8 ± 22. NEWELL, A. and CA RD, S. K. 1985, The prospects for psychological science in Human ± Computer Interaction. Human ± Computer Interaction 1, 209 ± 242. NEWMAN, W. and LAMMING, M. 1995, Interactive System Design (Wokingham: Addison-Wesley). NIELSEN, J. 1993, Usability Engineering (Boston, MA: Academic Press).


336

OLSEN, D. R. JR 1992, User Interface Management Systems: Models and Algorithms (San Mateo, CA: Morgan Kaufmann). PFAFF, G. P. (ed.) 1983, Proceedings of the Workshop on User Interface Management Systems, 1 ± 3 November, Seeheim, Germany. SHAW, M and GAR LAN, D. 1996, Software Architecture: Perspectives on an Emerging Discipline (Englwood CliVs, NJ: Prentice-Hall). SHNEIDER MAN, B. 1998, Designing the User Interface, 3rd edn (Reading, MA: Addison-Wesley). SUTTON, J. and SPR AGUE, R. 1978, A Study of Display Generation and Management in Interactive Business Applications. IBM San Jose Research Laboratory Technical Report RJ2392(#31804) , San Jose, CA. WOODS, D. 1999. Presidential Address, Watching Human Factors watch people at work. Human Factors and Ergonomics Society Annual Meeting, Houston, TX, 27 September ± 1 October.

Appendix A:

Cancellation

General scenario: A user invokes an operation, and then no longer wants the operation to be performed. The user now wants to stop the operation rather than wait for it to complete. It does not matter why the user launched the operation. It could have been the slip of the mouse that led the user to select an unintended menu item. The user could have mistaken one command for another. The user could have decided to invoke another operation. For these reasons (and many more), systems should allow users to cancel operations.

Potential bene®ts: If the ability to cancel operations were provided in a system, several types of bene®ts would accrue to the individual user and his or her organization. (These correspond to the columns in the bene®t-mechanism matrix in ®gure 2.) Cancellation supports the routine performance of skilled individuals because it reduces the impact of the inevitable slips that happen to even the most skilled users. The eVects of a slip of the mouse or typo can be stopped and undone as soon as the slip is detected, making error recovery fast and complete. Cancellation supports problem-solving by allowing users to explore with con®dence, knowing they will not have to wait for a long process to complete, and that they will be able to get back to the state they were in before invoking an unknown

operation. Cancellation reduces the impact of errors caused by lack of knowledge just as it does for slips. Likewise, the eVects of system errors are reduced; the user can cancel a command that accessed a downed network rather than waiting forever for the network to reappear.

Architectural pattern: We ®rst present the module view that enumerates the components involved and their responsibilities. We then present a sequence chart that shows how the components interact. Figure 3 presents the module view of the cancellation architectural style. It has the following components together with their responsibilities. Note that these functions may or may not be implemented as separate software components (such as classes or threads). Activity component. Activity components perform the activities that may be cancelled. They must co-operate with the controller to provide information about the resource that they use and their collaborations. They must also have a mechanism for retaining su cient information about the state of the system before invoking the active component to be able to restore that state at any time. The mechanism will be exercised by the cancellation component but the activity components must prepare so that the cancellation component can, in fact, exercise the mechanisms. (2) Cancellation listener. This component listens for the user to request cancelling the activity components. It must inform the user that it has received the cancellation request. It then informs the cancellation controller. If necessary, it may spawn a new thread to control the operation of the cancellation controller. (3) Cancellation controller. This component can terminate the active thread, return the persistent resources to their state prior to invoking the activity components, release nonpre-emptable resources, provide feedback to the user about progress and the result of the cancellation, and inform collaborating components of the termination of the active thread. It is responsible for gathering information about the resources used by the activity components and the collaborators. (4) Collaborators. These components are responsible for receiving information about the termination of the activity components. (1)

Usability and software architecture Figure 4 presents a representation of the threads of this pattern. The following logically distinct threads of activity exist, although, they may be implemented together. The listener thread. This thread interacts with the user. It provides the user with a means to indicate what is to be cancelled. . The cancellation control thread. This thread manages the cancellation activities. It must be an independent thread from the active thread. . The active thread. This is the running thread that the user wishes to cancel. The activities running under the control of the active thread are those that are to be cancelled. . The collaborating processes thread. This may be a collection of threads but we model it as a single thread. This thread manages those processes that collaborate with the active thread. .

These threads interact as follows. The user sends a cancellation stimulus to the cancellation listener component running in the listener thread. This thread then: .

provides feedback to the user that the cancel request has been received; and

.

indicates to the cancellation controller that the cancel activity should be carried out.

The cancellation controller is a thread created to carry out the cancellation. The active thread should not be expected to listen for a cancel request since it may be

Figure 3.

Module view of cancellation architecture pattern.

337

blocked for some reason or it may be in an in®nite loop. The cancellation component carries out four activities: (1) (2)

terminate the active thread; inform the user of the progress and results of the cancellation; (3) return the system to its state prior to the invocation of the active thread. This involves: 3(a) restoring any persistent resources to their state prior to the invocation of the active thread; 3(b) releasing nonpre-emptive resources acquired by the active thread. (4) inform threads collaborating with the active thread of the termination of the active thread. The ®rst of these is straightforward. Presumably, the thread control mechanisms of the operating system permit terminating a thread. The second activity is also straightforward. The user should be informed of both progress and the results of the cancellation. The third activity (returning to prior state) requires that the cancellation controller be aware of the mechanisms for restoring persistent resources to their states prior to invoking the active thread. For example, operating system resources may need to be reallocated, ®les may need to be restored, network connections may need to be re-established, etc. The cancellation controller must also be aware of the resources acquired by the activity components and these resources must be freed. This awareness can be achieved by a variety of mechanisms. The activity components can report resources acquired to the cancellation controller, the cancellation controller can intercept requests for resources, or the various


338

informed of the state of these collaborations; it can simply inform each of the collaborating threads of the termination of the active thread. Then it becomes the responsibility of the collaborating threads to perform the correct actions, including providing information to the user about the progress and results of these cancellation requests. This can be potentially complicated. It depends on the type of collaboration and the extent to which the collaborating components depend on the completion of the active thread. One possibility is to treat the information as a cancellation request for the collaborating components. In this case, a recursive use of the pattern will achieve the desired results. Other types of collaborations may not require cancellation. In any case, a decision must be made as to the desired result after the collaboration components have been informed of the cancellation of the active thread.

Architectural mechanisms used in this pattern:

Figure 4.

Cancellation pattern ± thread view.

resource managers can provide this information to the cancellation controller. The fourth activity (informing collaborating threads) also requires knowledge on the part of the cancellation controller. The cancellation controller must be informed of collaborations, either synchronization or data communication that the active thread has with other threads. The controller doesn’t necessarily need to be

Certain architectural mechanisms are found in this pattern to implement cancellation. (These correspond to the rows in the bene®t-mechanism matrix in ®gure 2.) This pattern uses pre-emptive scheduling because the cancellation listener and cancellation controller must occupy independent threads. It uses recording because the cancellation controller must record its initial state so that the system can be returned to the state before the invocation of the cancelled components. It also must have a model of itself, because after a command has been cancelled, the cancellation controller must consult an explicit model of itself in order to predict state restoration time and to report progress.