Maíra Greco de Paula, Bruno Santana da Silva, Simone Diniz Junqueira Barbosa. Departamento de Informática, PUC-Rio. R. Marquês de São Vicente, 225.
Using an Interaction Model as a Resource for Communication in Design Maíra Greco de Paula, Bruno Santana da Silva, Simone Diniz Junqueira Barbosa Departamento de Informática, PUC-Rio R. Marquês de São Vicente, 225 Rio de Janeiro, RJ, Brazil – 22453-900 {mgreco, brunosantana, simone}@inf.puc-rio.br Abstract
Many design models and representations have been proposed to support user-centered system design, such as scenarios, use cases, and prototypes. With these artifacts, designers typically deal with representations of fragments of the application, and sometimes have difficulties communicating with one another about design decisions. To face some of the communication challenges during design, we believe that we could use a global view of the system’s apparent behavior, from the users’ point of view. Such a representation would serve as a common reference for HCI designers from different disciplinary backgrounds, helping to foster communication among them. In our goal to promote a shared understanding of the application, we have investigated different professionals’ usage of MoLIC, an interaction modeling language that follows an interaction-as-conversation metaphor. MoLIC allows designers to build a blueprint of all the interactions that may take place when the application is used. Categories & Subject Descriptors: H.1.2 [Models and Principles]: User/Machine Systems General Terms: Design, Documentation, Human Factors Keywords: software design representations, interaction modeling, multidisciplinary design teams INTRODUCTION
It is well-known that multidisciplinary teams are necessary for designing high-quality interactive applications. Professionals from different disciplinary backgrounds bring distinct perspectives on problem framing, design issues, and on evaluating the impact of alternative solutions on the users’ daily lives and work practices. However, it is precisely this difference in perspective that sometimes proves to be a major challenge in having different professionals communicate and collaborate with each other in design activities. To face this challenge, we propose to use a shared representation to help the various members of an HCI design team to collaborate in the application design, e.g., graphics designers, psychologists, sociologists, software engineers, and so on. Scenarios, use cases, and prototypes are among the most
Copyright is held by the author/owner(s). CHI 2005, April 2–7, 2005, Portland, Oregon, USA. ACM 1-59593-002-7/05/0004.
widely used representations to support user-centered system design. However, we believe that they don’t provide an overall view of the application’s behavior, and that such a view is necessary to ensure that designers understand the consequences of their design decisions. Thus, we need a representation that organizes the content depicted in existing representations. It is important to note that we don’t claim that a single representation is enough to cover all the needs of every HCI professional. Instead, we propose to have a shared representation to serve as a reference to designers with distinct concerns, facilitating communication among them. It should also contribute to the creation of the specific representations used by each professional involved in interactive software design. Scenarios describe contextualized interaction stories, facilitating the designers’ and users’ understanding of the designers’ assumptions and design decisions [2]. However, the informal nature of scenarios makes it possible for inexperienced designers to build uninformative or even system-centered scenarios. Moreover, each scenario is usually related to one or few user goals, promoting a somewhat isolated understanding of a portion of the application. In real-world applications, design decisions are often scattered across many scenarios, making it difficult for designers to grasp the consequences of their decisions. Use cases have been used by software engineers to allow some HCI concerns to be addressed in sofware design. Unfortunately, use cases don’t necessarily promote usercentered design: it is not always clear whether use cases should focus on the system’s functionality, from a designer’s perspective, or on the external actors’ interaction with the system, from a user’s perspective. Also, it is unclear at what level of detail the interaction should be represented in use cases. At a more concrete level, HCI designers frequently use prototypes. However, since prototypes emphasize the user interface (as a product) more than the interaction process, they may be viewed as premature for representing the application in early design stages. In this work, the representation chosen to help foster communication among design members was MoLIC (acronym for “Modeling Language for Interaction as Conversation”), an interaction model that provides a blueprint of the apparent behavior being designed, from the users’ point-of-view [1]. MoLIC was devised to support
designers in reflecting about the solution being conceived [4]. We conducted a preliminary study about the use of MoLIC as a shared representation to which all members of the designed team may refer during the design process. The next sections introduce the semiotic engineering theory of HCI and the communication-centered approach to design within which this work is framed. In the fourth section, we briefly describe MoLIC, a candidate interaction model to play the role of the shared representation. We then describe the results of a preliminary study about the usage of MoLIC by professionals from different disciplinary backgrounds. We conclude the paper with some brief comments about the usage of MoLIC and directions for future research. THE SEMIOTIC ENGINEERING OF HCI
This work is grounded on semiotic engineering, a theory of HCI that characterizes human-computer interaction phenomena and provides an ontology from which HCI frameworks and models can be derived [3]. Semiotic engineering adopts a media perspective on the use of computer applications, investigating the designer-to-user metacommunication, i.e., how the signs engineered into the user interface tell the users how to communicate with the application to achieve the intended effects. The content of the designers’ message is who they believe users are, what they have interpreted as being the users needs, values, and preferences, and how they implemented their vision in this interactive system to allow users fulfill their actual goals. It is important to underscore the interpretive nature of the designers’ understanding of the material gathered and compiled during the analysis and requirements elicitation activities. MoLIC is an interaction model created within semiotic engineering. It represents all possible interactive conversations that users may have with the system, i.e., all the possible interaction paths, including alternative paths to achieve the same goal, and paths for the recovery from errors or interactive breakdowns [1]. In the next sections, we will argue for the possibility of using MoLIC as a shared resource to foster communication among HCI designers. COMMUNICATION-CENTERED DESIGN
Within semiotic engineering, we have used MoLIC as a shared representation to achieve two distinct goals: to represent the designer-to-user communication (achieved at interaction time), and to foster communication among design team members (during design). As such, MoLIC serves as a reference of how the application should behave, allowing professionals from different disciplinary backgrounds to discuss about and collaborate to the design decisions that affect each other’s work and the way in which users will interact with the application. Having agreed to commit to an interaction design solution represented in MoLIC, each professional may proceed with his own activities in whichever way he wishes, as long as
the established common vision is respected, i.e., the MoLIC blueprint is followed or revised. Regarding who should build this common representation, we assume that it will be built collectively, by HCI professionals, graphics designers, software engineers, and so on. We believe that the first draft representation will emerge during the initial design sessions, and hope that everyone is able to contribute to its elaboration and refinement. This way, MoLIC prevents interaction design decisions from being made too late in the development process (i.e. in later specification or implementation), or by non-HCI professionals (i.e. engineers or programmers). As the designers’ vision matures into a more stable version of the application’s blueprint in MoLIC, each professional will have a concrete resource to use as a basis for creating the representations used in his own field and concerning the design issues that belong to his practice. MoLIC: a Modeling Conversation
Language for
Interaction
as
MoLIC represents the user-system interaction as threads of conversation that users may (or must) have with the application in order to achieve their goals. MoLIC was not devised to replace existing representations, but to complement them. The event sequences depicted in scenarios are organized in a MoLIC diagram, which reveals the relationships and intersections between scenarios, from a user’s point-of-view. It is important to note that MoLIC was devised for human usage; it is not meant to be a formal, machine-processable model. The MoLIC diagram is complemented by an ontology of signs. Here, we use the term sign to denote any given element in the application domain or at the user interface, to which a user may attribute meaning with respect to his goal or task, or to the application itself. The goal of the sign ontology is also to share knowledge among the design team members. The signs that are represented in the ontology are those that will be presented to or manipulated by users during their conversation with the system, together with their definition (descriptive and related to the users’ goals) and the relationships among them. This ontology is built pari passu the MoLIC diagram and the scenarios. The notation to represent the ontology hasn’t yet been thoroughly defined and is beyond the scope of this paper. MoLIC’s Diagrammatic Notation
A MoLIC diagram basically depicts the turn-taking between user and system, forming conversation threads. Although the graphical representation resembles a statetransition diagram, the coincidence is only superficial: we focus on the communication aspects of the interaction, such as turn-taking, topic and subtopic structures, and some mismatches between user' intentions and system behavior, encouraging a careful design for the recovery from interaction breakdowns.
In a MoLIC diagram, there are two different kinds of nodes, indicating the user’s or the system’s turn to “say something”. We represent the user’s turn to make a decision about how the conversation should proceed in a scene, represented by a rounded rectangle, containing a label describing the topic of the conversation at that moment, and a set of dialogs and signs related to that topic (to achieve a certain goal or subgoal). In order to facilitate the representation of scenes that can be accessed from anywhere within the application (e.g. from menu items), MoLIC diagrams contain ubiquitous accesses to these scenes, represented by gray, rounded rectangles. The system’s turn in the conversation is represented by a “black box”, indicating that users cannot perceive what is going on inside the system processing nodes. Linking scenes to system processes, and vice-versa, are transition utterances. Transition utterances stemming from scenes represent changes in focus or a conclusion of the conversation topic, as caused by a user’s choice, indicated by the transition label. Those stemming from system processes represent the result of that processing, indicating whether the user’s request was completed successfully or whether a breakdown or system error has occurred. Interaction breakdowns in MoLIC
Repair utterances are an inherent part of human conversation, and so are breakdown prevention and handling in user-system interaction. Considering the interaction as conversation, designers are encouraged to represent not only how users should perform tasks under normal conditions, but also how to avoid or deal with mistaken or unsuccessful situations. When potential breakdown situations are detected or predicted during interaction modeling, they should be represented in the
MoLIC diagram by breakdown tags. These tags are used to identify the interaction mechanisms designed to deal with potential or actual breakdowns, according to the following categories: Passive prevention (PP): documentation or online instructions designed to prevent breakdowns from happening (e.g. the format of the data expected in a field). Active prevention (AP): active mechanisms that will prevent breakdowns from occurring (e.g. forbidding the user to type in letters or symbols in numerical fields). Supported prevention (SP): asking the user to decide if a situation is a breakdown or not (e.g., confirmation messages such as “File already exists. Overwrite?”). Error capture (EC): errors that are detected by the system and must be notified to users, but for which there is no remedial action (e.g., when a file is corrupted). Supported repair (SR): informing the user about a detected breakdown and allowing him to correct it (e.g., presenting an error message and the previously filled fields for the user to correct the problem). MoLIC diagrams may be represented in an abbreviated or an extended form. The abbreviated form includes the dialogs’ topics, but not the individual signs or utterances composing the dialogs. The extended MoLIC diagram includes the signs associated to each dialog. For each sign, it represents whether they are mandatory, whether they have a default value, the abstract user interface widget associated to the sign (simple choice, free text, etc.), and associated breakdown tags, if necessary. Figure 1 shows a MoLIC diagram for a hotel reservation application at an intermediary stage of design, in which signs for two scenes have already been defined.
c Figure 1: A sample MoLIC diagram.
The Use of MoLIC by Different Professionals
We have conducted a preliminary study of this approach, interviewing HCI professionals, graphics designers, psychologists, and software developers using MoLIC. Our goal was to learn about the usefulness and understanding of MoLIC as a representation of the interaction. In our preliminary findings, the usage of MoLIC was found to be effective by all team members. The recurring observations were that the notation is easily understood, and that MoLIC is useful as a resource for each professional to build his own design representation(s), specifying or detailing the application in his field of work, addressing his own needs and perspectives on the designed artifact. The main contribution, in their opinion, is that it clearly defines how the interaction should take place. The psychologist said that, despite not having a tradition of working with graphical notations, the MoLIC diagrammatic notation was easy to understand. In his opinion, psychologists would certainly be able to contribute to the construction of MoLIC diagrams, especially by providing a deeper understanding of the users’ expectations and wishes regarding each represented goal. When asked about if and how MoLIC could contribute to his activities, he said that it would be very useful for developing interview scripts and test plans for qualitative evaluation of the user interface. In his opinion, having all the possible interaction paths clearly represented in the diagram would help him perform his work faster, and the resulting interview scripts would probably be more comprehensive. From the graphics designers’ point-of-view, representing the interaction using MoLIC makes sure that relevant HCI decisions are not lost. A global view of the interaction processes was viewed as an important resource that is rarely provided to these professionals, for they need to be aligned with the shared vision of the solution. He found that MoLIC wouldn’t limit their creativity. Instead, it defined the content for which they must create the expression. Moreover, they confirmed the need for the sign ontology, by stating that he would like MoLIC to include a choice of standard widgets for each sign, from which they could draw when creating the user interface layout. The software developers were glad to receive a clear definition of the interaction, which traditional software engineering models and representation languages do not provide. They found it was a welcome complement to the storyboards they usually receive, but which leave some interaction paths unspecified and thus prone to rushed or uninformed decisions.
addition, it is important that it provide a blueprint of the application’s apparent behavior, from a user’s point-ofview, instead of a fragmented or system-centered view of the application. We have chosen MoLIC, an interaction modeling language, as a candidate to be the shared representation. Based on the preliminary case studies and a deeper analysis of interaction as conversation, MoLIC is being extended to include dialog structures (to represent sequential and mutually exclusive dialogues, for instance); multi-user interactions (in which interconnected MoLIC diagrams are used to represent each user’s interaction with the system); and to increase the contribution of and the benefits to different professionals, such as software engineers and graphics designers. There are some HCI concerns that haven’t yet been addressed, such as concurrency, interleaving, and order permutation.We have identified the benefits of using MoLIC at different levels of abstraction: from less detailed (or even incomplete) diagrams at early stages of design, using only the basic MoLIC elements, to promote the designers’ reflection about alternative solutions; and introducing more refined elements at later stages of design, as we move towards interaction specification. Besides using MoLIC in multidisciplinary HCI design teams, we are also investigating the use of MoLIC as a concrete resource for software design, both for representing HCI design patterns and for deriving UML diagrams. Some works dedicated to the integration of human-computer interaction and software engineering extend UML to represent HCI concerns [5]. However, UML-based approaches make it difficult to separate software engineering and UI design concerns, even when this would be possible, hindering the designers’ reflection and communication about relevant HCI concerns. ACKNOWLEDGEMENTS
The authors thank CNPq, CAPES, and their colleagues at the Semiotic Engineering Research Group at PUC-Rio for ongoing support and contribution to their research. REFERENCES
[1]
[2]
[3]
CONCLUDING REMARKS
In this paper, we argued for the importance of having a shared representation to foster communication among HCI designers from multidisciplinary backgrounds. Such a representation must be easily understood and collectively built by professionals from all the involved disciplines. In
[4]
[5]
Barbosa, S.D.J.; Paula, M.G. “Designing and Evaluating Interaction as Conversation: a Modeling Language based on Semiotic Engineering” In 10th International Workshop, DSV-IS 2003, Madeira Island, Portugal, LNCS, vol. 2844, 2003, pp. 16–33. Carroll, J. M. (ed) Scenario-based design: envisioning work and technology in system development, New York, Wiley. 1995. de Souza, C. S., The Semiotic Engineering of HumanComputer Interaction, The MIT Press, 2005, in press. Schön, D. The Reflective Practitioner: How Professionals Think in Action. New York: Basic Books. 1983. van Harmelen, M. (ed.) Object Modeling and User Interface Design. Addison-Wesley. 2001.
