(Prepared for a Grad School Assignment, October 2006)
Patterns are commonly applied by software developers to solve re-occurring issues.
The article “The Value of a Usability-Supporting Architectural Patterns in Software Architecture Design: A Controlled Experiment” assesses the effectiveness of a USAP (Usability-Supported Architectural Pattern) in considering various usability concerns in modifying a system architecture.
Students were placed into one of three groups and evaluated on the number of usability-related issues they considered, as well as the time this task took. One group was provided with a usability scenario, one with this scenario as well as a list of general responsibilities to be taken into account during implementation, and the third group with these two elements as well as a sample solution to a similar problem.
The results of the experiment were not terribly shocking; those who were provided with more information identified more usability concerns. There were some individual variation, but there was strong evidence that “USAP for canceling a command can already be considered a valuable tool for modifying software architecture designs to address a specific usability concern.”[1]
As may be evident, the results of the experiment did not particularly capture my interest. I was far more intrigued by their closing comments:
“Perhaps the greatest surprise, however, is not that USAPs help to produce a more complete design, but that they are necessary at all. There is an implicit assumption in the world of human-computer interaction, and perhaps more generally, that software engineers simply know how to implement whatever requirements are provided to them. While this may be true in some areas which are more traditionally included in the training of either computer scientists or software engineers, it is not true in the case of software engineering for usability.”[2]
As a front-end developer in the User Experience group of a large online information provider, this is an area of personal and professional interest. Often system requirements either leave out usability considerations completely, or they are not captured in a measurable fashion. I was happy to see the article comment on how traditional software engineering practices do not implicitly meet usability needs.
Usability as a Quality Attribute
It is becoming increasingly obvious that usability has significant architectural implications. This is a departure from past perceptions, which were such that
“Since the 1980s, usability has been treated as a subset of modifiability, that is, architects commonly separate the user interface from the functionality of the system and assume that usability issues that arise during user testing can be handled with localized modifications…”[3]
This sentiment is echoed in other sources, that usability was often perceived to only be significant in “decorating a thin component sitting on top of the software or the “real system”[4] It is clear through the description of the experiment in this article how short-sighted this opinion is. Color and the physical arrangement of components do not a usable product make.
According to usability expert Jakob Nielsen,
“Usability is a quality attribute that assesses how easy user interfaces are to use. The word “usability” also refers to methods for improving ease-of-use during the design process.
Usability is defined by five quality components:
- Learnability: How easy is it for users to accomplish basic tasks the first time they encounter the design?
- Efficiency: Once users have learned the design, how quickly can they perform tasks?
- Memorability: When users return to the design after a period of not using it, how easily can they reestablish proficiency?
- Errors: How many errors do users make, how severe are these errors, and how easily can they recover from the errors?
- Satisfaction: How pleasant is it to use the design? ”
[5]
Initially, I sought to map these quality components to the tactics we assign to other quality attributes, but proved to be a fruitless endeavor. These were not action items but rather measurable attributes.
I was interested to note that in the same way that quality attributes may negatively impact each other, so too can these quality components. That is, learnability and efficiency are often at odds, similar to how one must strike a balance between the quality attributes of performance and availability, once the relative importance of each is determined.
Another way in which usability seems to vary from many other quality attributes is explored in the article “Designing software architectures for usability”, which points out that
“Most quality attributes focus on characteristics that are desirable from the point of view of the software development organization. Usability, on the other side, is a quality attribute perceived directly by the client/user”[6]
This has significant implications for the perception of the importance of usability concerns. The architectural business cycle as described in the textbook identifies the following major influences on the architecture: the stakeholders, the developing organization, the technical environment and the architect’s experience. The client/user is notably absent. Without representation from this unknown entity, how can we reliably ensure their needs are met (or even surmise what these needs are)?
The article did a fine job showing how usability considerations are increasingly recognized for their significance, and are in fact a legitimate quality attribute that can and should be accounted for throughout the architectural process.
Incorporating software development processes
The article introduces the notion of a Usability-Supported Architectural Pattern that may be used by software engineers to aid in meeting usability concerns through the development process. Many other articles I referred to also explored the need to provide engineers with tools or schemas that could be incorporated into their current processes.
Earlier work by two of the article’s authors explored the notion of an “Attribute-Based Architectural Style” that could “present implementation solutions for [specific usability] features..[and] include methods for performing a cost-benefit analysis for particular usability features.”[7]
Another article went on to emphatically state that “UCD will be considered more seriously at large if and only if a computer-assisted usability engineering (CAUsE) platform is available. CAUsE should support the whole process for gathering and analyzing the observational data, extracting relevant measures/feedback, and making decisions for changes. This CAUsE platform and the related usability measurement can also benefit from the long tradition in the field of software testing and measurement. The lack of UCD tools is one of the major technical obstacles that the HCI and software engineering communities should address.”[8]
It was interesting to note that while the problem of how to merge user-centered design and software development processes was widely recognized, no single best practice to do so has yet been identified. The suggestions on how to bridge the gap have consistent elements: specific details related to implementation as well as methods to analyze the data. It is good that it is increasingly being recognized that usability needs to be built into the system at its core, even if there is not yet a clear way to do so.
Measuring Usability
Much of the difficulty in perceiving usability as a quality attribute and ensuring it is incorporated into the development process at an early stage may be related to the qualitative nature of its measures. Indeed, the simple fact that usability requirements were perceived to be met simply by architecting a system of which the visual design could be changed easily following user testing belies the perception that usability principles are fluid.
Many of the articles I referred to a need to validate the extent to which a product is usable. In my experience as a web professional, I am dubious of the ability for this to provide a quality assessment.
As a web developer, I am responsible for providing code that adheres to accessibility guidelines. While an accessible site does not forcibly infer the site is usable, the two are related. One standard set of guidelines web developers often try to comply with are the Web Content Accessibility Guidelines developed by the World Wide Web Consortium. However, there has been great difficulty in being able to validate the extent to which a site is truly accessible, even when it appears to follow the guidelines. This is because so much is not testable. Checkpoint 14.1 of the WCAG 1.0 states “Use the clearest and simplest language appropriate for a site’s content.”[9] While a site developer may aim to meet this checkpoint, it is questionable if compliance can really be accessed. While there are tools currently available that can test for failures to meet certain guidelines, there cannot always be ways to measure for positive compliance.
Conclusion
While the experimental results discussed in the paper were not ground-breaking, I found many of the points raised in the article quite interesting. Current software development practices do not implicitly account for usability concerns, yet usability cannot be disregarded or minimalized through the architectural design process. There have been several proposals on how best to communicate these usability principles to developers (including the Usability-Supporting Architectural Patterns referred to in this article), yet a single best practice has not yet been established. I have my own reservations about the feasibility of a tool that can measure how usable a system is, but as the field of user-centered design develops and matures, we may find a way this can be done.
Citations
[1] Golden, John & Bass, 2005
[2] Golden, John & Bass, 2005
[3] Golden, John & Bass, 2005
[4] Seffah & Metzker, 2004
[5] Neilsen, 2003
[6] Bosch & Juristo, 2003
[7] Bass & John, 2000
[8] Seffah & Metzker, 2004
[9] World Wide Web Consortium, 1999
References
Len Bass, Paul Clements, Rick Kazman. (2003) Software Architecture in Practice - 2nd ed. Boston MA: Pearson Education, Inc.
Len Bass, Bonnie E. John, Natalia Juristo, Maria-Isabel Sanchez-Segura, “Usability-Supporting Architectural Patterns,” icse, pp. 716-717, 26th International Conference on Software Engineering (ICSE’04), 2004.
Len Bass , Bonnie E. John, Achieving usability through software architectural styles, CHI ‘00 extended abstracts on Human factors in computing systems, April 01-06, 2000, The Hague, The Netherlands
Len Bass, Bonnie E. John, Linking usability to software architecture patterns through general scenarios, Journal of Systems and Software, v.66 n.3, p.187-197, 15 June 2003
Jan Bosch , Natalia Juristo, Designing software architectures for usability, Proceedings of the 25th International Conference on Software Engineering, May 03-10, 2003, Portland, Oregon
George Casaday, Notes on a pattern language for interactive usability, CHI ‘97 extended abstracts on Human factors in computing systems: looking to the future, March 22-27, 1997, Atlanta, Georgia
Elizabeth M. Comstock , William M. Duane, Embed user values in system architecture: The Declaration of System Usability, Proceedings of the SIGCHI conference on Human factors in computing systems: common ground, p.420-427, April 13-18, 1996, Vancouver, British Columbia, Canada
Xavier Ferré , Natalia Juristo , Helmut Windl , Larry Constantine, Usability Basics for Software Developers, IEEE Software, v.18 n.1, p.22-29, January 2001
Eelke Folmer, Jilles van Gurp, Jan Bosch: Software Architecture Analysis of Usability. EHCI/DS-VIS 2004: 38-58
Elspeth Golden, Bonnie E. John, Len Bass: The value of a usability-supporting architectural pattern in software architecture design: a controlled experiment. ICSE 2005: 460-469
Jakob Nielsen. (2003, August 25) Usability 101: Introduction to Usability. Retrieved September 29, 2006 from http://www.useit.com/alertbox/20030825.html
Perzel, K. and Kane, D., “Usability Patterns for Applications on the World Wide Web,” Submitted to Pattern Languages of Programming 1999.
Ahmed Seffah, Alina Andreevskaia, “Empowering Software Engineers in Human-Centered Design,” icse, p. 653, 25th International Conference on Software Engineering (ICSE’03), 2003.
Ahmed Seffah , Eduard Metzker, The obstacles and myths of usability and software engineering, Communications of the ACM, v.47 n.12, p.71-76, December 2004
Kenia Sousa , Elizabeth Furtado , Hildeberto Mendonça, UPi: a software development process aiming at usability, productivity and integration, Proceedings of the 2005 Latin American conference on Human-computer interaction, p.76-87, October 23-26, 2005, Cuernavaca, Mexico
Web Content Accessibility Guidelines 1.0 (1999) Retrieved October 2, 2006 from http://www.w3.org/TR/WAI-WEBCONTENT/
