Preparing Usability Supporting Architectural Patterns for Industrial Use Pia Stoll Bonnie E. John, Len Bass, Elspeth Golden ABB Corporate Research Carnegie Mellon University Forskargränd 6 5000 Forbes Ave. SE 72178 Västerås, Sweden Pittsburgh, PA, USA 15213 Tel: +46 21 32 30 00 Tel: 1+412 268 2000 pia.stoll@se.abb.com bej@cs.cmu.edu, ljb@sei.cmu.edu, egolden@cmu.edu ABSTRACT Usability supporting architectural patterns (USAPs) have been 1. INTRODUCTION The Software Engineering community has recognized that shown to provide developers with useful guidance for producing a usability affects not only the design of user interfaces but software architecture design that supports usability in a laboratory software system development as a whole. In particular, efforts are setting [7]. In close collaboration between researchers and focused on explaining the implications of usability on software software developers in the real world, the concepts were proven architecture design [3, 4, 5, 6, 10]. useful [2]. However, this process does not scale to industrial development efforts. In particular, development teams need to be One effort in this area is to produce artifacts that communicate able to use USAPs while being distributed world-wide. USAPs usability requirements in a form that can be effectively used for also must support legacy or already partially-designed software architecture evaluation and design. These usability architectures, and when using multiple USAPs there could be a supporting architectural patterns (USAPS) have been shown to potentially overwhelming amount of information given to the improve the ability of software architects to design higher quality software architects. In this paper, we describe the restructuring of architectures to support usability features such as the ability to USAPs using a pattern language to simplify the development and cancel a long-running command [7, 8]. Other uses of USAPs in use of multiple USAPs. We also describe a delivery mechanism industrial settings have been productive [2] but have revealed that is suitable for industrial-scale adoption of USAPs. The some problems that prevent scaling USAPs to widespread delivery mechanism involves organizing responsibilities into a industrial use. These problems include: hierarchy, utilizing a checklist to ensure responsibilities have been considered, and grouping responsibilities in a fashion that 1. Prior efforts have involved personal contact with USAP both supports use of multiple USAPs simultaneously and also researchers, either face to face or in telephone conversations. points out reuse possibilities to the architect. This process does not scale to widespread industrial use. 2. The original USAPs included UML diagrams modifying the Categories and Subject Descriptors MVC architectural pattern to better support the usability D.2.2 [Design Tools and Techniques] User interfaces; D.2.11 concern. Although intended to be illustrative, not [Software Architectures]: Patterns; H.5.2 [User Interfaces] prescriptive, software architects using other overarching Theory and Methods patterns (e.g., legacy systems, SOA) viewed these UML diagrams as either unrelated to their work or as an unwanted recommendation to totally redesign their architecture. General Terms Design, Human Factors. 3. The original use of USAPs was as a collection of individual patterns. Even using one pattern involved processing a large amount of detailed information. Applying multiple USAPs Keywords simultaneously is likely to overwhelm software architects Software Architecture, Usability, Human-Computer Interaction, with information. HCI In this paper, we introduce a pattern language [1] for USAPs that reduces the information that architects must absorb and produces Permission to make digital or hard copies of all or part of this work for information at a level that applies to all architectures. We also personal or classroom use is granted without fee provided that copies are discuss the design of a delivery mechanism suitable for industrial- not made or distributed for profit or commercial advantage and that scale adoption of USAPs. copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. 2. BACKGROUND A USAP has six types of information. We illustrate the types with I-USED’08, September 24, 2008, Pisa, Italy information from the cancellation USAP [9] 1. A brief scenario that describes the situation that the USAP is intended to solve. For example, “The user issues a command then changes his or her mind, wanting to stop the operation “Alarms, Events and Alerts”, “User Profile” and “Environment and return the software to its pre-operation state.” Configuration” is shown in Figure 1. 2. A description of the conditions under which the USAP is relevant. For example, “A user is working in a system where the software has long-running commands, i.e., more than one second.” 3. A characterization of the user benefits from implementing the USAP. For example, “Cancel reduces the impact of routine user errors (slips) by allowing users to revoke accidental commands and return to their task faster than waiting for the erroneous command to complete.” 4. A description of the forces that impact the solution. For example, “No one can predict when the users will want to cancel commands” 5. An implementation-independent description of the solution, i.e., responsibilities of the software. For example, one implication of the force given above is the responsibility that “The software must always listen for the cancel command.” 6. A sample solution using UML diagrams. These diagrams Figure 1 USAP Pattern Language for “User Profile”, were intended to be illustrative, not prescriptive, and are, by “Alarms, Events and Alerts”, and “Environment necessity, in terms of an overarching architectural pattern Configuration” (e.g., MVC). The pattern language has two types of USAPs. “End-User It is useful to distinguish USAPs from other patterns for software USAPs” follow the structure given in Section 2. Their purpose design and implementation. USAPs are not user interface patterns, from a user’s point of view can be expressed in a small scenario, that is, they do not represent an organization or look-and-feel of a they have conditions under which they are relevant, benefits for user interface [e.g., 11]; they are software architecture patterns the user can be expressed and they require the fulfillment of that support UI concerns. Nor are USAPs structural software software responsibilities in the architecture design. End-User architecture patterns like MVC; they are patterns of software USAPs are used by the requirements team to determine which are responsibilities that can be applied to any structure. As such, they applicable to the system being developed. In this example, they can be applied to any legacy architecture and can support the are “User Profile”, “Alarms, Events and Alerts”, and functionality called for in UI patterns. “Environment Configuration”. The pattern language also contains what we are calling “Foundational USAPs”. These do not have the same six portions 3. A PATTERN LANGUAGE FOR USAPs as the End-User USAPS. For example, there is no scenario, no Through collaboration among academic and industrial researchers description of conditions, and no benefits to the user for the and usability engineers, we are constructing three USAPs for Foundational USAPs. Rather, they act as a framework to support process control and robotics applications. The first author and her the construction of the End-User USAPs that make direct contact colleagues in the industry research team drafted an “Alarms, to user scenarios and usability benefits. For example, all of the Events and Alerts” USAP while, independently, the last three End-User USAPs that we present have an authoring portion and authors drafted a “User Profile” USAP and an “Environment an execution portion, that is, they are specializations of the Configuration” USAP. When these three USAPs were considered Authoring Foundational USAP and the Execution with Authored together, it was clear that there was an enormous amount of Parameters Foundational USAP. These foundational USAPs make redundancy in the responsibilities necessary for a good solution. use of other foundational USAPs, Authorization and Logging. We In addition, in preliminary discussions, industry software abstracted the commonalities of the End-User USAPs to derive architects reacted negatively to the large amount of information the responsibilities of the Foundational USAPs. The required to implement any one of the USAPs. responsibilities in the Foundational USAPs are parameterized, Our early work [4] recognized the possibility of reusing such where the parameters reflect those aspects of the End-User software tactics as separating authoring from execution and USAPs that differ. recording (logging), but our subsequent work had not An example of the parameterization is that the Authoring incorporated that notion, treating each USAP as a separate Foundational USAP and the Execution with Authored Parameters pattern. A consequence of focusing on industrial use is that reuse Foundational USAP each have a parameter called in constructing and using USAPs was no longer an academic SPECIFICATION. The value of SPECIFICATION is “Conditions thought experiment, but a necessity if industrial users are to for Alarm, Event and Alerts”, “User profile”, and “Configuration construct and use USAPs themselves. description” for the three End-User USAPs, respectively. We observed that both the industry research team and the In addition to parameterization, End-User USAPs explicitly list academic research team independently grouped their assumptions about decisions the development team must make responsibilities into very similar categories. This led us to prior to implementing the responsibilities. For example, in the construct a pattern language [2] that defines relationships between “Alarms, Events and Alerts” End-User USAP, the development USAPs with potentially reusable sets of responsibilities that can team must define the syntax and semantics for the conditions that lead to potentially reusable code. Our pattern language relating will trigger alarms, events or alerts. End-User USAPs may also have additional responsibilities beyond those of the Foundational The design includes a set of radio buttons for each responsibility USAPs they use. For example, the “Alarms, Events and Alerts” that are initially set to “Not yet considered.” The architect reads End-User USAP has an additional responsibility that the system each responsibility and determines whether it is not applicable to must have the ability to translate the names/ids of externally the system being designed, already accounted for in the generated signals (e.g., from a sensor) into the defined concepts. architecture, or that the architecture must be modified to fulfill the Both the assumptions and additional responsibilities will differ for responsibility. If “Not applicable”, “Must modify architecture to the different End-User USAPs. address this” or “Architecture addresses this” is selected, then the There are three types of relationships among the Foundational responsibility’s checkbox is automatically checked. If “Not USAPs and these are shown in Figure 1 as different color arrows. considered”, “Must modify architecture or “Discuss status of The Generalization relationship (turquoise) says that the responsibility”, is selected, the responsibility will be recorded in Foundational USAP is a generalization of part of the End-User To-Do list generated from the website (Figure 3). We expect this USAP. The End-User USAP passes parameters to that lightweight reminder to consider each and every responsibility Foundational USAP and, if there are any conditionals in the will not be too much of a burden for the architect, but will responsibilities of the Foundational USAP, the End-User USAP increase the coverage of responsibilities, which is correlated with may define the values of those conditionals. The Uses relationship the quality of the architecture solution [8]. (black) also passes parameters, but the USAPs are at the same As Figure 2 show, the responsibilities are arranged in a hierarchy, level of abstraction (the foundational level). The Depends-On which reflects both the relationship of End-User and Foundational relationship (red) implies a temporal relationship. For example, USAPs and the internal structure within a Foundational USAP. the system cannot execute with authored parameters unless those This hierarchy divides the responsibilities into manageable sub- parameters have first been authored. The double headed arrow parts. The checkboxes enforce this structure by automatically between authoring and logging reflects the possibility that the checking off a higher-level box when all its children have been items being logged may be authored and the possibility that the checked off, and conversely, not allowing a higher-level box to be identity of the author of some items may be logged. checked when one or more of its children are not. Thus, this Foundational USAPs each have a manageable set of mechanism simultaneously addresses the problems of providing responsibilities (Authorization has 11; Authoring, 12; Execution guidance without intervention by USAP researchers and with authored parameters, 9; and Logging 5), as opposed to the 21 simplifying the information provided to the software architect. responsibilities of the Cancel USAP that seemed to be too much Another mechanism for simplifying the information delivered to for our experiment participants to absorb in one sitting [7]. These an architect is that each responsibility has additional details responsibilities are further divided into groups for ease of available only by request of the architect. These details include understanding, e.g., Authoring is separated into Create, Save, more explanation, rationale about the need for the responsibility Modify, Delete and Exit the authoring system. This division into and the forces that generated it, and some implementation details. manageable Foundational USAPs simplifies the creation of future This information is easily available, but not “in the face” of the USAPs that use them. For example, the User Profile End-User software architect. As well as simplifying the presentation, this USAP requires only the definition of parameters and the values mechanism de-emphasizes the role of illustrative examples for one conditional, and pointers to the Authoring and Execution situated in reference architecture like MVC. We expect that this Foundational USAPs. presentation decision will reduce the negative reactions to generic example UML diagrams. When using the tool in-house in 4. DELIVERING A SINGLE USAP TO industry, the reference architecture used in example solutions SOFTWARE ARCHITECTS could be changed to an architecture used by that industry. This The roadblocks to widespread use of USAPs in industry identified would both accelerate understanding of the examples and increase in the introduction were (1) the need for contact with USAP the possibility of re-using the sample solution. This presumes that researchers in the development process, (2) reactions to examples the tool is constantly managed and updated by in-house usability using a particular overarching architectural pattern (MVC) and (3) experts and software architects, a presumption facilitated by an overwhelming amount of information delivered to the software delivering the examples in separate web pages. architect. Data from our laboratory study and the pattern language Although the hierarchy of responsibilities reflects the relationship outlined above put us in a position to solve these problems. of the End-User USAPs and the Foundational USAPs, the Our laboratory study [7] showed that a paper-based USAP could difference between the types of USAPs is not evident in the be used by software engineers 1 without researcher intervention, to presentation of responsibilities. It was a deliberate design choice significantly improve their design of an architecture to support the to express each responsibility in terms of the End-User USAP’s users’ need to cancel long-running commands. Although vocabulary. Thus, the responsibilities in Figure 2 are couched in significantly better than without a USAP, these software terms of “User Profile”, “Configuration Description”, “Conditions engineers seemed to disregard many of the responsibilities listed for Alarms, Events, and Alerts” and this string replaces the in the USAP in their designs. To enhance attention to all parameter SPECIFICATION in the Foundational Authoring responsibilities, we have chosen to design a web-based system USAP. that presents responsibilities in an interactive checklist (Figure 2). 1 The participants in our lab study had a Masters in SE or IT, were trained in software architecture design, and had an average of over 21 months in industry. Figure 2: Prototype of a web-based interface for delivering USAP responsibilities to industry software architects. Figure 3: Prototype “to do” list produced from those responsibilities that are marked as requiring architectural modification. In the next section, we discuss how we anticipate managing the responsibilities and hence the reuse possibilities of fulfilling situation when the architect chooses multiple USAPs as being them through a single piece of parameterized code. relevant to the system under construction. This will allow The problem introduced by this form of the presentation is that distribute architecture teams both to record rationale for their now the radio buttons becomes ambiguous. Does the entry choice and to discuss potential solutions. Attaching design “Architecture addresses this” mean that all of the three rationale and discussion is optional so our delivery tool will responsibilities have been addressed or only some of them? We support discussion, but not require it, keeping the tool resolve this ambiguity by repeating the radio buttons three lightweight. times, once for each occurrence of the responsibility. Thus, the At any point in the process of considering the different three responsibilities will be combined into one textual responsibilities, the architect can generate a “to do” list. This is description of the responsibility but three occurrences of the a list of all of the responsibilities that have been checked as “Not radio buttons. yet considered” or “Must modify architecture”. See Figure 3 for an example. The list can then be entered into the architect’s 6. CURRENT STATUS AND FUTURE normal task list and will be considered as other tasks are WORK considered. At this writing, we have developed the pattern language for Supporting world wide distribution of the architecture team in three End User USAPs and four Foundational USAPs (Figure 1) the use of USAPs has two facets. and have fleshed out all the responsibilities for these seven USAPs. We have constructed a prototype delivery tools for a • Enable world wide access browser based checklist and “to do” list generator. • Reduce the problems associated with simultaneous updates We plan to test the delivery mechanism in an ongoing industrial by different members of the team. development effort. This will demonstrate strengths and The use of the World Wide Web for delivery allows world wide weaknesses of our approach and we will iterate to resolve any access with appropriate access control. Standard browsers problems or capitalize on any opportunities. One suggestion put support the concept of check lists and producing the “to do” forth in early industry feedback is to enhance the to-do list by lists. assigning expected effort to each responsibility. One Allowing simultaneous updates is not supported by standard requirements engineer at ABB said that her perception of the browsers. Some Wikis do support simultaneous updates, e.g. effort needed to implement a scenario had been thoroughly MediaWiki [www.mediawiki.org], but we do not yet know revised just be looking at the to-do list. By adding estimated whether these wikis directly support checklists and the hours to the responsibilities, industry would get a better estimate generation of “to do” lists. We are currently investigating which of the usability improvements’ translation into software tool or combination of tools will be adequate for our needs and implementation cost. These estimates would vary depending on what modifications might have to be made to those tools. many factors such as underlying architectural style, implementation language, skill of programmers, etc. but a large 5. DELIVERING MULTIPLE USAPS TO organization may have enough data from previous projects to make such estimates for their organization. In addition, such a SOFTWARE ARCHITECTS feature could emphasize the savings realized by reuse; Our motivation for developing the USAP Pattern Language was responsibility-implementations that serve multiple End-User partially to simplify the delivery of USAPs when multiple USAPs would show up as requiring very little effort after the USAPs are relevant to a particular system. We also want to first implementation. indicate to the architect the possibilities for reuse. In this section, we describe how we anticipate accomplishing these two The delivery platform that we have described here, to be used by goals. software architects, is envisioned to be the final portion of a tool chain. There are two additional roles involved in the Recall that the Foundational USAPs are parameterized and each development and use of USAPs. First, USAP developers will End User USAP provides a string that is used to replace the have to create USAPs within the stylized context of the USAP parameter. For instance, consider a responsibility from the Pattern Language. Tool support for USAP developers will Authoring Foundational USAP “The system must provide a way greatly simplify the creation of USAPs. for an authorized user to create a SPECIFICATION”. When three End User USAPs are relevant to the system under design, The second role is the requirements definers; often a team such as “User Profile”, “Environment Configuration”, and comprised of technologists and human factors engineers, “Alarms, Events and Alerts”, the three responsibilities are usability engineers, designers, or other users or user advocates. displayed to the architect as “The system must provide a way for Figure 4 shows how we envision a tool supporting this role. an authorized user to create a [User Profile, Configuration description, Conditions for Alarm, Event and Alerts]. This presentation satisfies two goals and introduces one problem. Presenting three responsibilities as one reduces the amount of information displayed to the architect since every Foundational USAP responsibility is displayed only once, albeit with multiple pieces of information. This presentation also indicates to the architect the similarity of these three [2] Adams, R. J., Bass, L., & John, B. E. (2005) Applying general usability scenarios to the design of the software architecture of a collaborative workspace. In A. Seffah, J. Gulliksen and M. Desmarais (Eds.) Human-Centered Software Engineering: Frameworks for HCI/HCD and Software Engineering Integration. Kluwer Academic Publishers. [3] Bass, L., John, B., & J. Kates, (2001), “Achieving Usability through Software Architecture,” Technical Report CMU/SEI-2001-TR-005, Software Eng. Inst., Carnegie Mellon Univ., 2001. Figure 4: Tool to support the requirements elicitation [4] Bass, L., & John, B. (2003) “Linking Usability to Software process Architecture Patterns through General Scenarios,” The J. The requirements team has available to them a repository of Systems and Software, vol. 66, no. 3, pp. 187-197, 2003. USAPs. They select the ones that are appropriate for the system [5] Folmer, E. (2005) Software Architecture Analysis of being constructed. In our experience, the USAP end-user Usability, Ph.D. thesis. Department of Computer Science, scenarios are very general and can be used to invoke ideas about University of Groningen, Groningen. how they apply to the system at hand. However, industrial teams would like to tailor these scenarios to match their everyday [6] Folmer, E., van Gurp, J., Bosch, J. (2003) A Framework for usability issues. Thus, the tool supporting requirements definers capturing the relationship between usability and software will allow them to re-write the general scenarios to suit their architecture; Software Process: Improvement and Practice, specific application. Volume 8, Issue 2. Pages 67-87. April/June 2003. The tool then creates input for the delivery tool while [7] Golden, E, John, B. E., & Bass, L. (2005) The value of a simultaneously combining redundant responsibilities. The usability-supporting architectural pattern in software output of the requirements definition process will then be architecture design: A controlled experiment. Proceedings presented to software architects, as described in this paper, to of the 27th International Conference on Software aid in their architecture design process. Engineering, ICSE 2005 (St. Louis, Missouri, May, 2005). In summary, USAPs have been proven to be useful to software [8] Golden, E., John, B. E., Bass, L. (2005) Quality vs. architects but have also demonstrated some problems that hinder quantity: Comparing evaluation methods in a usability- industrial use. Definition of a USAP Pattern Language and an focused software architecture modification task. appropriate selection of tools supporting the roles involved in Proceedings of the 4th International Symposium on the creation and use of USAPs should simplify industrial use. Empirical Software Engineering (Noosa Heads, Australia, We are currently constructing versions of these tools and testing November 17-18 2005). the extent to which they do, in fact, enable the industrial use of [9] John, B. E., Bass, L. J., Sanchez-Segura, M-I. & Adams, USAPs. R. J. (2004) Bringing usability concerns to the design of software architecture. Proceedings of The 9th IFIP Working 7. ACKNOWLEDGMENTS Conference on Engineering for Human-Computer We would like to thank Fredrik Alfredsson and Sara Lövemark Interaction and the 11th International Workshop on for their contributions to the “Alarms, Events and Alerts” Design, Specification and Verification of Interactive USAP. This work was supported in part by funds from ABB Inc. Systems, (Hamburg, Germany, July 11-13, 2004). The views and conclusions in this paper are those of the authors [10] Juristo, N., Moreno, A. M., Sanchez-Segura, M. (2007), and should not be interpreted as representing the official “Guidelines for Eliciting Usability Functionalities”, IEEE policies, either expressed or implied, of ABB. Transactions on Software Engineering, Vol. 33, No. 11, November 2007, pp. 744-758. 8. REFERENCES [11] Tidwell, J. (2006), Designing Interfaces: Patterns for [1] Alexander, C. (1977). A Pattern Language: Towns, Effective Interaction Design. O’Reilly Media: Sebastopol, Buildings, Construction. USA: Oxford University Press. CA. ISBN 978-0195019193.