Reconciling usability and interactive system architecture using patterns

https://doi.org/10.1016/j.jss.2008.04.037Get rights and content

Abstract

Traditional interactive system architectures such as MVC [Goldberg, A., 1984. Smaltalk-80: The Interactive Programming Environment, Addison-Wesley Publ.] and PAC [Coutaz, J., 1987. PAC, an implementation model for dialog design. In: Interact’87, Sttutgart, September 1987, pp. 431–436; Coutaz, J., 1990. Architecture models for interactive software: faillures and trends. In: Cockton, G. (Ed.), Engineering for Human–Computer Interaction, Elsevier Science Publ., pp. 137–153.] decompose the system into subsystems that are relatively independent, thereby allowing the design work to be partitioned between the user interfaces and underlying functionalities. Such architectures extend the independence assumption to usability, approaching the design of the user interface as a subsystem that can designed and tested independently from the underlying functionality. This Cartesian dichotomy can be fallacious, as functionalities buried in the application’s logic can sometimes affect the usability of the system. Our investigations model the relationships between internal software attributes and externally visible usability factors. We propose a pattern-based approach for dealing with these relationships. We conclude by discussing how these patterns can lead to a methodological framework for improving interactive system architectures, and how these patterns can support the integration of usability in the software design process.

Introduction

Software architecture is defined as the fundamental design organizations of a system; they are embodied in its components, their relationships to each other and the environment, and the principles governing its design, development and evolution [ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems]. In addition, it encapsulates the fundamental entities and properties of the application that generally insure the quality of application (Kazman et al., 2000).

In the field of interactive systems engineering, architectures of the 1980s and 1990s such as MVC (Goldberg, 1984) and PAC (Coutaz, 1987, Coutaz, 1990) are based on the principle of separating the functionality from the user interface. The functionality is what the software actually does and what information it processes. The user interface defines how this functionality is presented to end-users and how the users interact with it. The underlying assumption is that usability, the ultimate quality factor, is primarily a property of the user interface. Therefore separating the user interface from the application’s logic makes it easy to modify, adapt or customize the interface after user testing. Unfortunately, this assumption does not ensure the usability of the system as a whole.

We now realize that system features can have an impact on the usability of the system, even if they are logically independent from the user interface and not necessarily visible to the user. Bass observed that even if the presentation of a system is well designed, the usability of a system could be greatly compromised if the underlying architecture and designs do not have the proper provisions for user concerns (Bass et al., 2001, Raskin, 2000). We propose that software architecture should define not only the technical interactions needed to develop and implement a product, but also interactions with the users.

At the core of this vision is that invisible components can affect usability. By invisible components, we mean any software entity or architectural attribute that does not have visible cues on the presentation layer. They can be an operation, data, or a structural attribute of the software. Examples of such phenomena are commonplace in database modeling. Queries that were not anticipated by the modeler, or that turn out to be more frequent than expected, can take forever to complete because the logical data model (or even the physical data model) is inappropriate. Client-server and distributed computer architectures are also particularly prone to usability problems stemming from their “invisible” components.

Designers of distributed applications with Web interfaces are often faced with these concerns: They must carefully weigh what part of the application logic will reside on the client side and what part will be on the server side in order to achieve an appropriate level of usability. User feedback information, such as application status and error messages, must be carefully designed and exchanged on the client and server part of the application, anticipating response time of each component, error conditions and exception handling, and the variability of the computing environment. Sometimes, the Web user interface becomes crippled by the constraints imposed by these invisible components because the appropriate style of interactions is too difficult to implement.

Like other authors (Bass et al., 2001, Folmer and Bosch, 2003), we argue that both software developers implementing the systems features and usability engineers in charge of designing the user interfaces should be aware of the importance of this intimate relationship between features and the user interfaces. This relationship can inform architecture design for usability. With the help of patterns, this relationship can help integrate usability concerns in software engineering. Beyond proposing a list of patterns to solve specific problems, our long-term goal is to define a framework for studying and integrating usability concerns in interactive software architecture via patterns.

The second section discusses the related word dealing with the architectures for interactive software. In Sections 3 Identifying and categorizing typical scenarios, 4 Patterns as solutions to the problems documented as scenarios, we focus on specific ways in which internal software properties can have an impact on usability criteria. In Section 5, we attempt to provide a more general, theoretical framework for the relationships between usability and invisible software attributes. Finally, we conclude with the future investigations.

Section snippets

Related work

A large number of architectures for interactive software have been proposed, e.g., Seeheim model, model-view-controller (MVC), arch/slinky, presentation abstraction control (PAC), PAC-amadeus and model-view-presenter (MVP) (Bass et al., 1998). Most of these architectures distinguish three main components: (1) abstraction or model, (2) control or dialog and (3) presentation. The model contains the functionality of the software. The view provides graphical user interface (GUI) components for a

Identifying and categorizing typical scenarios

The first step in our approach for achieving usability via software architecture and patterns is to identify typical situations that illustrate how invisible components of the model might affect usability. Each typical situation is documented using a scenario. Scenarios are widely used in HCI and software engineering (Carroll, 2000). Scenarios can improve communication between user interface specialists and software engineers who design invisible components – this communication is essential in

Patterns as solutions to the problems documented as scenarios

There are different ways to document solutions for the problems described in the preceding scenarios. In our framework, we have been using design patterns (Alexander et al., 1997, Gamma et al., 1995). Since the relationship between usability and internal software properties defines the problem, it has been added into the pattern descriptions that follow. This measurement relationship is what makes a pattern a cost effective solution. In short, if a pattern does not improve at least one of the

Modeling cause-effect relationships between software elements and usability

In Sections 3 Identifying and categorizing typical scenarios, 4 Patterns as solutions to the problems documented as scenarios, we focused on specific ways in which internal software properties can have an impact on usability criteria. In this section, we attempt to provide a more general, theoretical framework for the relationships between usability and invisible software attributes. In particular, among the huge or potentially infinite number of ways that invisible components can affect

Conclusion and future investigations

In this paper, we first identified specific scenarios that how invisible software components can have an effect on the usability of the interactive system. Then, we provided a list of patterns that solved the problems described in the scenarios. This research effort can benefit software architecture designers and developers, who can use our approach in two different ways. First, the scenarios can serve as a checklist to determine whether important usability features (external attributes) have

References (22)

  • Eelke Folmer et al.

    Bridging Patterns – an approach to bridge gaps between SE and HCI

    Journal of Information and Software Technology

    (2006)
  • C. Alexander et al.

    A Pattern Language

    (1997)
  • L. Bass et al.

    Software Architecture in Practice

    (1998)
  • Bass L., John B.E., Kates J., 2001. Achieving Usability Through Software Architecture, SEI Report, Carnegie Mellon...
  • F. Buschmann et al.

    Pattern-Oriented Software Architectures: A System of Patterns

    (1996)
  • J.M. Carroll

    Scenario-Based Design of Human–Computer Interactions

    (2000)
  • Coplien, J.O., 2001. A pattern definition, patterns home page, retrieved on 2005. Available at:...
  • Coutaz, J., 1987. PAC, an implementation model for dialog design. In: Interact’87, Sttutgart, September 1987, pp....
  • J. Coutaz

    Architecture models for interactive software: failures and trends

  • E. Folmer et al.

    Architecting for usability; a survey

    Journal of Systems and Software

    (2003)
  • E. Gamma et al.

    Design Patterns: Elements of Reusable Object-Oriented Software

    (1995)
  • Cited by (35)

    • Addressing Usability Requirements in Mobile Software Development

      2014, Relating System Quality and Software Architecture
    • A machine learning-based usability evaluation method for eLearning systems

      2013, Decision Support Systems
      Citation Excerpt :

      It has also been defined as the extent to which an application allows users to accomplish specified goals efficiently, effectively, and satisfactorily [47]. Formally defined, usability stands for “the effectiveness, efficiency, and satisfaction with which specified users can achieve goals in particular environments” [25]; “the capability to be used by humans easily and effectively”; “quality in use” [6,7]; “how easy it is to find, understand and use the information displayed on a web-based system” [35]; and “the ultimate quality factor” for software architecture [70]. The International Standardization Organization (ISO) defines usability as “the extent to which a product can be used by specified users to achieve specified goals with efficiency, effectiveness, and satisfaction in a specified context of use” [30].

    • UseLearn: A novel checklist and usability evaluation method for eLearning systems by criticality metric analysis

      2010, International Journal of Industrial Ergonomics
      Citation Excerpt :

      An additional component that should be added to this definition is usefulness; that is, a highly usable application will not be embraced by users if it fails to contain content that is relevant and meaningful to them (Miller, 2005). Formally defined, usability stands for “the capability to be used by humans easily and effectively”; “quality in use” (Bevan, 1999); “the effectiveness, efficiency, and satisfaction with which specified users can achieve goals in particular environments” (Hornbaek, 2006); how easy it is to find, understand, and use the information displayed on a web-based system (Keevil, 1998); and “the ultimate quality factor” for the software architecture (Seffah et al., 2008). The International Standardization Organization (ISO) defines usability as the extent to which a product can be used by specified users to achieve specified goals with efficiency, effectiveness, and satisfaction in a specified context of use (ISO 9241-11, 1998).

    View all citing articles on Scopus
    View full text