A Responsibility-Based Pattern Language for Usability-Supporting Architectural Patterns

To appear in the Proceedings of EICS 2009, July 14-17, 2009, Pittsburgh, PA, USA A Responsibility-Based Pattern Language for Usability-Supporting Architectural Patterns Bonnie E. John Len Bass Elspeth Golden Pia Stoll HCI Institute Software Engineering Institute HCI Institute ABB Corp Research Carnegie Mellon University Carnegie Mellon University Carnegie Mellon University Forskargränd 6 5000 Forbes Ave. 4500 Fifth Ave. 5000 Forbes Ave. SE 72178 Pittsburgh, PA, 15217 Pittsburgh, PA, 15217 Pittsburgh, PA, 15217 Västerås, Sweden +1-412-268-7182 +1-412-268-6763 1+412-268-2000 +46 21 32 30 00 [email protected] [email protected] [email protected] [email protected] ABSTRACT Thus, the original USAPs were a pattern “catalogue”, as opposed Usability-supporting architectural patterns (USAPs) were to a pattern language [8]. developed as a way to explicitly connect the needs of As originally conceived to emulate patterns in the Alexander style architecturally-sensitive usability concerns to the design of [2], a USAP had six types of information. We illustrate the types software architecture. In laboratory studies, the Cancellation with information from the Cancellation USAP [15]. USAP was shown to significantly improve the quality of 1. A brief scenario that describes the situation that the USAP is architecture designs for supporting the ability to cancel a long- intended to solve. For example, “The user issues a command running command, sparking interest from a large industrial then changes his or her mind, wanting to stop the operation organization to develop new USAPs and apply them to their and return the software to its pre-operation state.” product line architecture design. The challenges of delivering the 2. A description of the conditions under which the USAP is architectural information contained in USAPs to practicing relevant. For example, “A user is working in a system where software architects led to the development of a pattern language the software has long-running commands, i.e., more than one for USAPs based on software responsibilities and a web-based second.” tool for evaluating an architecture with respect to those patterns. 3. A characterization of the user benefits from implementing the USAP. For example, “Cancel reduces the impact of routine Categories and Subject Descriptors user errors (slips) by allowing users to revoke accidental H.5.2 User Interfaces; D.2.11 Software Architectures. commands and return to their task faster than waiting for the erroneous command to complete.” General Terms 4. A description of the forces that impact the solution. For Design, Human Factors. example, “No one can predict when the users will want to cancel commands” 5. An implementation-independent description of the solution, Keywords i.e., responsibilities of the software. For example, one Usability, software architecture. implication of the force given above is the responsibility that “The software must always listen for the cancel command.” 1. INTRODUCTION 6. A sample solution using UML-style diagrams. These diagrams Usability-supporting architectural patterns (USAPs) were were intended to be illustrative, not prescriptive, and are, by developed as a way to explicitly connect the needs of necessity, in terms of an overarching architectural pattern architecturally-sensitive usability concerns to the design of (e.g., MVC). Both component and sequence diagrams were software architecture [14]. A score of patterns were originally provided, showing MVC before and after incorporating the proposed [5], loosely connected by software tactics that they USAP’s responsibilities. Responsibilities were assigned to might share (e.g., encapsulation of function, data indirection, each component and represented in the UML-style diagrams preemptive scheduling), but this relationship was not developed (Figures 1 and 2). sufficiently to be of benefit in subsequent research or practice. Making all six parts complete and internally consistent is a time- consuming process and for several years the original authors Permission to make digital or hard copies of all or part of this work for succeeded only in creating one full exemplar, the Cancellation personal or classroom use is granted without fee provided that copies are USAP for canceling long-running commands. With only one not made or distributed for profit or commercial advantage and that USAP fully fleshed out, there was no opportunity to discover copies bear this notice and the full citation on the first page. To copy structure that might lead to a pattern language. otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. The Cancellation USAP was shown to significantly improve the EICS’09, July 14–17, 2009, Pittsburgh, PA, USA. quality of architecture designs for supporting the ability to cancel Copyright 2009 ACM 1-58113-000-0/00/0004…$5.00. a long-running command in laboratory studies [12, 13]. This the architecture and had not yet written any code. Their success was encouraging, but did not address issues with implementation plan started with the backbone of the product line designing an architecture that had to consider more than one system, the core functionality, which would support all the USAP at a time. Multiple USAPs had been used in a real variation points for the products. Usability had been prioritized as development setting, but that intervention required heavy one of three most important software qualities for the new system involvement from the researchers who developed the USAPs during the Quality Attribute Workshop. because they were not sufficiently fleshed out for the architect to The best method to support usability concerns through software use them on his own [1]. Thus, prior uses of USAPs suffered from architecture has been the subject of some investigation over the two defects. First, the industrial uses all involved the researchers past years. In addition to the work on USAPs [5, 12, 13, 14, 15], who developed USAPs and this clearly does not scale up. Second, Folmer and his colleagues [9, 10] and Juristo and her colleagues the laboratory experiments were paper based and the participants [16] have investigated the relationship between software omitted important responsibilities of the USAPs, leaving architecture and usability. None of this work has gained additional room for quality improvement. widespread industry acceptance probably because all of the results reported require the direct involvement of the researchers. Thus, our goal in this project was to deliver appropriate knowledge concerning usability and software architecture to ABB’s software architects in a format and at a time that would benefit their design and that could scale to support global development efforts. After some investigation into the interplay of usability and software architecture the ABB research team, supporting the ABB project team, decided to try using usability-supporting Figure 1 UML-style component diagram of the MVC architectural patterns (USAPs) in a collaboration with the authors reference architecture before considering the ability to cancel at Carnegie Mellon University (CMU). Their decision was based a long running command. Original responsibilities of MVC on the fact that USAPs use generic usability scenarios and from are numbered R1, R2, etc. and refer to prose descriptions of these construct generic software architecture responsibilities. By the responsibilities accompanying the diagram. working this way, ABB expected to address some of the major usability concerns early in the software design phase without having an actual user interface design in place. The collaboration started with several teleconferences and a two- day workshop where the ABB research team together with the CMU research team presented the USAP approach and the ABB project team presented their new product line system to be developed. The researchers presented 19 general usability scenarios possibly relevant to this domain. These were: • Progress feedback • Warning/status/alert feedback • Undo • Canceling commands Figure 2 UML-style component diagram of MVC revised to • User profile include the responsibilities necessary to provide the ability to • Help cancel a long running command. New cancellation • Command aggregation responsibilities are numbered CR1, CR2, etc., are assigned to • Action for multiple objects both old and new components, and refer to prose descriptions • Workflow model of the responsibilities in the Cancellation USAP. • Different views of data • Keyboard shortcuts • Reuse of information 2. A COLLABORATION BETWEEN • Maintaining compatibility with other systems INDUSTRY AND ACADEMIA • Navigating within a single view A large global company, ABB, was beginning the development of • Recovering from failure a new product line. Prior to the collaboration reported in this • Identity management paper, the project team in the business unit developing the new • Comprehensive search product line of systems, together with an ABB research team, had • Supporting internationalization done a use case analysis, performed a Quality Attribute Workshop • Working at the user’s pace to collect non-functional requirements from prioritized scenarios The ABB project team was asked to prioritize the general [4], used the Influencing Factors method [18] and conducted the usability scenarios and they decided to focus on two – User first step of the Product Line Architecture development approach Profile and Warning/status/alert feedback (which ABB called

Load more