Interactive Systems. Design Specification, and Verification: 12th International Workshop, DSVIS 2005, Newcastle upon Tyne, UK, July 13-15, 2005, ... (Lecture Notes in Computer Science, 3941) 9783540341451, 3540341455

Citation preview

Lecture Notes in Computer Science Commenced Publication in 1973 Founding and Former Series Editors: Gerhard Goos, Juris Hartmanis, and Jan van Leeuwen

Editorial Board David Hutchison Lancaster University, UK Takeo Kanade Carnegie Mellon University, Pittsburgh, PA, USA Josef Kittler University of Surrey, Guildford, UK Jon M. Kleinberg Cornell University, Ithaca, NY, USA Friedemann Mattern ETH Zurich, Switzerland John C. Mitchell Stanford University, CA, USA Moni Naor Weizmann Institute of Science, Rehovot, Israel Oscar Nierstrasz University of Bern, Switzerland C. Pandu Rangan Indian Institute of Technology, Madras, India Bernhard Steffen University of Dortmund, Germany Madhu Sudan Massachusetts Institute of Technology, MA, USA Demetri Terzopoulos University of California, Los Angeles, CA, USA Doug Tygar University of California, Berkeley, CA, USA Moshe Y. Vardi Rice University, Houston, TX, USA Gerhard Weikum Max-Planck Institute of Computer Science, Saarbruecken, Germany

3941

Stephen W. Gilroy Michael D. Harrison (Eds.)

Interactive Systems Design, Specification, and Verification 12th International Workshop, DSVIS 2005 Newcastle upon Tyne, UK, July 13-15, 2005 Revised Papers

13

Volume Editors Stephen W. Gilroy Michael D. Harrison University of Newcastle upon Tyne School of Computing Science Newcastle upon Tyne, NE1 7RU, UK E-mail: {steve.gilroy,michael.harrison}@ncl.ac.uk

Library of Congress Control Number: 2006925462 CR Subject Classification (1998): H.5.2, H.5, I.3, D.2, F.3 LNCS Sublibrary: SL 2 – Programming and Software Engineering ISSN ISBN-10 ISBN-13

0302-9743 3-540-34145-5 Springer Berlin Heidelberg New York 978-3-540-34145-1 Springer Berlin Heidelberg New York

This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable to prosecution under the German Copyright Law. Springer is a part of Springer Science+Business Media springer.com © Springer-Verlag Berlin Heidelberg 2006 Printed in Germany Typesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, India Printed on acid-free paper SPIN: 11752707 06/3142 543210

Preface

The 12th year of this workshop brought further development to familiar themes but also welcomed inclusion of less familiar topics such as “experience” and “quality-based design.” The two keynote speakers, Cliff Jones and Peter Wright, described contrasting research and in so doing added zest to the meeting, emphasising the interdisciplinary breadth of the problems of interactive system design and verification. Cliff Jones, taking an approach that is familiar to the workshop faithful, discussed the role that a careful formal framing plays in specifying how an interactive system relies on its environment, including users. Peter Wright, in contrast, discussed the nature of human experience and how new conceptions of user experience can critically inform interaction design theory, principles and practice. As usual, the submitted papers placed a strong emphasis on task representation as a means of modelling the requirements for the interactive system. CTT appears to be emerging as a defacto standard for describing tasks within this community and several papers describe model-orientated approaches based on task representation. Montero et al. address a broad framework rendered in terms of a tool, while Ponsard et al. give a specific example of model-based design and Nobrega et al. deal with the more specific issue of mapping CTT to UML. Other papers consider different aspects of conceptualising the design. Paterno and Volpe consider how to move from sketches or informal descriptions to task representations, while Paquette and Schneider deal with templates that ease the process of producing task descriptions. Naghsh et al. on the other hand consider annotations and paper prototypes. A further set of papers deals with the peculiar and novel requirements of mobile and migratory applications. Hence there are papers about platform fusion (Dupuy-Chessa et al.), a taxonomy of migratory user interfaces (Berti et al.). As usual there are papers that concern the modelling and analysis of properties such as moding (Gow et al.), menus (Zhang et al.), the verification of haptic algorithms (de Boeck et al.) and group interactions (ter Beek et al.). Other papers hint at the more radical agenda suggested by Peter Wright’s keynote address. The paper by Dix et al. addresses a framework for thinking about the design of computer interfaces that support performance. Two papers discuss how distributed cognition issues might be addressed in design. Blandford and Furniss’s paper draws on claims analysis and distributed cognition, while Campos and Doherty fold an analysis of information resources into a formal approach. Finally, Lee et al. address an approach to measuring user preferences using utility trade-offs. The workshop stimulated new ideas, working groups reflected on present and future issues in the community. We fully expect that the meeting triggered significant collaborations. The location of the workshop, the North East of England, is an area full of character and history. Overall the workshop was a rewarding and illuminating experience. From the 60 or so papers that were submitted to the conference, the reviewers worked hard to get down to the 20 papers included in these proceedings. Submissions

VI

Preface

came from a range of countries, including the UK, Italy, France, Belgium, Spain, Korea, Canada, USA, Portugal, Ireland, Brazil and Switzerland. The papers are organised into six themes reflecting common issues and approaches explored by the accepted papers. In addition, four papers summarise break-out discussions. These centre on issues that the workshop participants chose as being important in future research that might be presented in later DSVIS meetings. In summary, we hope that the proceedings will give the reader a feeling for the values and goals of the community and provide a context that links all of the papers presented here. Stephen Gilroy Michael Harrison

Organisation

Conference Programme Chair Michael Harrison

University of Newcastle upon Tyne, UK

Reviews and Proceedings Stephen Gilroy

University of Newcastle upon Tyne, UK

Conference Support Annabel Bixby Christine Wisher

University of Newcastle upon Tyne, UK University of Newcastle upon Tyne, UK

Programme Committee Remi Bastide Ann Blandford Jos´e C. Campos Anke Dittmaar Alan Dix Gavin Doherty Peter Forbrig T.C. Nicholas Graham Philip Gray Chris Johnson Joaquim A Jorge Rick Kazman Karsten Loer Panos Markopoulos Mieke Massink Laurence Nigay Phillippe Palanque Fabio Patern`o Chris Roast Kevin Schneider Harold Thimbleby Jean Vanderdonckt Additional Reviewers Patrick Olivier Shamus Smith

LIIHS-IRIT, France UCL, UK University of Minho, Portugal University of Rostock, Germany Lancaster University, UK University of Dublin, Trinity College, Ireland University of Rostock, Germany Queen’s University, Kingston, Canada University of Glasgow, UK University of Glasgow, UK IST-UTL, Portugal Carnegie Mellon University, USA Germanischer Lloyd AG, Germany Technische Universiteit Eindhoven, Netherlands CNR-ISTI, Italy Universit´e Joseph Fourier, France LIIHS-IRIT, France CNR-ISTI, Italy Sheffield Hallam University, UK University of Saskatchewan, Canada University of Wales, Swansea, UK Universit´e Louvain-La-Neuve, Belgium

University of Newcastle upon Tyne, UK Durham University, UK

VIII

Organisation

Supporting Societies British Computing Society British HCI Group IFIP Working Group Informatics Research Institute, University of Newcastle upon Tyne

Table of Contents

Keynote User Experience and the Idea of Design in HCI Peter Wright, Mark Blythe, John McCarthy . . . . . . . . . . . . . . . . . . . . . . .

1

Teams and Groups Formalising Performative Interaction Alan Dix, Jennifer G. Sheridan, Stuart Reeves, Steve Benford, Claire O’Malley . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

DiCoT: A Methodology for Applying Distributed Cognition to the Design of Teamworking Systems Ann Blandford, Dominic Furniss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

Towards Model Checking Stochastic Aspects of the thinkteam User Interface Maurice H. ter Beek, Mieke Massink, Diego Latella . . . . . . . . . . . . . . . .

39

Incident and Accident Investigation Techniques to Inform Model-Based Design of Safety-Critical Interactive Systems Sandra Basnyat, Nick Chozos, Chris Johnson, Philippe Palanque . . . . .

51

Sketches and Templates Natural Modelling of Interactive Applications Fabio Patern` o, Marco Volpe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

67

Task Model Simulation Using Interaction Templates David Paquette, Kevin A. Schneider . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

78

Investigating Annotation in Electronic Paper-Prototypes ¨ Amir M. Naghsh, Andy Dearden, Mehmet B. Ozcan ................

90

Away from the Desktop Test of the ICARE Platform Fusion Mechanism Sophie Dupuy-Chessa, Lydie du Bousquet, Jullien Bouchet, Yves Ledru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

X

Table of Contents

A Method for the Verification of Haptic Algorithms Joan De Boeck, Chris Raymaekers, Karin Coninx . . . . . . . . . . . . . . . . . . 114 A Specification Language and System for the Three-Dimensional Visualisation of Knowledge Bases El Mustapha El Atifi, Gilles Falquet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Migration and Mobility A Calculus for the Refinement and Evolution of Multi-user Mobile Applications W. Greg Phillips, T.C. Nicholas Graham, Christopher Wolfe . . . . . . . . 137 A Taxonomy for Migratory User Interfaces Silvia Berti, Fabio Patern` o, Carmen Santoro . . . . . . . . . . . . . . . . . . . . . . 149 Solving the Mapping Problem in User Interface Design by Seamless Integration in IdealXML Francisco Montero, V´ıctor L´ opez-Jaquero, Jean Vanderdonckt, Pascual Gonz´ alez, Mar´ıa Lozano, Quentin Limbourg . . . . . . . . . . . . . . . 161

Analysis Tools Concept Analysis as a Formal Method for Menu Design Guo-Qiang Zhang, Gongqin Shen, Ye Tian, Jiayang Sun . . . . . . . . . . . . 173 Supporting Resource-Based Analysis of Task Information Needs Jos´e Creissac Campos, Gavin J. Doherty . . . . . . . . . . . . . . . . . . . . . . . . . 188 Automatic Critiques of Interface Modes Jeremy Gow, Harold Thimbleby, Paul Cairns . . . . . . . . . . . . . . . . . . . . . . 201 Quantitative Measurement of Quality Attribute Preferences Using Conjoint Analysis Kwang Chun Lee, Ho-Jin Choi, Dan Hyung Lee, Sungwon Kang . . . . . 213

Model-Based Design Processes and Tools A Model-Based Design Process for Interactive Virtual Environments Erwin Cuppens, Chris Raymaekers, Karin Coninx . . . . . . . . . . . . . . . . . 225 Mapping ConcurTaskTrees into UML 2.0 Leonel N´ obrega, Nuno Jardim Nunes, Helder Coelho . . . . . . . . . . . . . . . . 237

Table of Contents

XI

Goal-Oriented Design of Domain Control Panels Christophe Ponsard, Nadiya Balych, Philippe Massonet, Jean Vanderdonckt, Axel van Lamsweerde . . . . . . . . . . . . . . . . . . . . . . . . . 249

Group Discussions Future Challenges of Model-Based Design Sandra Basnyat, Joan De Boeck, Erwin Cuppens, Leonel N´ obrega, Francisco Montero, Fabio Patern` o, Kevin Schneider . . . . . . . . . . . . . . . . 261 Supporting Values Other Than Usability and Performance Within the Design Process ¨ Nick Chozos, Jennifer G. Sheridan, Ozcan Mehmet, Amir Naghsh, Kwang Chun Lee, Ann Blandford . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 Ambience and Mobility Gavin J. Doherty, Lydie du Bousquet, Jos´e Creissac Campos, El Mustapha El Atifi, Gilles Falquet, Mieke Massink, Carmen Santoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Outdated Ideas of the Design Process and the Future of Formal Models, Methods and Notations Dominic Furniss, Alan Dix, Christophe Ponsard, Guo-Qiang Zhang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

User Experience and the Idea of Design in HCI Peter Wright1 , Mark Blythe1 , and John McCarthy2 1 Department of Computer Science, University of York, Heslington, York Y010 5DD, UK {peter.wright, mark.blythe}@cs.york.ac.uk 2 Department of Applied Psychology, University College Cork, Cork, Ireland [email protected]

Abstract. In this paper we argue that the idea of design in HCI is changing. For many years the design-as-engineering approach has dominated HCI research and practice, but now technological developments and new conceptions of ’the user’ require more interdisciplinary conceptions of design. In particular, the turn to experience in HCI has lead us to consider a design-as-craft perspective which we exemplify in this paper by the work of digital jeweller, Jayne Wallace. But our aim is not to supplant one design perspective with an other. On the contrary, we argue that experience design requires a new form of radically interdisciplinary dialogue between different design perspectives that span the arts, sciences and humanities. However, such radically interdisciplinary dialogue is not without its problems and points of contention. We conclude by arguing that not only new conceptual tools but also new HCI curricula may be helpful in achieving this interdisciplinary dialogue.

1 Introduction Fifteen years ago the idea of design in HCI was taken for granted and not a point of concern or discussion. Design meant the process of modelling users and systems and specifying system behaviour such that it fitted the users’ tasks, was efficient, easy to use and easy to learn. In short, design in HCI was about engineering usability. Research agendas around this idea involved how best to model the user and to overcome the technical problems with specifying interactive programs in a way that promoted usability. The translation from the specification of user tasks to the specification of system dialogues presented significant technical interest and research opportunities but was not seen as fundamentally problematical. It was simple to see that designing the behaviour and visual appearance of a system to match the user’s tasks, goals and action possibilities was a fundamentally sound proposition, which could be progressed not only as a human factors enterprise (task modeling, cognitive functional analysis, etc.) but also a formal software engineering enterprise [17]. But more recently various technological developments have led to a questioning of this idea of design in HCI. The confluence of information and communications technologies, and the reconceptualisation of interactive systems as new media [5] brings a much broader set of ideas about what it means to design an interactive system and S.W. Gilroy and M.D. Harrison (Eds.): DSVIS 2005, LNCS 3941, pp. 1–14, 2006. c Springer-Verlag Berlin Heidelberg 2006 

2

P. Wright, M. Blythe, and J. McCarthy

indeed what it is that is being designed. Just consider for example, some common terms that permeate text books and research papers in HCI: – – – – – –

User-centred design Dialogue design Information design Interaction design Emotional design Experience design

What is clear is that design has always been a central concern, but when Norman and others [23] introduced the idea of user-centred design there was little argument about what it was that was being designed—PCs and other desk-based computer interfaces. But the remainder of the list speaks to changing concerns. It appears we no longer design dialogue but interactions, information spaces, affect and now, user experience. Moving down the list also reveals differences in our understanding of ‘the user’—the user as someone who engages in dialogue through to someone who has an experience with- or through- the technology. This raises the broader question of whether design means the same thing with these different conceptions of the user. Can we design experiences in the same way as we design dialogues? So the question is whether these changes to the focus of study in HCI have any implications for what our idea of design is or should be? Our recent research programme exploring theory and method for experience-centred design has led us to conclude that we need to change our ideas about design in HCI. Within HCI research there is a tendency to simplify accounts of the idea of design, the most common of which is a simplification to a single, linear developmental trajectory wherein one technique, tool or viewpoint, overwrites its earlier predecessor. For example, – – – – –

First came batch processing, then command line, then GUI. . . First came task analysis, then scenario-based design, then personae-based design. . . First came the user as human factor then as human actor then. . . First the user was a cog in a virtual machine now the user is a consumer. . . . First came psychology, then ethnomethodology, then phenomenology. . .

These simplifications are often pedagogically useful but potentially misleading. It seems more appropriate (certainly as we view HCI practice as it is on the ground today) to understand these as coexisting perspectives, but where at certain times or in certain situations, one view, one metaphor, or one practice, is more central than another, one argument or one discourse is the dominant discourse for a while. Such a multi-perspectival view leads us to consider the boundaries between these accounts and encourages a dialogue between them. The quality of that dialogue will determine the effectiveness of our multi-disciplinary approach. A dialogue that tries to reduce ideas on the margins to more central ideologies will tend to stifle creativity, dialogues which at least for a time try to reverse centre and margin, or dialogues which strive to avoid replicating centre-margin distinctions, tend to foster creativity [1]. A number of different perspectives on HCI design already exist, ranging from engineering through to design as arts and crafts. If practitioners and researchers with these different perspectives can be helped to work together in some way then the new challenges of HCI

User Experience and the Idea of Design in HCI

3

design will be more easily met. We want to argue that this can be best done by a kind of radical interdisciplinary research programme. By radical interdisciplinarity, we mean not just psychologists, electronic engineers and computer scientists talking together and collaborating, for these groups fundamentally share a common idea of design. We mean psychologists, computer scientists, and electronics engineers talking to visual and performance artists, industrial designers, product designers and so on. A kind of crossfaculty collaboration that Buchanan refers to as a liberal arts of design [7]. But in order for such radical interdisciplinarity to work and in order to be able to engage meaningfully and productively across these radically interdisciplinary boundaries we need a much deeper critical understanding of what design thinking or design practice is both within the discipline of HCI (which is broad enough as it is) and within these other disciplines. We also need to explore ways in which the difficult job of dialogue across boundaries can be achieved.

2 Design-as-Engineering One perspective on design that has held a central position in HCI at times is what we have termed the design-as-engineering perspective but which some authors have referred to as the conservative view of design [12]. In this account design is seen as going from a fixed problem statement (or requirements specification), to an abstract specification of the solution that is then refined down into an actual implemented solution through a sequence of well-prescribed steps. The design problem, which is seen as given when design begins, may be broken down into smaller parts in order to divide and conquer. This breakdown is followed by a synthesis stage in which solutions to problem parts are aggregated into an overall design solution. This approach is at the heart of most software engineering and formal approaches to system design. Within this approach the emphasis is on proceduralising as much of the design process as possible to ensure knowledge is independent of individual designers and hence the process is replicable. Fallman [12] describes it as the conservative account to emphasise the idea that system properties and behaviours specified first at the abstract level are conserved throughout the subsequent refinement steps. Fallman describes the approach thus: ”According to this account of design, the design process is supposed to progress gradually from the abstract (requirements specifications) to the concrete (resulting artifacts). Progress is achieved through following a sequence of well-described, discrete and rational and structured methodological steps. A good designer in this tradition is someone who is able to follow prescribed action. This tends to de-emphasise the role of the designer, striving towards a disembodied design process built on structured methods and externalised guidelines rather than on the skills and judgment of individual designers.” p. 226. Within HCI, the kinds of approaches to design that seem to fit this account very well are exemplified by methodologies such as MUSE [19] and approaches to usability engineering proposed by both Nielsen [22] and Whiteside et al [28]. Within the more formal software engineering world of HCI, the engineering account is exemplified by approaches to specification based on abstract modelling of the user and the system

4

P. Wright, M. Blythe, and J. McCarthy

followed by refinement through to implementation, in which users goals are refined into task sequences which are then mapped to dialogues. Even some scenario-based design view of design [24]. The key features which unite these under the engineering approach are – Representation of the user or use context as a fixed set of well defined goals, tasks, or needs – Relatively abstract representations of typical users – Adherence or orientation to a task or scenario procedural methodology – An attempt to encapsulate usable design in terms of principles, guidelines or methods that can be re-produced by engineers who are not HCI specialists – A tendency to see usability as a property of the interface – An attempt to control the interaction with the user through design The design-as-engineering approach to HCI can be highly successful. Particularly where the domain of application is well regulated, relatively closed and the user’s role and goals in the system can be well defined and adequately captured in for example, a task analysis of tractable size. In these situations there are relatively uncontentious criteria as to what counts as an improved design [16]. But there are limits to this ap-proach and there are other disciplines which offer equally valuable perspectives on HCI. One new area of HCI research that offers challenges to the design-as-engineering approach, and illustrates the value of different perspectives is experience design.

3 The Challenge of Experience-Centred Design Experience is becoming an increasingly important problem for HCI research and over the last two or three years much has been written about not only what ’user experience’ is but also how to design for it. For some, the shift towards placing experience, ’felt-life’, and technology at the centre of our theorizing and design practice has led to an exploration of quite radically interdisciplinary literature (E.g. [9, 13, 20]). As an example, our own approach takes its inspiration from the pragmatist philosophy of John Dewey [11] and also the philosophy and literary theory of Mikhail Bakhtin [21]. Briefly our account can be characterised by three themes: 1. A holistic approach to experience wherein the intellectual, sensual and emotional stand as equal partners in experience 2. Continuous engagement and sense making wherein the self is the centre of experience, is already engaged in experience and brings to a situation a history of meanings and anticipated futures in order to complete the experience through acts of sense making 3. A relational or dialogical approach wherein self, object and setting are actively constructed as multiple centres of value with multiple perspectives and where an action, utterance or thing is designed and produced but can never be finalised since the experience of it is always completed in dialogue with those other centres of value.

User Experience and the Idea of Design in HCI

5

3.1 A Holistic Approach Most approaches to experience recognize the need to consider, not only the cognitive, intellectual and rational but also, the emotional and the sensual as important aspects of our experience. Norman [23] for example, identifies visceral, behavioural and reflective levels of design that connect with these aspects of experience. In our approach we argue against the reductive tendency to see these as independent (albeit interacting) levels that can be treated separately. The separation of form and content, behaviour and emotion, aesthetics and function, feeling and knowing is not helpful to an analysis of experience since the quality of experience emerges as the interplay between these things. 3.2 Continuous Engagement and Sense Making We argue that human experience is also constituted by continuous engagement with the world through acts of sense making at many levels. Continuous engagement involves an irreducible relationship between self and object, the concerned, feeling person acting with materials and tools. In our approach, everyday experience is primarily aesthetic since meaning emerges out of the dynamic relationship between sensual, emotional and intellectual levels of engagement at a particular time and place that bring about a particular quality of experience be it satisfying, enchanting, disappointing or frustrating. In a meaningful and satisfying experience each act relates coherently to the total action and is felt by the experiencer to have a unity or a wholeness that is fulfilling. This continuous engagement implies that how an individual makes sense of a situation, interaction, episode or artefact is as much about what the individual brings to the experience as it is about what the designer puts there. If we take for example the everyday experience of watching a movie, different people may take away different things from watching the same movie. Even the same person watching a movie for a second time may have different feelings about it and understand it differently. Two people’s experiences of the same movie will have some commonalities but there will also be differences because the two people bring different experiences to the movie. Not only different experiences of past films but also different experiences of the day they have just had. The quality of the felt experience of one person after a bad day in the office may be entirely different to that of another person after a relaxing day at home for example. Moreover, one person’s feeling that they should really be at home preparing for what is likely to be another demanding day tomorrow brings an expectation of a future experience into the present one. But how we experience the movie isn’t only about what we bring to it. The movie also brings something to us, it may temporarily dispel the troubles we bring or allow us see them in a different light. We can be totally engrossed by the narrative and spectacle, we can empathise with the characters. The movie also gives us a new experience, a new story that we can reflect on and recount to others. When we recount our own experiences to others, or other people’s experiences are recounted to us, the connection between the individual experience the social and the cultural is made. This connection in turn affects how we reflect on and interpret our experiences. It changes the sense we make of them. It allows us to see how other people might be expecting us to experience the movie that may or may not be how we actually experience it. Either way, we learn something about other people as well as ourselves,

6

P. Wright, M. Blythe, and J. McCarthy

the movie and the people that made it. These processes shape how we appropriate our experiences into our sense of self. They are what we refer to as dialogical. 3.3 A Dialogical View of Interaction Our movie example above highlights the dialogical character of experience, in which self, and others, technology, and setting are actively constructed as multiple centres of value, emotions and feelings and the experience is completed simultaneously by self and others, not determined solely by one or the other. A dialogical relation involves at least two centres of meaning or two consciousnesses. In a dialogical account, the meaning of an action, utterance, communication or artefact, is open because its interaction with the other makes the meaning something else. For example an utterance once uttered remains open to parody, sarcasm, agreement, disagreement, empathy, disgust, etc. Thus the other brings something to an interaction and responds to the act, utterance or artefact in a way that is informed by their own unique position in the world. Since each other is unique, the meaning of the act utterance or artefact is multi-perspectival, open to change and ultimately unfinalisable. But a dialogical understanding of meaning does not imply that a dialogue is a ‘dialogue of the deaf’ with neither side comprehending the terms of reference of the other. On the contrary because we can see what is uniquely our contribution and what is uniquely that of the other and what is shared between our selves and others, we can make sense of the other in relation to ourselves and vice versa. Empathy in the sense of being able to see something from one’s own perspective and that of another is an essential foundation for dialogue. In the movie example above, if someone tells us that a movie is great and that we’ll enjoy it, when we don’t, we learn something about the other person, about how they see us, about ourselves, about how we see them and about the movie. This is the essence of a dialogical relation based on centres of value. 3.4 Experience and the Design-as-Craft Perspective Our account of experience briefly described above stands as an example of the kinds of rich conceptions of experience that are emerging at this time. Such accounts offer serious challenges to design-as-engineering as the sole perspective on design in HCI. Recall that we characterized this approach as representing the user as a set of well defined tasks, an emphasis on methodology and an attempt to control the user’s interaction through properties and features of the design. If design-as-engineering is the only perspective on design we have, then inevitably, the richness of the concept of experience will be reduced to properties of the interface and issues of control and prediction. Consider as an example Garrett’s [14] idea of designing for experience taken from his recent book on web design: “The user experience development process is all about ensuring that no aspect of the user’s experience with your site happens without your conscious, explicit intent. This means taking into account every possibility of every action the user is likely to take and understanding the user’s expectations at every step of the way through that process. . . That neat, tidy experience actually results from a

User Experience and the Idea of Design in HCI

7

whole set of decisions—some small, some large—about how the site looks, how it behaves, and what it allows you to do.” (pp. 21–22) This kind of description of user experience and its relation to design is deeply rooted in a design-as-engineering perspective. Note its emphasis on a development process, the designer’s total control over the interaction and the emphasis on visual and behavioral properties of the interface. This approach to experience design does not fit well with the rich conception of experience outlined above. But there are different ways of looking at design that are more appropriate. For example, we have been working with digital jeweller Jayne Wallace [27] whose approach to designing for experience is based on a craft arts perspective. The design-as-craft approach is quite different to the design-asengineering perspective described earlier. It is more like what Fallman [12] describes as the pragmatist and artistic accounts of design. The design-as-craft perspective sees design as necessarily being an engagement with a particular world and particular materials, people and artifacts. The emphasis is on the process of making sense of a situation, where designers interpret the effects of their designs on the situation at hand and the effects of the situation at hand on their designs. It has been described as a reflective conversation with the materials of the design situation [26]. Pye [25] captures the difference between craft perspective and the engineering perspective with the terms ‘workmanship of risk’ and ‘workmanship of certainty’. In a craft practice each piece is unique and the outcome to some extent, uncertain. In an engineering practice, methodology and proceduralisation help to reduce risk in favour of certain and reproducible outcomes. Wallace [27] has created a collection of bespoke jewellery pieces that relate to the particular and personal significance of an individual client. The forms and digital function of the pieces refer to objects, memories, human connections and experiences, which are described as personally precious or meaningful to that client. For Wallace design is about engaging in dialogue with her participants and her materials. She works in a one-to-one relationship with her participants and engages them in dialogue around experiential moments shared through a set of ‘stimuli’ similar to the ‘Probe’ sets [15]. The probe stimuli, are not seen as requirements elicitation tools, nor are they simply sources of artistic inspiration removed from the client. Rather they are resources in a dialogue. The pieces she makes are bespoke and unique and create an environment where personally significant aspects of the person’s life can be referenced and paid attention to. The finished pieces are not the final statement in the dialogue. Rather she is concerned to understand how the pieces come to be appropriated into each person’s life and create new experiences [26]. For Wallace then, design-as-craft is about an emphasis on particular personhood and an empathetic stance in relation to both client and materials [27]. Elsewhere [29], we have also argued that designing for experience requires an empathetic relation between designer, materials, and user as separate centres of value. From a dialogical perspective, empathy is not simply about attempting to be another person in the sense of giving up one’s own unique position and experience in order to become, or fuse with the other. Rather it is about understanding another’s perspective and its sameness or difference to one’s own. A person must understand what it feels like to be in another’s position without giving up their own. This perspectivalism is necessary if

8

P. Wright, M. Blythe, and J. McCarthy

something new is to be created out of the dialogical engagement between different centres of value. The craft-based approach seems to be much more in tune with this philosophy. Viewing experience-centred design from the design-as-craft perspective seems to offer insights over and above the more familiar design-as-engineering perspective. However, our aim here is not to supplant one perspective on design with another. Our view is that having these co-existent perspectives enter into dialogue offers more potential for innovation in design and research. No one perspective alone is sufficient, HCI requires a radically interdisciplinary dialogue which crosses sciences and arts. In the case of Wallace’s own work, this dialogue centres around the issues of how to deal with the power and range of wireless transmitters in relation to the size and weight and appearance of the wearable jewellery, and issues of how to develop appropriate soft-ware for the delivery of digital content.

4 HCI Design as Radically Interdisciplinary Dialogue HCI has always been an interdisciplinary subject. In its early years the dialogue was between computer science and cognitive science and in particular, cognitive psychology. This was a natural and easy alliance since both disciplines shared a scientific worldview and a design-as-engineering perspective. Later the dominance of the cognitivist discourse was challenged by social scientists arguing against representationalist models of action in favour of practice theories. But here again the common philosophical foundation was a rationalist, scientific one. Only more recently, have these perspectives on HCI been complemented by perspectives from design disciplines. For example, Crampton Smith and Tabor [8] distinguish between the artist-designer and the engineerdesigner. Artist-designers have training and skills areas such as graphic design, filmmaking, product design and architecture. Crampton Smith and Tabor argue that too often when design-as-engineering dominates, the artist-designer is lim-ited to providing cosmetic look and feel after the ‘serious’ design work is done. They argue that this is a consequence of artificial distinctions between content and form and between function and aesthetics that occur when design-as-engineering is made central. Buchanan[7] also distinguishes between science and design in a number of interesting ways. Science is concerned with classification, understanding and explanation of the natural—of what exists. Its purpose is to observe, classify and model what exists objectively and without interfering or changing what they observe. The scientist’s position is outside of the system being studied. In contrast, design is concerned with the conception and planning of the artificial—of what does not yet exist. Its purpose is to supplement, re-interpret, change and transform what exists. The designer’s position is inside the system affecting and being affected by it. For Buchanan, while scientists often share an interest in the artificial and also need to engage in design thinking, they are also distinguished from designer by being master of a highly specialized body of subject matter knowledge and related methods such as is found in for example the disciplines of biology, physics, mathematics, psychology and so on. Design, however, has no specialized subject matter, it is, by definition, interdisciplinary—the problems addressed seldom fall within one disciplinary boundary.

User Experience and the Idea of Design in HCI

9

For Buchanan then, design thinking is more than just the application of science (although it involves this), because it involves solving ‘wicked’ problems. Wicked problems are problems that are ill-formulated, potentially unbounded, open to alternative formulations with no obvious means of choice or stopping rule and are particular to a situation, setting or context. A wicked problem is open to a potentially universal set of solutions yet the designer must come up with a particular and concrete solution out of the particular and concrete materials that constitute the problem situation. As an example to illustrate this, consider designing a solution to the problem of elderly and disabled people who can’t get out of their homes to buy groceries [3]. There is no subjectmatter independent solution to this problem and the subject matter of this problem could be medical, social, technological, or economic. any one of a number of subject-matters is potentially relevant to a concrete solution. Design thinking is concerned with how a concrete solution might be forged out of these abstract subject matters. Thus, while design practice can be characterised in terms of a philosophy or set of principles and methods, heuristics etc., design thinking is fundamentally concerned with the particular solution, and this for Buchanan, is the fundamental difference between scientific thinking and design thinking, there can be no “science of the particular”. A statistical analysis of the number of falls amongst the over 65s can, for example, produce information like the odds of a fall for a person in that age group, but it cannot tell you that your grandmother will break her leg on the way to the corner shop next week. For Buchanan and for Crampton Smith and Tabor, design is an integrative discipline in which engineering and art stand as equal partners in a dialogical process, separated by different subject matters, values and ways of looking, but united by a common problem and by design thinking. These are essential pre-requisites for innovation and creative understanding to occur, along with an empathetic relation between the individuals concerned. But the process of integration across disciplines is not always easy.

5 Resources for Interdisciplinary Dialogue Dialogue across disciplines will always be difficult. A fundamental problem is having sufficient knowledge of another’s language, practice, perspective and ways of looking to begin to engage empathetically in dialogue. A tendency in this situation is to reduce the other’s perspective to one’s own. That is to do a kind of translation process which can undermine the uniqueness of that perspective. Ultimately, we will argue that the way forward here is the kind of liberal arts education that we will discuss in the next section. But in addition dialogue can be fostered by a number of conceptual tools, philosophies and resources that help designers to see problems from another’s perspective. For Buchanan [7], one of the most important of these conceptual tools is the ‘doctrine of placements’, a kind of conceptual re-positioning of the design problem. He contrasted placements with the more scientific notion of classification thus: “Understanding the difference between a category and placement is essential if design thinking is to be regarded as more that a series of creative accidents. Categories have fixed meanings that are accepted within the framework of a theory or a philosophy, and serve as a basis for analysing what already exists. Placements have boundaries to shape and constrain meaning but are not

10

P. Wright, M. Blythe, and J. McCarthy

rigidly fixed and determinate. The boundary of a placement gives a context or orientation to thinking, but the application to a specific situation can generate a new perception of that situation and, hence, a new possibility to be tested. Therefore, placements are sources of new ideas and possibilities when applied to problems in concrete circumstances.” (pp. 10–11) By moving a concrete design problem out of its habitual placement and placing it in some other disciplinary context or orientation, an innovative solution can occur. For example, instead of seeing a building as a physical space—its habitual placement, it could be viewed as an emotional space or information space. In a similar way we have tried to encourage theoretical insight about interactive system design by reframing technology as experience [20] and reframing design as novelistic authorship [29]. The doctrine of placements also has similarities to the process of defamiliarisation that ethnographers have described [2] and also to Agre’s ideas on reversing centre and margin [1]. The doctrine of placements and these other techniques serve an important role in allowing disciplines with specialist subject matters to contribute to interdisciplinary dialogue. By using the doctrine of placements to generate a way of framing a problem and its solution, the designer establishes what Buchanan refers to as a ’principle of relevance’ for knowledge from the arts and sciences. Placements help determine how a particular discipline’s subject matter might be relevant to a design problem without reducing the problem to that discipline. We have also argued elsewhere for the use of open representations, rich scenarios, cultural probes and prototyping as tools in dialogical design [29], and Fallman [12] and others have argued a central role for sketching in dialogical design. But is important to note that it is not any inherent property of these tools that facilitates a dialogical approach. Rather it is the way they are used in design in practice. So for example, Gaver [15] has argued that cultural probes when appropriated into a designas-engineering perspective resemble a closed requirements elicitation technique rather than a stimulus to dialogue favoured by Gaver and typical of Wallace’s use described earlier. When used in a dialogical way they support innovative design by helping to open up spaces and new ways of looking at the problem and solution in ways very similar to Buchanan’s doctrine of placements. Brown and Duguid [6], introduce the term genre (more commonly associated with literary theory and cultural and media studies) as a way of characterising how an object’s placement in an unspoken context determines in part, how the object will be understood. Knowing for example, that you are reading a detective novel generates certain expectations and certain habitual ways of understanding what is written, pictured, or said. Many design disciplines have toolkits of resources and styles to encour-age this kind of implicit processes of framing. But Brown and Duguid argue that unlike classification systems of a more scientific provenance, genres offer more per-meable boundaries whose crossing stimulates innovation and move a discipline on. Crossing an unseen boundary brings the boundary to light and leads to a questioning that can give rise to a boundary re-definition. Good artists push the boundaries of a genre which leads to the response, “is this art?” and thereby define a tradition and a new way of thinking. Brown and Duguid, use the example of Jazz to show how innovation emerges at boundary crossings:

User Experience and the Idea of Design in HCI

11

“In jazz, for instance, Miles Davies claimed that Wynton Marsalis was too respectful of old forms to go anywhere new. Other musicians, however criticized Davis for moving too far beyond the conventional forms to be understood. Almost every time that he moved across musical boundaries, Davis was charged with incoherence . . . Before long, however, it became apparent that he had built a new audience for his work, and a new frontier for musicians—often led by Davis himself—to cross.” (p.142) In addition to showing how pushing genre boundaries stimulates innovation and progress, Brown and Duguid’s example also describes a process of critical reflective practice [1, 26], in which practitioner’s continually question assumptions and ways of interpreting. This kind of critical reflection is particularly well facilitated when arts and sciences meet in interdisciplinary dialogue. At these boundaries radically different perspectives on the same design problem offer significant surpluses for forging new frontiers. For instance Bolter and Gramola [4], who take a digital arts perspective as their starting point, critically question a number of assumptions that are fundamental to a the usability engineering perspective on interaction design. For example, they bring to light assumptions concerning the utility of transparency and invisibility as design goals and note the ways in which such principles can stifle innovation and research. In place of the metaphor of window they offer a metaphor of mirror and in place of transparency they discuss the value of reflectivity, and argue that in reality, interaction is an oscillation between moments of transparency and reflection. But Bolter and Gramola go further than this, and like many from an arts perspective use their critical reflective practice to challenge assumptions about the role of technology in society and culture.

6 Towards a Liberal Arts of HCI HCI researchers having a long history of interdisciplinary dialogue, but despite the best of intentions and conceptual tools, it can sometimes seem like a ‘dialogue of the deaf’. At times this is a result of participants not having a sufficiently empathetic stance towards each other, preferring to establish one design approach (e.g., designas-engineering, design-as-art) as the dominant voice and translate the other’s terms of reference into that voice. At other times it is plainly and simply the fact that the participants lack sufficient common ground with each other even to begin to identify surplus and relate their own expertise to that of others. As Kapor [18] argues, many people in HCI lack the technical grounding to be an effective participant in the dialogue. Programmers quickly lose respect for people who do not understand the technical limitations, and artists feel artificially fettered by technical limitations and lack respect for programmers who fail to grasp the importance of conceptual work. From our own experience, we observe that artistic and engineering skills seldom reside in the same person, largely because there is too much subject matter knowledge and too much practical experience for most people trained at undergraduate level in one discipline to be ‘converted’ at postgraduate level to expertise in another. However, following Buchanan’s consideration of design as a liberal art, there is more that could be done in higher education to provide the common ground necessary for radically interdisciplinary dialogue. A broader education in HCI as a design discipline would integrate skill sets

12

P. Wright, M. Blythe, and J. McCarthy

and subject matters from the parent disciplines. Computer science, psychology, sociology, visual, literary and performing arts, TV film and thea-tre would all become applied subjects matters in a new liberal arts of HCI. Such an education would embrace not only an understanding of the skills of the software programmer, electronics engineer and network developer, but also the techniques of the artist-designer, including graphic design, sketching, the use of 3-D visualization tools, and the use of multimedia editing tools for scenario development. In addition, qualitative and quantitative research methods would provide a basis for understanding the process of empirical research and evaluation. There would be a strong practical, problem-based and team based ethos to the mode of study. But in addition such an education could offer foundation courses in science, technology and the design disciplines as well as the philosophical foundations of interaction design. In particular, the critical, reflective thinking of the humanities curriculum would have a valuable role to play in a critical technical practice of HCI design.

7 Conclusions In this paper we have argued that since HCI has grown and developed to take more complex challenges beyond usability, there needs to be more emphasis on radical interdisciplinary research which crosses sciences and arts, we have argued that inter-disciplinary dialogue is essential to ‘wicked problems’ like designing for experience, and we have outlined some of the sensibilities, tools and training that may be required to make this possible. If nothing else, we are arguing that HCI might be best under-stood as a design discipline that integrates radically interdisciplinary research and practice. To us, this has a liberating feel to it. Shifting the focus to design and explor-ing what the term actually means in different subject matter disciplines has provided a positive energy to our research. This shift is also not without precedent. Papers at the ACM CHI conference (e.g. [12]) are exploring what a design-oriented HCI might mean and in the UK, research councils are beginning to seek to support collaborations across arts and sciences. But framing HCI as a design discipline is not without its risks. The art and design education sector was severely criticized throughout the last decade. The 1995/6 HESA first destination study revealed that those students who studied creative Arts and Design were most likely to be unemployed (12%) one year after graduation. This crisis was relieved by the publication of a document called “The Creative Industries” by the Department of Culture, Media and Sport in 1998 [10]. This document expanded previous classifications of the cultural industries to include commercial arts such as advertising and interactive and leisure software. This new aggregate of sectors produced some startling figures: the creative industries were growing at twice the rate of the economy as a whole, they contributed more than four percent of the domestic economy, they employed around one and a half million people and generated over sixty billion pounds a year. Although the proportion of art and design graduates who went on to success in the creative industries might be small, their contribution to GDP, so the argument went, was disproportionately high. The design education sector then underwent something of a transformation. From justifying its existence in terms of how well it developed communication skills or teamwork it became a glittering example of the utility of higher education to the general economy.

User Experience and the Idea of Design in HCI

13

HCI has long found gainful employment for ethnographers and ethnomethodologists who are probably as surprised as anyone that their sociological training should turn out to be useful to design. As HCI’s scope expands still further, arts and humanities graduates may yet discover that their studies were not, as they probably thought, without immediate utility. Indeed HCI may yet become the last bastion of a liberal arts education. Subject disciplines like sociology, psychology and english literature may offer the best grounding in understanding the human in human computer interaction, and craft disciplines together with engineering science and visual and performance arts may offer the best grounding in designing and building interactive environments, products and services.

Acknowledgements This paper was developed from the keynote address given by the first author at DSVIS 2005. Many thanks to the EPSRC for support in the form of the Leonardo (GR/T21042/01) and Affective Communication networks (GR/T21264/01) which have provided the opportunity of real radical interdisciplinary explorations and for support in the form of a visiting fellowship (GR/S18779/01) and a responsive mode grant (GR/S70326/01) that have allowed us to develop our theoretical and methodo-logical framework for experience-centred design.

References 1. P. Agre. Computation and Human Experience. Cambridge University Press, 1997. 2. G. Bell, M. Blythe, and P. Sengers. Making by making strange: Defamiliarisation and the design of domestic technologies. Transactions on Computer-Human Interaction Special Issue on HCI and Social Issues, (In press). 3. M. Blythe and A.F. Monk. Net neighbours: Adapting hci methods to cross the digital divide. Interacting with Computers, 17:35–56, 2005. 4. J.D. Bolter and D. Gramola. Windows and Mirrors: Interaction Design, Digital Art, and the Myth of Transparency. MIT Press, 2003. 5. J.D. Bolter and R. Grusin. Remediation: Understanding New Media. MIT Press, 2001. 6. J.S. Brown and P. Duguid. Keeping it simple. In T. Winograd, editor, Bringing Design to Software, pages 129–145. ACM Press, 1996. 7. R. Buchanan. Wicked problems in design thinking. In R. Buchanan and V. Margolin, editors, The Idea of Design, pages 3–20. MIT Press, 1995. 8. G. Crampton Smith and P. Tabor. The role of the artist designer. In T. Winograd, editor, Bringing Design to Software, pages 37–57. ACM Press, 1996. 9. Marc Davis. Theoretical foundations for experiential systems design. In ETP ’03: Proceedings of the 2003 ACM SIGMM Workshop on Experiential Telepresence, pages 45–52. ACM Press, 2003. 10. Department of Culture, Media and Sport. Creative industries mapping document, 1998. 11. J. Dewey. Art as Experience. Pedigree, 1934. 12. D. Fallman. Design-oriented human-computer interaction. In Proceedings of CHI 2003, pages 225–232. ACM Press, 2003. 13. J. Forlizzi and S.Ford. The building blocks of experience: An early framework for interaction designers. In Proceedings of Designing Interactive Systems (DIS 2000), pages 419–423. ACM Press, 2000.

14

P. Wright, M. Blythe, and J. McCarthy

14. J.J. Garrett. The Elements of User Experience: User-Centred Design for the Web. New Riders Publishers, 2002. 15. B. Gaver, A. Boucher, S. Pennington, and B. Walker. Cultural probes and the value of uncertainty. Interactions, XI, September–October 2004. 16. W.D. Gray, B.E. John, and M.E. Atwood. The pr´ecis of Project Ernestine or an overview of a validation of GOMS. In P. Bauersfeld, J. Bennet, and G. Lynch, editors, Striking a Balance: Proceedings of the CHI’92 =Conference on Human Factors in Computing Systems, pages 307–312. ACM Press, 1992. 17. M.D. Harrison and P. Barnard. Integrating cognitive and system models in human-computer interaction. In A. Sutcliffe and L. Macaulay, editors, People and computers V, pages 87–104. Cambridge University Press, 1989. 18. M. Kapor. A software design manifesto. In T. Winograd, editor, Bringing Design to Software, pages 1–9. ACM Press, 1996. 19. K.Y. Lim and J. Long. The MUSE Method for Usability Engineering. Cambridge University Press, 1994. 20. J. McCarthy and P. Wright. Technology as Experience. MIT Press, 2004. 21. G.S. Morson and C. Emerson. Mikhael Bakhtin: Creation of a Prosaics. Stanford University Press, 1990. 22. J. Nielsen. Usability Engineering. Academic Press, 1992. 23. D.A. Norman and S. Draper. User Centered System Design: New perspectives on HumanComputer Interaction. Lawrence Erlbaum Associates, 1986. 24. S. Pocock, M.D. Harrison, P. Wright, and P. Johnson. Thea: A technique for human error assessment early in design. In M. Hirose, editor, Proceedings of INTERACT ’01. IFIP TC.13 International Conference on Human-Computer Interaction, 2001. 25. D. Pye. The Nature and Art of Workmanship. Herbert Press, 1968. 26. D. Schon. The Reflective Practitioner. Basic Books, 1983. 27. J. Wallace and M. Press. All this useless beauty: Craft practice in design for a digital age. The Design Journal, 7.2, 2004. 28. J. Whiteside, J. Bennett, and K. Holtzblatt. Usability engineering: Our experience and evolution. In M. Helander, editor, Handbook of Human-Computer Interaction, pages 791–817. Elsevier Science Publishers, 1988. 29. P.C. Wright and J. McCarthy. The value of the novel in understanding work for design. In A. Pirhonen, H. Isomki, C. Roast, and P. Saariluoma, editors, Future Interaction Design, pages 9–30. Springer, 2005.

Formalising Performative Interaction Alan Dix1 , Jennifer G. Sheridan1 , Stuart Reeves2 , Steve Benford2 , and Claire O’Malley2 1

Computing Department, InfoLab 21, South Drive, Lancaster University, Lancaster LA1 4WA [email protected], [email protected] 2 School of Computer Science and IT, Nottingham University, Jubilee Campus, Wollaton Road, Nottingham NG8 1BB {str, sdb}@cs.nott.ac.uk, [email protected]

Abstract. In this paper we attempt to formalise some of the basic attributes of performative interaction against a background of sociological analysis in order to better understand how computer interfaces may support performance. We show how this generic formalisation can be used in the deconstruction, analysis and understanding of performative action and more broadly in live performance. Two examples of this form of analysis are shown: the installation piece Deus Oculi; and Stelarc’s Ping Body performance piece. The analysis of these pieces renders visible the varied (re)mappings of the causal nature of interaction, direct and indirect effects, and how these are perceived and exploited by the various members of performance social groupings. Our aim, then, is to provide a model that can be used to explore the relationships that exist in performative activities across domains.

1 Introduction Computing technology has come to be used increasingly in many forms of performance in order to augment and extend (human) agents’ ability [1] for performative action. Although this may be seen as part of a wider trend in art to engage with sciences [10], computer technology in particular presents the artist with ways of breaking some essential physical restrictions (such as location, e.g., mobile phones), and obfuscating causal relations between actions. The very nature of this use of technology in art also breaks from the original emphasis in human-computer interaction (HCI) of efficiency, and as such we have few means for investigating these breaks. Our interest, then, is in defining a formal method for describing performative actions.

2 What Do We Mean by Performance? While there are many, often conflicting, definitions of live performance, it is necessary that we point out that it is not our intent to create a new definition. However, to improve the clarity of this paper, we must discuss what we include in our definition of live S.W. Gilroy and M.D. Harrison (Eds.): DSVIS 2005, LNCS 3941, pp. 15–25, 2006. c Springer-Verlag Berlin Heidelberg 2006 

16

A. Dix et al.

performance. The complex essense of performance may be viewed in many ways. For example, live performance may be seen as “tripartite interaction” [8], i.e., synchronous, real-time interaction that occurs between a number of agents (such as performers, participants in the performance, and “observers” of the performance). Some models, on the other hand, only draw a distinction between a performer and a spectator and their transitioning relationship as mediated by the interface [5]. For the purposes of this paper, our simplified view on the ‘component’ parts of performance follows a tripartite model, introducing the key notion of ‘framings’ (discussed shortly): – Performers construct the ‘frame’ of the performance, and perform to an audience with a particular (typically premeditated) intent. – Participants interpret the ‘framing’ of the performance, and are engaged in the intended performance through some witting or unwitting activity. – Bystanders also interpret this performance framing and although their presence is integral to the performance, their performative actions are not. They may also interpret a framing either wittingly or unwittingly. Note that we consider the performative actions themselves (i.e., those actions conducted by participants and performers) to be very much part of the performance, not just the effects that are produced as a result of them (as discussed in [6]). Other definitions deepen this action-to-effect mapping, including, for example, gestures around the interface [5], however this is beyond the scope of this paper. The concept of a performance framing here is central to understanding the background sociological concepts inside which our formal method is placed. The “frame” is a term developed from sociologist Erving Goffman’s work [3] broadly meaning a constructed context within the limits of which individual human agency and social interaction takes place. For example, a theatrical frame [3][pp. 124–155] involves the construction of a higher-level frame on top of a “primary framework,” i.e., the reality in which the fantasy takes place. In this example, actors assume a character, audiences suspend disbelief and events have their meaning transformed (e.g., compare the use of a mobile phone in public with its use in a theatre). We note that although all social interaction may be seen from a dramaturgical perspective, meaning everyday social interaction becomes performance in some sense [2], we deliberately narrow our analysis to cover more stabilised ‘established’ forms of performance. What this means, then, is defining performance framings as an activity done within the intended frame “by an individual or group” who have some established knowledge about the frame, and are “in the presence of and for another individual or group” [7]. Also pertinent to this model is ‘intent’; participants and bystanders may perceive the performance differently than the performer intended. However, in this paper we do not focus on intention since intention rests with the makers of the live performance (orchestrators, designers, technicians, etc.). We believe that intention is imperative to the understanding of HCI in live performance and yet this issue adds a layer of complexity that deserves its own careful analysis. Instead, then, we focus on the nature of observation and participation, and how technology changes bystander perception so that we may use this knowledge as an entry point for understanding the application of interactivity in this domain.

Formalising Performative Interaction

17

3 Overview We begin with a generic model of activity and perception. This reflects the fact that much of performance is really about social action. We then go on to look at the beliefs (the reality of some being or phenomenon) that participants have about their actions and the effects of those actions. Together these enable us to produce (weak) definitions of witting and unwitting performative action based on beliefs about the effects of actions and the extent of the performative frame (that the being or phenomenon is part of the performance).

4 Actions The key objects in performance are represented by two sets: Agent The set of all (human, animal, machine, etc.) agents involved in the performance. P henomenon The set of all world phenomena that can be affected or sensed by agents. This includes real world physical things like cups, balls, etc., visual and aural things like the sound at a location of a room, and virtual things like the appearance of a web page. However, the directly perceivable phenomena are ultimately real world rather than virtual (e.g., the appearance of the screen on which the web page is shown). At any moment and situation an agent has a set of actions available: available actions : Agent → set(Action) This and the other relations below will change depending on the current context and time. However to avoid repeating ‘Context × T ime’ as parameters for every function we will take these as read. If an agent actually performs an action at a particular moment we write this as ‘A[a]’. Of course, this is only possible if the action is available: A[a] ⇒ a ∈ available actions(A) These actions act on phenomena: ef f ect : Action → set(P henomenon) However, in general there are also indirect influences due to physical or digital causal effects, for example the sound of played music may be picked up by microphones that create lighting effects, or dropping a glass may make a crash! causal link : P henomenon → set(P henomenon)

18

A. Dix et al.

Note that this causal link will depend on the behaviour of technological and mechanical devices. These causal links give rise to a set of phenomena that are indirectly influenced by a person’s actions and hence may influence others: indirect ef f ect : Action → set(P henomenon) indirect ef f ect (a) = causal link(ef f ect(a)) ∪ ef f ect(a) We write A[a]  p to mean that agent A performs action a that potentially indirectly affects phenomena p: A[a]  p ⇐⇒ A[a] ∧ p ∈ indirect ef f ect(a)

5 Perception Similarly each agent has a set of phenomena that can be perceived at any moment: perceivable : Agent → set(P henomenon) As with the case of actions, the causal links in the world mean that an agent may indirectly perceive phenomena not otherwise directly observable. indirectly perceivable

:

Action → set(P henomenon)

indirectly perceivable (a) = causal link(perceivable(A)) ∪ perceivable(A) An agent may directly perceive the effects of another’s actions if these sets interact. We write p A to mean that agent A may perceive phenomena p: p A ⇐⇒ p ∈ indirectly perceivable(a)

6 Influences If the indirect effect of one agent intersects with the perceivable phenomena of another, then the actions of one may influence the other. We will write A  B if agent A potentially influences agent B: A  B ⇐⇒ ∃a, p s.t. A[a]  p B Note that this is just representing that some action may give rise to a perceived effect. It does not necessarily mean that agent A necessarily performs the particular actions that may be indirectly perceived by agent B, nor that agent B actually notices the phenomena affected by agent A, nor even if the effects are perceived, that agent B realises that agent A is their cause. Figure 1 illustrates some combinations of influence and perception. We can consider a stronger conceptualisation of interaction by recognising that they can occur in two forms: actions by agent A that give rise to an effect perceivable by agent B; and actions that give rise to an effect that is actually noticed by agent B. This, however, does not distinguish effects on B that may be unconscious or not the focus of attention (e.g., peripheral awareness), or ones that may not be perceived as being in any way explicitly caused (e.g., small changes in temperature).

Formalising Performative Interaction

19

Phenomena directly perceived by B

Phenomena directly influenced by A

B

A

Phenomena indirectly influenced by A

Phenomena indirectly perceived by B

Fig. 1. Spheres of influence and perception

7 Knowledge, Frames and Performance A key difference between someone who acts and is observed or perceived in some way by another and one who actively performs for another is one of knowledge. To perform for another one must know that the other person may perceive the effects of one’s actions. We will write ‘βA {X}’ to represent the current beliefs of A about the world (read ‘βA {X}’ as ’A believes X’). If we perform for another then we must both act and believe that the other person will perceive our actions: A perf orms to B ⇒ A[a] ∧ βA {A[a]  B} This would include everything from speaking to someone to hitting a person on the head, but performances in the artistic sense require more. The participating agents have, in some way, to understand that their actions and effects are part of the performance. This is the role of the frame that was discussed earlier. Giving your friend a toffee during a play is not part of the performance, but an actor standing on stage and throwing the toffee probably is. Each agent has different levels of experience in interpreting and making sense of framings. In this way performance framings are active and dynamic since they may be perceived differently by different people (e.g., a child and an adult). In the traditional theatrical context, it is commonly understood (although often also deliberately broken) as the time between the curtain rising and falling and the space on stage [3][p. 139]. In street theatre the physical and temporal boundaries are not so well defined. What is important is what people believe to be the frame. As a simplification we will model the frame as a collection of phenomena (e.g., the things that happen on stage). Using this we can have a stronger definition of performance: A perf orms to B ⇐⇒ A[a] ∧ ∃p ∈ P henomenon s.t. βA {A[a]  p} ∧ βA {p ∈ F rame} ∧ βA {p B} ∧ βA {βB {p ∈ F rame}}

20

A. Dix et al.

That is, we must believe that our actions influence another through some phenomena, that these phenomena are part of the frame, and that the other person also believes the phenomena are part of the frame. We can contrast this with the ‘unwitting performer’ who acts without knowledge that their actions constitute part of a performance: A unwittingly perf orms to B ⇐⇒ ∃p s.t. A[a]  p B ∧ ¬(βA {A[a]  p} ∧ βA {p ∈ F rame}) ∧ βB {p ∈ F rame} Note that there are two ways in which the unwitting performer may fail to understand that their actions are part of a performance. They may not know of the existence or bounds of the frame: ¬βA {p ∈ F rame} or may not know of the effects of their actions: ¬βA {A[a]  p} The latter may occur because the unwitting performer does not understand the causal connections between directly influenced and indirectly influenced phenomena.

8 The Effect of Technology Adding technological interfaces will change the available phenomena that can be acted upon (e.g., knobs, dials) or perceived (e.g., screens, sound from speakers). Furthermore, technological interfaces can affect the existing phenomena and create new causal connections. For example, adding a microphone and speaker will make a causal connection between the sound near the microphone and the sound near the speaker. Technological manipulations may even remove or weaken existing causal connections. For example, bright lights or loud sounds may block other stimuli. Whilst physical linkages are readily visible, technological ones may be invisible. This invisibility means that those implicated in a performance may not know whether their actions will affect particular phenomena and hence, as noted above, they as participants or bystanders may unwittingly place themselves within the performance frame. The act of discovering or understanding these connections effectively shifts one’s perception of the boundaries of the performance frame. This thus creates changes in the way in which those involved may view their roles in a performance and so also affect their behaviour. This is exactly what occurs in Deus Oculi, which we shall now examine.

9 Analysis of Deus Oculi Deus Oculi was an interactive installation exhibited at the Chelsea International Crafts Fair in September 1999. This was a large renaissance-style painted scene featuring two figures whose faces were painted on small doors. Behind the doors were small CCTV

Formalising Performative Interaction

21

B looks at screen inside small door

A looks at painting on hand−held mirror Frame

A

B

Both are aware that mirror and screen are within frame

... but is unaware of causal link between mirror and screen

Fig. 2. Deus Oculi Table 1. Tableaux of beliefs during Deus Oculi actual situation 1. A and B come to the ex- mirror ∈ F rame hibit screen ∈ F rame mirror  screen 2. A looks at mirror, B looks mirror  A at screen screen  B A  mirror 3. B sees A in screen A  mirror  screen  B 4. B infers relationships 5. A looks at mirror, B looks mirror  B B  at screen mirror mirror  screen screen  B

βA (A’s beliefs) mirror ∈ F rame screen ∈ F rame + knows B’s beliefs mirror  A screen  B A  mirror

screen ∈ F rame

βB (B’s beliefs) mirror ∈ F rame screen ∈ F rame + knows A’s beliefs mirror  A screen  B A  mirror mirror  screen B  mirror  screen  A + knows A’s beliefs

screens that were linked directly to two hand-held mirrors situated on either side of the painting. When a visitor, assuming the role of a performer, picked a mirror and looked into it, an image of their face was captured on a hidden video camera and then displayed on one of the screens in the painting. As a result, performers could not see the effects of their own manipulations resulting in highly engaging collaborative exchanges as the spectators pointed them out to the performers and/or bystanders [4]. Figure 2 shows the phenomena and frame in Deus Oculi. Two visitors, Alison (A) and Brian (B) visit the gallery and view the exhibit. The tableaux in Table 1 shows the various stages that they go through. Initially (step 1) they both realise that the mirror and screen are part of the frame. However, they are unaware that there is a causal link between the two. At step 2, Alison looks in at the mirror and Brian looks at the screen however, the mirror and screen are linked by the hidden camera hence at step 3 Brian sees Alison’s face. At step 3 Alison is an unwitting participant. Looking back at our definition, the key phenomenon (‘p’ in the formula) is the screen. Brian believes the screen is part of the

22

A. Dix et al.

frame. Alison’s action of looking at the mirror indirectly affects the screen, however Alison does not know that she is having this effect because she is ignorant of the causal link. ⎫ A[a]  screen B∧ ⎬ ¬βA {A[a]  screen} ⇐⇒ A unwittingly perf orms to B ⎭ ∧βB {screen ∈ F rame} At this point however, Brian realises that there is some connection between mirror and screen and this is reflected in his changed beliefs at step 4. Brian does not share his new knowledge with Alison but knows that she does believe that the screen is part of the frame of the exhibit. Now they swap positions. Brian looks in the mirror and makes silly faces whilst Alison looks at the screen. Similar to step 2 and 3, the hidden camera means that Brian’s faces are visible to Alison. However, unlike Alison at step 3, Brian is aware of this link. As he knows about the link it is not hard to work out that if he looks in the mirror Alison will see him. βB {A[a]  mirror} ∧ βB {mirror  screen} ⇒ βB {A[a]  screen} Of course, even with perfect knowledge some technical interfaces may be such that with bounded rationality we are not able to work out all such relationships, or they may only become apparent after a long time. However, in this case Brian does know that his actions affect the screen that Alison is seeing and that both he and she regard this as part of the exhibit’s frame. This makes him a witting participant: ⎫ βB {B[look in mirror]  screen} ⎪ ⎪ ⎬ ∧βB {screen ∈ F rame} ⇒ B perf orms to A ∧βB {screen A} ⎪ ⎪ ⎭ ∧βB {βA {screen ∈ F rame}} Brian’s actions, whilst not specifically scripted into the exhibit are expected. In acquiring knowledge about the performance frame Brian transitions from an unwitting to witting participant which gives him the ability to perform to an audience. Brian’s performative actions with and around the interface are tethered in a relatively linear fashion to the resulting effects (e.g., his face on the screen). This causal mapping enables swift (and humorous) transitions from unwitting to witting participant. Next we shall examine how these causal mappings themselves have greater depth, using Stelarc’s Ping Body as an example.

10 Analysis of Ping Body Ping Body, in contrast to Deus Oculi, is explicitly framed as a performance, rather than as an installation that encourages performative action. Stelarc performs his work, Ping Body, to demonstrate not how the body can be actuated by other bodies in other places,

Formalising Performative Interaction

23

but how the body can be actuated by internet activity itself thus producing an inversion of the usual interface of the body to the internet. Not only is Stelarc’s performance an event, but the performative interaction is an event itself [6]. A fascinating concept in this piece, then, is how this inversion exposes the complex and obscure causal mappings that constitute routine Internet activity, (i.e., routine activity as would be experienced for the usual interface of the body to the Internet). In one performance Stelarc describes: “We also used the ping Internet protocol in a performance where the Body was moving through internet data. During the performance I would ping 40 global sites. The reverberating signals were measured in milliseconds mapped to the body muscles in a very crude way, but what was effectively happening was that the body was becoming a barometer of Internet activity. The Body moved according to the internet activity from that global site.” [9] Figure 3 illustrates the performative activity occurring in this performance. Firstly we can decompose this in a similar way to Deus Oculi, drawing out the mechanics of unwitting and witting performance (unlike Deus Oculi, however, the participants in this case never know about their participation in the performance, and do not necessarily make the transition within the time span of the performance): ⎫ R[a]  N ∧ ⎪ ⎪ ⎪ ⎪ N [a]  B∧ ⎪ ⎪ ⎪ ⎪ B[a] A∧ ⎪ ⎪ ⎪ ⎪ {R[a]  B}∧ ¬β ⎪ ⎧ R ⎫ ⎪ ⎪ ⎪ ⎨ {R ∈ F rame}∧ ⎬ ⎬ βA {¬βR {R[a]  B}∧ ∧ ⇒ R unwittingly perf orms to A ⎩ ⎭ ⎪ ⎪ ⎪ ⎪ ⎧ {N [a]  B} ⎫ ⎪ ⎪ {R ∈ F rame}∧ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎨ ⎬ ⎪ {¬βR {R[a]  ⎪ ∧ ⎪ βB ⎪ ⎪ B} ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎭ ⎩ ⎭ ∧{N [a]  B} The causal links between these unwitting participants (R) and Stelarc’s (B) body movements are aggregated, which becomes part of this process of inverting the interface. Figure 4 illustrates several examples of different sets of causal linkages. We might think of Deus Oculi as exploiting a relatively linear causal link, i.e., A  mirror  screen B, Figure 4(a). Fig. 4(b), on the other hand, illustrates a more obfuscated, indirect chain of causal links, e.g., A  p1  p2  p3  p4 B. We can even imagine a tree of indirect causal links, Fig. 4(c). For Ping Body, however, these causal links are not only highly obfuscated causal links, but also aggregates of causal links such that (put crudely): R1 [a] ∪ R2 [b] ∪ R3 [c] ∪ . . . Rn [z]  p B In short, then, we are able to unpack some of the elementary details that lie behind these experiences by assuming a simple formalisation of the various interactions that take place in both examples, Deus Oculi and Ping Body.

24

A. Dix et al. The body moves when stimulated

Local audience observes movement Frame

H B

A

N People creating network traffic unaware of causal link between their actions and body movement

Performer and local audience aware that remote audience exists

R Fig. 3. Ping Body

A

B

B

A

(a) Linear

(b) Indirect

A

R1 R2 B

(c) Many indirect

N

B (H)

R3

Rn

(d) Aggregated

Fig. 4. An analysis of the causal linkages

11 Conclusion In this paper we have seen how performative acts may be formalised in order to understand how interaction with interfaces impacts performers, participants and bystanders, and how sociological aspects in turn impact this interaction itself. Some salient features of our formalisation are

Formalising Performative Interaction

– – – – –

25

The direct and indirect effects of actions performed by a (human) agent Direct and indirect perception of those effects Influences as the combination of indirect effects and indirect perception Causal links that bind these together and their varyingly complex structures Wittingness and its relationship to the frame of performance

Through our two examples, we demonstrated how this model may be applied in order to reveal the detail of interactions that may occur by virtue of the interface’s configuration within a given setting. The main application for such decomposition would be to direct the design of interfaces in order to craft certain experiences both for the performer of that system and, as we have also considered here, the resulting experience for participants and bystanders. Future work will be concerned with analysing further examples of live performance as well as applying this model as a design tool, in particular how it may be exploited and subverted in implementations of interfaces designed for performance.

References 1. J Clarke. pros + thesis. In Adrian Heathfield, editor, Live: Art and Performance, pages 208–209. Tate, London, 2004. 2. Erving Goffman. The Presentation of the Self in Everyday Life. Doubleday, New York, 1959. 3. Erving Goffman. Frame Analysis: An Essay on the Organization of Experience. Harper & Row, 1974. 4. Christian Heath and Jon Hindmarsh. Analysing interaction: Video, ethnography and situated conduct. In T. May, editor, Qualitative Research in Practice, pages 99–121. Sage, 2002. 5. Stuart Reeves, Steve Benford, Claire O’Malley, and Mike Fraser. Designing the spectator experience. In Proceedings of SIGCHI Conference on Human Factors in Computing Systems (CHI), pages 741–750, April 2005. 6. D Saltz. The art of interaction: Interactivity, performativity and computers. Journal of Aesthetics and Art Criticism, 55(2):117–127, 1997. 7. R Schechner. Performance Theory. Routledge, London, 1977. 8. Jennifer Sheridan, Alan Dix, Simon Lock, and Alice Bayliss. Understanding interaction in ubiquitous guerrilla performances in playful arenas. In Proceedings of British HCI Conference, September 2004. 9. Stelarc. The body. Switch Journal (online), 2004. Verified 4/3/05. 10. Stephen Wilson. Information Arts: Intersections of art, science and technology. The MIT Press, 2002.

DiCoT: A Methodology for Applying Distributed Cognition to the Design of Teamworking Systems Ann Blandford and Dominic Furniss UCL Interaction Centre, University College London, Remax House, 31-32 Alfred Place, WC1E 7DP, UK {A.Blandford, D.Furniss}@cs.ucl.ac.uk

Abstract. Distributed Cognition is growing in popularity as a way of reasoning about group working and the design of artefacts within work systems. DiCoT (Distributed Cognition for Teamwork) is a methodology and representational system we are developing to support distributed cognition analysis of small team working. It draws on ideas from Contextual Design, but re-orients them towards the principles that are central to Distributed Cognition. When used to reason about possible changes to the design of a system, it also draws on Claims Analysis to reason about the likely effects of changes from a Distributed Cognition perspective. The approach has been developed and tested within a large, busy ambulance control centre. It supports reasoning about both existing system design and possible future designs.

1 Introduction Most interactive systems do not consist of a single user with a single desktop computer. Yet most of the established methods for reasoning about the design and use of systems are still best suited for such single-user–single-device systems. Mobile, pervasive and distributed systems bring new sets of design challenges, and correspondingly new approaches are needed for reasoning about such systems. Distributed Cognition (DC) is an approach to reasoning about the interaction of multiple people and artefacts who share a common purpose. Within the system of people and artefacts, it considers the coordination of knowledge and goals, and the flow of information. It has been widely promoted as a method for reasoning about the design of distributed systems involving multiple people and interactive devices. However, despite the relevance of DC to HCI, it has lacked visibility in the HCI community [12,13] and, to the best of our knowledge, there has been no concerted attempt to develop or test a methodology for applying the ideas of DC in a structured way for distributed work. In this paper, we present DiCoT (Distributed Cognition for Teamwork), a structured approach to analysing a work system in terms of the central ideas of Distributed Cognition as presented in the DC literature. 1.1 The Approach The approach taken was to start with a systematic study of the DC literature. From this literature, a set of core principles for DC were derived and classified according to S.W. Gilroy and M.D. Harrison (Eds.): DSVIS 2005, LNCS 3941, pp. 26 – 38, 2006. © Springer-Verlag Berlin Heidelberg 2006

DiCoT: A Methodology for Applying Distributed Cognition

27

primary theme. Five themes emerged; for the three main themes, appropriate representations were developed to support reasoning about that aspect of the distributed system. For this, we drew extensively on the early stages of Contextual Design [2]. These representations and the associated reasoning process form the core of DiCoT. The representations were developed and tested by applying them to a case study involving team working in ambulance control. Two visits, each of half a day, were made to the case study organisation (London Ambulance Service, LAS); each involved both focused observation work and Contextual Inquiry interviews [2]. Data was gathered from call takers (who are seated in a group separately from the main control area), and from representatives of the three main control roles: telephone dispatchers, radio operators and allocators (who lead the teams and are responsible for planning, co-ordination and decision making). Data gathered during these visits was represented and analysed using DiCoT. The core DC principles were used to support reasoning about qualities of the design of the current system. In order to test the utility of DiCoT for reasoning about new designs, two re-designs of the system were proposed. DiCoT was applied to reasoning about these re-designs. Since these redesigns have not been implemented, it is not possible to validate the conclusions drawn, but this exercise has been a ‘proof of concept’ to show that the method can be applied to both existing and proposed designs. Before presenting the detailed literature analysis and the case study, we briefly review related work on DC. 1.2 Background: Distributed Cognition Various team-working contexts have been analysed in terms of DC. Hutchins [9] analysed the team working behaviours of, and the designs of the artefacts used by, the navigation team on a large naval vessel. Hutchins and others [7,8] have conducted similar analyses of team working and the design of systems in an aircraft cockpit. Fields, Wright, Marti and Palmonari [5] apply DC to an air traffic control (ATC) room to assess the representations and their distribution, manipulation and propagation through the ATC system. They recognise that a potential criticism of their work is the lack of method that takes them from analysis to design. This is one of the issues that our work on DiCoT addresses. Artman and Waern [1] analyse work in an emergency control room from a Distributed Cognition perspective. Their work contrasts with that reported here in that they focus primarily on the dialogue between participants and how understanding is shared through the verbal channel, whereas the work reported here also considers the artefacts in the environment and how their design and spatial arrangements support or hinder group working. Wright, Fields and Harrison [13] have made DC more accessible to the HCI community by developing a Resources Model which clarifies how abstract resource structures can be coordinated in strategies to produce behaviour. Wright et al [13] intentionally address a single-user–single-device system to show how DC can be

28

A. Blandford and D. Furniss

applied to traditional software design. However, they acknowledge that there is more work to be done to extend DC to collaborative settings.

2 From the Literature to DiCoT Hutchins [9] presents DC as a view on how information is transformed and propagated around a system. The DC approach can be distinguished from other theoretical methods by its commitment to two related principles [6]: 1. The unit of analysis is expanded so that the “cognitive process is delimited by the functional relationships among the elements that participate in it, rather than by the spatial collocation of the elements”. 2. The analysis looks for a range of mechanisms that can partake in the cognitive system rather than restricting itself to symbol manipulation and computation (e.g., the interplay between human memory, external representations and the manipulation of objects). Hollan et al. [6, p.176] argue that many of the concepts and vocabulary familiar to classical information processing cognitive science can be retained, but that the unit of analysis needs to be expanded from the individual to the wider system. They suggest three ways in which cognition may be distributed: 1. “Cognitive processes may be distributed across the members of a social group.” 2. “Cognitive processes may involve coordination between internal and external (material or environmental) structure.” 3. “Processes may be distributed through time in such a way that the products of earlier events can transform the nature of later events.” This gives some indication of the sorts of observations and phenomena that a DC analysis might highlight; we have expanded on these by reference to the broader DC literature to present a set of principles of DC. The three themes that have been the focus of the work to date are: physical layout; information flow; and the design and use of artifacts. Two further themes—evolution over time and the role of social structures in coordinating activity—have not to date formed a focus for analysis, and are therefore omitted from the current account. For each of the three primary themes, there are three components to DiCoT. The first is the set of principles that pertain to that theme; the second is a set of diagrammatic representations that illustrate structure and flow from the relevant perspective; the third is a set of tabular representations that present a summary of the system, details, further observations and issues that emerge, all from the viewpoint of the theme. This tabular representation focuses on narrative, and on highlighting features of the system in relation to the relevant principles. 2.1 Physical Layout The physical model describes those factors that influence the performance of the system, and of its components, at a physical level. This description is important from a distributed cognition perspective as those things that can be physically heard, seen

DiCoT: A Methodology for Applying Distributed Cognition

29

and accessed by individuals have a direct impact on their cognitive space and hence will shape, empower and limit the calculations that individuals perform. Thus, the first set of principles relate to the physical organisation of work— whether concerning the large-scale structures or the details. Principle 1: Space and Cognition. Hollan et al. [6] discuss the role of space in supporting cognition. They present examples of the use of space such as supporting choice and problem solving. For example, in the work presented here, we found that ambulance controllers lay information out on their desks in ways that support their planning (e.g., by grouping the ‘tickets’ that correspond to future jobs by time). Principle 2: Perceptual Principle. Norman [11, p.72] argues that spatial representations provide more support for cognition than non-spatial ones provided that there is a clear mapping between the spatial layout of the representation and that which it represents. An example from the ambulance control domain is that calls are displayed on the allocator’s screen in order of priority. Principle 3: Naturalness Principle. Similarly, Norman [11, p.72] argues that cognition is aided when the form of the representation matches the properties of what it represents; in these cases what is experienced is closer to the actual thing, so the necessary mental transformations to make use of the representation are reduced. This is referred to elsewhere as ‘stimulus–response compatibility’. Principle 4: Subtle Bodily Supports. In interacting with the environment, an individual may use their body to support their cognitive processes; for example, pointing at a place in a book whilst responding to an interruption is part of the mechanism of remembering where we are (Hutchins, 1995a, p.236). Principle 5: Situation Awareness. One of the key aspects of shared tasks is that people need to be kept informed of what is going on, what has happened and what is planned (Norman, 1995). The quality of this situation awareness can be influenced by how accessible the work of the team is. This can also be influenced by the proximity of the person, involving both observation and overhearing conversation. Situation awareness in ambulance control has been studied by Blandford and Wong [3]. Principle 6: Horizon of Observation. The horizon of observation is what can be seen or heard by a person [9, p.268]. For each person in an environment, this depends on their physical location, the activities they are close to, what they can see, and the manner in which activities take place. The horizon of observation of a person plays a large role in influencing their situation awareness. Principle 7: Arrangement of Equipment. From a DC perspective, the physical layout of equipment affects access to information, and hence the possibilities for computation. This applies to the different levels of access to people, their conversations and their work as well as to physical representations and artefacts [9, p.197]. For example, in each ambulance control team, the allocator and radio operator share access to certain items.

30

A. Blandford and D. Furniss

As we move from the principles towards modelling, there are a number of different levels which we might choose to model. We may take the environment of the individual, the team, the wider working unit or the organisation; the focus should be on sensible units of interest rather than pre-determined physical spaces. For ambulance control, we chose to focus on the structure of the sector desks (i.e., the main unit in which a team works) and the layout of the room (the environment within which teams coordinate their activities). In considering the effect of the physical layout of the system we focus on the component parts of the system and ask ourselves questions about the proximity of, and access to, devices and people: what can be seen in an individual’s horizon of observation and what can be heard in an individual’s zone of normal hearing? The answers to these questions affect the information processing ability of an individual and the information flow in the system. For each level of description, we generate a summary, then details, then add further observations and highlight issues that arise. Details cover two important aspects: support for communication and access to artefacts. We illustrate this briefly with extracts from the room level model. The room level model describes the physical layout of the Central Ambulance Control room, both graphically (Fig. 1) and in text. The description focuses on overall layout and the location of important shared artefacts such as call status boards. The summary and edited highlights from the additional detail sections are presented in Table 1.

H S EM

A A

A A

A

SE

A

A

A

SW

Fig. 1. Room layout (most sector desks are labelled with a region of the city; HEMS = helicopter control, FRU = fast responder units)

This description is produced iteratively. First, the diagram is checked to ensure that it includes all important artefacts and features. Second, the table is refined, pulling out issues relating the design of the system to the principles (identifying both positive and negative features). Space does not permit a full illustration of this process, but Table 1 provides a snapshot of the kind of reasoning involved.

DiCoT: A Methodology for Applying Distributed Cognition

31

Table 1. Physical model: Extracts from the room level description

SUMMARY There are seven sector desks in the London Ambulance Service control room, each of which has the responsibility of allocating ambulances to incidents in an area of London. Although these sectors provide operational boundaries, where different allocators are responsible for certain areas, it is their collective responsibility to provide the best service for the whole of London; this entails cross boundary working. This is achieved by allocators communicating with each other across the room.

DETAILS Communication (Access to Actors) The sector desks are organised roughly geographically, so sectors that border each other are close by for communication (Principle 5). When an allocator identifies the ambulance closest to an incident, it may be from a neighbouring sector. Permission to allocate ambulances from different sectors has to be obtained from that sector allocator. Hence, ease of communication between allocators is important for cross boundary working. Depending on where allocators are seated in the room, people will generally raise their voices to get their attention and communicate with them. If this is not possible then the telephone will be used. […]

Access to Artefacts The most prominent shared artefacts, at room level, are the boards which indicate the status of incoming calls: how many call takers are free and the percentage of calls that have been answered within an allocated time period. These boards are located high on the wall so that they are accessible by everyone. This information gives an indication of how busy the call takers are, which indirectly indicates overall workload. […]

FURTHER NOTES − Call takers are situated in a different area from the sector desks. The floor to the call taker’s area is at a lower level. This adds a further degree of distinction between the two and could help reduce sound travelling. − The control desk is raised to provide an overview of the room (Principle 6). […]

ISSUES − The allocators are not always within easy reach of each other. This may be important where an incident requires multiple crews from different sectors. − The display giving the status of the call takers’ work load and performance does not directly impact on the allocators’ work load.

2.2 Information Flow The physical structure partly determines how information flows and is transformed within a work setting. The second theme for analysis focuses on information flow more specifically. This turns the focus of the analysis to the communication between the participating members, what their roles are and the sequences of events, which define the mechanics of the system. We start by outlining the principles derived from the literature relating to how information flows and is transformed. Principle 8: Information Movement. Information moves around the system. This can be achieved in a number of different ways which have different functional

32

A. Blandford and D. Furniss

consequences for information processing. These ways differ in their representation and their physical realisation. Different mechanisms include: passing physical artefacts; text; graphical representation; verbal; facial expression; telephone; electronic mail; and alarms. Even inaction might communicate information [9]. Principle 9: Information Transformation. Information can be represented in different forms; transformations occur when the representation of information changes. This can happen through artefacts and communications between people. Appropriate representations support reasoning and problem solving [9]. One important transformation is filtering, in which information is gathered, sifted and structured. In ambulance control, filtering is a central activity of call takers, who solicit and structure information from callers for onward transmission to the relevant sector desk. Principle 10: Information Hubs. Information hubs can be considered as a central focus where different information channels meet, and where different information sources are processed together (e.g., where decisions are made on various sources of information [3]). Busy information hubs can be accompanied by buffers that control the information to the hub, to keep it working effectively. Principle 11: Buffering. As information propagates around a system, there may be times when the arrival of new information interferes with important ongoing activity. This can create conflict and increase the chances of an error occurring, either because the new information gets lost or distorted or because the interruption provokes a mistake within the ongoing activity [9, p.195]. Buffering allows the new information to be held up until an appropriate time, when it can be introduced. In the case of ambulance control, radio operators frequently buffer information for their sector allocators. Principle 12: Communication Bandwidth. Face-to-face communications typically impart more information than those conducted by other means, including computer mediated communication, radio and telephone [9, p.232]. This richness needs to be recognised when technologies are redesigned. Principle 13: Informal Communication. Informal communication can play an important functional role in the system, including the propagation of important information about the state of the system and the transfer of knowledge through stories, which can have important consequences for learning how the system behaves [9]. Principle 14: Behavioural Trigger Factors. It is possible for a group of individuals to operate without an overall plan as each member only needs to know what to do in response to certain local factors. These can be dubbed ‘trigger factors’ because of their property of triggering behaviour [9]. Three separate viewpoints on information flow have been developed to capture different aspects of the way information is transferred around a system:

DiCoT: A Methodology for Applying Distributed Cognition

33

1. A high level view focuses on the overall input, transformation and output of the system. 2. An agent-based view focuses on the principal agents within the system and the flows between them. The properties of each of the main communication channels are identified. In this case study, we chose to focus on the human agents, and not to consider the interactions between a human and their computer systems: that was left for the artefact model. This decision was made because there is little computermediated communication in the current system design. 3. The third view is an adaptation of the second, focusing on how information is buffered, filtered and transformed within the system (referring specifically to the principles for information flow presented above). For the second and third views, we have adopted the same structure as the physical model described above, of presenting a summary, detail, further notes and issues. For illustrative purposes in this paper, we present just the diagrammatic representation of the enhanced information flow model (item 3 in the list above). This is shown in Figure 2, and expanded on in Table 2, which includes an outline of the key properties of each information channel and node. The issues that emerge from this representation include the importance of buffers for helping the allocator perform effectively under high workload conditions, and the

Fig. 2. Overview of information flow, focusing on buffers, hubs and filters (see also Table 2)

34

A. Blandford and D. Furniss Table 2. Description of the main flow properties shown in Fig. 2

Process I Filtering of External Caller Information

II Allocator at the Decision Hub III The Buffer of the Telephone Dispatcher IV The Buffer of the Radio Operator

V Discontinuity in Communication Media used by the Ambulance Crews

Summary Call takers receive calls from external callers who help in filtering out the required information so that the system can perform effectively. When appropriate, they will also negotiate times that hospital transfers need to be made with doctors, which has an impact on the management of resources in the rest of the system. In focusing on the process of allocating ambulances to incidents, the allocator can be seen as the central person that makes the decision of what ambulance should go where and when. The telephone dispatcher supports the allocator by dealing with incoming telephone calls and contacting outside parties as required through the business of allocating. This provides an extended arm of communication for the allocator and protection against a potential barrage of incoming calls. The radio operator supports the allocator by dealing with incoming radio communications from mobile crews and contacting them whilst away from the station. This provides an extended arm of communication for the allocator and protection against a potential barrage of incoming requests and queries. The ambulance crews have two mains forms of communication that they use to talk to the sector desk: they use the phone when they are at the station and away from their vehicle; and use the radio when in their vehicle. This discontinuity is amplified as the two communication channels are dealt with by different people at the LAS control room. In addition, the allocator can send information direct to the crew when mobile via their mobile data terminal.

discontinuity in communication channels and media as crews move from being on station to being in their vehicles to being at scene. We discuss the second of these issues further below in proposing a small design change to the system. 2.3 Artefacts As discussed above, from a DC perspective the environment that we inhabit plays a central role in cognition, bringing artefacts, representations, and environmental affordances centre stage in a cognitive analysis. Thus, a third important consideration within DC is how artefacts are designed to support cognition. Principle 15: Mediating Artefacts. To support activities, people make use of ‘mediating artefacts’ [9, p.290]. Mediating artefacts include any artefacts that are brought into coordination in the completion of the task. In ambulance control, the ‘tickets’ that contain information about incidents are essential mediating artefacts, being passed around between team members and annotated to keep track of the state of the incident. Principle 16: Creating Scaffolding. Hollan et al. [6, p.192] argue that people use their environment constantly by creating “external scaffolding to simplify our cognitive tasks”. For example, we may create reminders of where we are in a task.

DiCoT: A Methodology for Applying Distributed Cognition

35

Principle 17: Representation–Goal Parity. One way in which external artefacts can aid cognition is by providing an explicit representation of the relationship between the current state and a goal state [9]. The closer the representation is to the cognitive need or goal of the user, the more powerful that representation will be. In the case of ambulance control, the allocator’s goal is often to obtain a clear screen – one with no outstanding jobs. Principle 18: Coordination of Resources. Abstract information structures, or ‘resources’, can be internally and externally coordinated to aid action and cognition. The six resources Wright et al [13] describe in their Resources Model are: plans, goals, affordance, history, action-effect, and current state. The artefact model considers the detailed design of individual artefacts that support the work of the team. In our case study, we focused attention on those artefacts and representations considered central to the performance of the system—i.e., the computer system, a supporting paper ticket system and a communal status board. At an individual artefact level, we want to ask questions about how its design impacts on shaping, structuring and empowering cognition at either team or individual level. By building up a model of the artefact, and the system in which it operates, we aim to understand how it contributes to system performance. To this end we can use the Resources Model [13] to inform how resources are internally and externally represented in the system. The better the understanding we have of how information propagates around the current system, the better our chances of identifying design issues that should be attended to in any system redesign. Diagrammatic representations of artefacts include both physical structures (e.g., the layout of a computer display) and how artefacts move around the systems (e.g., the ways ambulance control tickets are passed between team members and the significance of each transaction in terms of communication and coordination). These representations and related structures help identify strengths and limitations of the current artefact designs; for instance, as the ambulance service considers replacing paper tickets by a computer-based representation, the model helps identify the important roles and features of paper tickets that need to be preserved in any computer based implementation of this functionality.

3 Reasoning About Re-design As a brief example of the use of DiCoT to reason about re-design, we consider changing the flow of communication between allocator and crews. As shown in Figure 2, and discussed above, there is a discontinuity in the ways Central Ambulance Control communicate with crews. We could propose changes in the information flow structure. More flexible communication channels could be added (e.g., personal radio or other mobile device) so that the crew could be contacted regardless of whether they are at a station or mobile. Also, the allocation of a crew at a station could be more automated; for example, an allocator could allocate a station, a data terminal would then alert all crews of the details at the station, and one crew would accept the call, which would then be forwarded to their vehicle. Both of these communication

36

A. Blandford and D. Furniss

changes would reduce the need for a telephone dispatcher. An alert for station data terminals could even be incorporated on the new communication devices; e.g. it could operate something like a pager. The merits and disadvantages of this modification can be considered by comparing a DC analysis of the new information flow with that of the old. Claims Analysis, described by Carroll and Rosson [4] as a form of “cognitive design rationale”, has been chosen to represent this comparison. Such a design rationale is illustrated in Table 3. Since this analysis is being conducted from a DC perspective, considerations such as costs of set-up and maintenance of alternative communications devices have been omitted, but would clearly be important in a full consideration of design changes. This example is necessarily brief. It serves simply to illustrate one possible approach to using DiCoT to support reasoning about the design of systems that have not yet been implemented. The consideration of this design option has led to the identification of potential design issues that need to be considered if the system is to be reorganised (see Table 3 for example). In practice, those design ideas that appear to have the best chance of improving the current system were not found to be big structural changes, but incremental modifications such as reviewing the communication channels between the sector desks and crews, and improving crossboundary working through the computer system. Table 3. Claims Analysis of more flexible communications to crews

Design Feature

Hypothesized Pros (+) or Cons (-) of the Feature

Have a one-stop communication channel with crews

+ allows greater flexibility in contacting crew + could open potential for telephone dispatcher and radio operator to job share + can improve communications between crew and external party + telephone dispatcher’s call to station is automated, freeing them for other tasks + allocator can treat allocating a call to a station in much the same manner as to a mobile vehicle - automation will need further equipment and the addition of activities performed by the crew - reducing verbal communication between LAS staff and crews might have negative social consequences

Further automate allocating crews at a station

4 Discussion The aim of this paper has been to develop a structured method of analysis for DC, iteratively developing an approach based on existing research and practice, using a case study to focus development. This case study approach ensured that we took account of practical limitations, complexities and constraints, and made it possible to constantly evaluate what was done well, what was not, and what needed to be included to make the method work practically.

DiCoT: A Methodology for Applying Distributed Cognition

37

The method took explicit account of most of the DC principles that had been identified in the literature, both in devising the representations to be developed (which also drew on the Contextual Design approach [2]), and in the subsequent analysis approach. The DC principles that have been downplayed in the approach are those that relate to the evolution of the design—a factor that is more central to Activity Theory [10] than DC— and to social factors. These would ideally be considered in an extended DC method, but were outside the scope of this study. As well as developing a preliminary methodology for conducting a DC analysis, this study has also yielded useful insights into the design of an ambulance control system. Although the study has highlighted a few areas where the design of systems and work spaces could be improved, it has also highlighted why so many aspects of the current design work well. For example, it has shown why the positioning of the radio operator to the side of the allocator (so that many artefacts can be shared and good situation awareness maintained, and so that the radio operator can buffer information for the allocator at times of high workload) is effective. The conception of how DC can be used as a design tool should be viewed as one possible approach to developing DC rather than a complete account. The possibility of such a use for DC has been alluded to elsewhere but, to the best of our knowledge, has not previously been described. The use of such an approach in this context seems like a suitable way to proceed given that large complex systems (e.g., control rooms) cannot simply be physically built and tested. Claims analysis [4] has been used as an approach to aid design reasoning, and appears to be promising. In the work reported here, we have aimed to address claims that DC lacks visibility within the HCI community, although it is relevant for analysis and design [13], and that DC cannot currently be used as an ‘off the shelf’ methodology [12]. By making the theory more accessible to understand and apply, it is hoped that practitioners and researchers will be in a better position to engage with it through practice, criticism and development.

Acknowledgements This work is supported by EPSRC grant GR/S67494. We are grateful to the management and staff of London Ambulance Service who supported us in this study.

References 1. Artman, H. & Waern, Y. (1999) Distributed Cognition in an Emergency Co-ordination Center. Cognition, Technology and Work. 1. 237-246. 2. Beyer, H., Holtzblatt, K.: Contextual Design. San Francisco : Morgan Kaufmann. (1998). 3. Blandford, A. & Wong, W. (2004) Situation Awareness in Emergency Medical Dispatch. International Journal of Human–Computer Studies. 61(4). 421-452. 4. Carroll, J. M. & Rosson, M. B. (1992) Getting around the task-artifact cycle: how to make claims and design by scenario. ACM Transactions on Information Systems, 10(2), 181-21. 5. Fields, R., Wright, P., Marti, P. & Palmonari, M. (1998). Air Traffic Control as a Distributed Cognitive System: a study of external representation. In Green, T., Bannon, L., Warren, C. & Buckley, J. (eds) ECCE9: Proceedings of the Ninth European Conference on Cognitive Ergonomics. pp 85-90.

38

A. Blandford and D. Furniss

6. Hollan, J. D., Hutchins, E. L. & Kirsh, D. (2000) Distributed cognition: toward a new foundation for human-computer interaction research. ACM Transactions on CHI, 7.2, 174-196. 7. Hutchins, E. & Klausen, T. (1991) Distributed Cognition in and Airline Cockpit. in Y. Engeström and D. Middleton, Eds. Cognition and Communication at Work, Cambridge: Cambridge University Press. 8. Hutchins, E. (1995) How a Cockpit Remembers Its Speed. Cogntiive Science, 19, 265-288 9. Hutchins, E. (1995a) Cognition In The Wild. MIT Press, Cambridge, MA. 10. Nardi, B. (1996a). Studying Context: A comparison of activity theory, situated action models, and distributed cognition. In Nardi, B. (ed) Context and Consciousness: Activity theory and human-computer interaction. pp 69-102. MIT Press. 11. Norman, D. (1995). Things that Make Us Smart. Addison Wesley. 12. Rogers, Y. & Scaife, M. (1997). Distributed Cognition. Retrieved 12/08/04, from wwwsv.cict.fr/cotcos/pjs/TheoreticalApproaches/DistributedCog/DistCognitionpaperRogers.htm 13. Wright, P. C., Fields, R. E. & Harrison, M. D. (2000) Analysing Human–Computer Interaction as Distributed Cognition: The Resources Model. HCI Journal. 15.1. 1-41.

Towards Model Checking Stochastic Aspects of the thinkteam User Interface Maurice H. ter Beek, Mieke Massink, and Diego Latella CNR/ISTI – ‘A. Faedo’, Via G. Moruzzi 1, 56124 Pisa, Italy {m.terbeek, m.massink, d.latella}@isti.cnr.it

Abstract. Stochastic model checking is a recent extension of traditional modelchecking techniques for the integrated analysis of both qualitative and quantitative system properties. In this paper we show how stochastic model checking can be conveniently used to address a number of usability concerns that involve quantitative aspects of a user interface for the industrial groupware system thinkteam. thinkteam is a ready-to-use Product Data Management application developed by think3. It allows enterprises to capture, organise, automate, and share engineering product information and it is an example of an asynchronous and dispersed groupware system. Several aspects of the functional correctness, such as concurrency aspects and awareness aspects, of the groupware protocol underlying thinkteam and of its planned publish/subscribe notification service have been addressed in previous work by means of a traditional model-checking approach. In this paper we investigate the trade-off between two different design options for granting users access to files in the database: a retrial approach and a waitinglist approach and show how stochastic model checking can be used for such analyses.

1 Introduction Computer Supported Cooperative Work (CSCW) is an interdisciplinary research field that deals with the understanding of how people work together, and the ways in which computer technology can assist. This technology mostly consists of multi-user computer systems called groupware [16]. Groupware is often classified according to the time-space taxonomy given by Ellis [16], (i.e., whether its users: (1) work together at the same (synchronous) or at different (asynchronous) times and (2) work together in the same (co-located) or in different (dispersed) places). In this paper we deal with thinkteam, which is an asynchronous and dispersed groupware system, as is email. Recently there has been an increasing interest in using model checking for formal verification of (properties of) groupware [6, 26, 27]. Some properties of interest are related to important groupware design issues like user awareness and concurrency control. In [7, 8] we have used a traditional model-checking approach, using the model checker S PIN [22], to formalise and verify some properties specifically of interest for the correctness of general groupware protocols (i.e., not limited to thinkteam’s context). 

This work has been partially funded by the EU project AGILE (IST-2001-32747). For further details, the reader is referred to the technical report of this paper [5].

S.W. Gilroy and M.D. Harrison (Eds.): DSVIS 2005, LNCS 3941, pp. 39–50, 2006. c Springer-Verlag Berlin Heidelberg 2006 

40

M.H. ter Beek, M. Massink, and D. Latella

Many interesting properties of groupware protocols and their interfaces can be analysed a priori (i.e., before implementation) by means of a model-based approach and model-checking techniques. There are, however, usability issues that are influenced by the performance of the groupware system rather than by its functional behaviour. One such issue was raised by the analysis of thinkteam with a traditional model-checking approach in [7, 8]. It was shown that the system could exclude a user from obtaining a file simply because other users competing for the same file were more ‘lucky’ in their attempts to obtain the file. Such behaviour was explained by the fact that users were only provided with a file-access mechanism based on a retrial principle. While analysis with traditional model checking can be used to show that such a problem exists, it cannot be used to quantify the effect that it has on the user. In other words, it cannot be used to find out how often, in the average, a user needs to perform a retry in order to get a single file. Of course, the number of retries a user has to perform before obtaining a file is an important ingredient for measuring the usability of the system. In this paper we address the retrial problem by means of stochastic model checking. This is a relatively new extension of traditional model checking that allows also for the analysis of quantitative properties of systems such as those related to performance and dependability issues [10, 20, 24]. Other work on the use of stochastic modelling for usability analysis has been performed in [11], where it has been shown that Markov models and traditional Markov-chain analysis can be used to obtain measures that give an indication of how hard it is for a user to use certain interactive devices. In [14], stochastic modelling has been used to analyse the finger-tracking interface of a whiteboard with augmented reality. The analysis was based on stochastic process algebra models with general (i.e., not necessarily exponential) distributions and discrete event simulation. The main purpose of this paper is to show that stochastic model checking can be a convenient model-based analysis technique to address usability issues that involve quantitative measures. We will explain how such analysis can be performed in the context of a simple but relevant industrial case study. In a further study we plan to collect more detailed statistical information on typical use of thinkteam in practice in order to calibrate the models for the analysis of specific situations. The current paper shows the formal specification of users and the system and their interactions, the formalisation of relevant quantitative properties and a number of numerical results.

2 thinkteam In this section we present a brief overview of thinkteam. For more information we refer the reader to [5, 7, 8] and http://www.think3.com/products/tt.htm. thinkteam is think3’s Product Data Management (PDM) application catering to the document management needs of design processes in the manufacturing industry. Controlled storage and retrieval of documents in PDM applications is called vaulting, the vault being a file-system-like repository. Next to providing a secure and controlled storage environment, vaulting must prevent inconsistent changes to the document base while still allowing maximal access compatible with the business rules. This is implemented in thinkteam’s underlying groupware protocol by a standard set of operations:

Towards Model Checking Stochastic Aspects

41

get – extract a read-only copy of a document from the vault, import – insert an external document into the vault, checkOut – extract a copy of a document from the vault with the intent to modify it, unCheckOut – cancel the effects of a previous checkout, checkIn – replace an edited document in the vault, and checkInOut – replace an edited document in the vault, but retaining it checked out. It is important to note that access to documents (via a checkOut) is based on the ‘retrial’ principle: currently there is no queue or reservation system handling the requests for editing rights on a document. thinkteam typically handles some 100,000 documents for 20–100 users. A user rarely checks out more than 10 documents a day, but she can keep a document checked out from anywhere between 5 minutes and a few days. To maximize concurrency, a checkOut in thinkteam creates an exclusive lock for write access. An automatic solution of the write access conflict is not easy, as it is critically related to the type, nature, and scope of the changes performed on the document. Moreover, standard but harsh solutions—like maintaining a dependency relation between documents and use it to simply lock all documents depending on the document being checked out—are out of the question for think3, as they would cause these documents to be unavailable for too long. For thinkteam, the preferred solution is thus to leave it to the users to resolve such conflicts. However, a publish/subscribe notification service would provide the means to supply the clients with adequate information by: (1) informing clients checking out a document of existing outstanding copies and (2) notifying the copy holders upon checkOut and checkIn of the document. In [7, 8] we studied the addition of a lightweight and easy-to-use publish/subscribe notification service to thinkteam and we verified several correctness properties. These properties addressed issues like concurrency control, awareness, and denial of service. Most properties were found to hold, with the exception of one concurrency-control and a denial-of-service property. The problem with the concurrency-control property arises when a user simply ‘forever’ forgets to checkIn the file it has checked out, which means that the lock on this file is never released. In thinkteam, such a situation is resolved by the intervention of a system administrator. The problem with the denial-of-service property is that it may be the case that one of the users can never get its turn to, e.g., perform a checkOut, because the system is continuously kept busy by the other users, while this user did express its desire to perform a checkOut. Such behaviour forms an integral part of the thinkteam protocol. This is because access to documents is based on the ‘retrial’ principle: thinkteam currently has no queue or reservation system handling simultaneous requests for a document. Before simply extending thinkteam with a reservation system, it would be useful to know: (1) how often, in the average, users have to express their requests before they are satisfied and (2) under which system conditions (number of users, file processing time, etc.) such a reservation system would really improve usability. We come back to this later.

3 Stochastic Analysis Traditionally, functional analysis of systems (i.e., analysis concerning their functional correctness) and performance analysis have been two distinct and separate areas of

42

M.H. ter Beek, M. Massink, and D. Latella

research and practice. Recent developments in model checking, in particular its extension to address also performance and dependability aspects of systems, have given rise to a renewed interest in the integration of functional and quantitative analysis techniques. A widely used model-based technique for performance analysis is based on Continuous Time Markov Chains (CTMCs). CTMCs provide a modelling framework, proved to be extremely useful for practical analysis of quantitative aspects of system behaviour. Moreover, in recent years proper stochastic extensions of temporal logics have been proposed and efficient algorithms for checking the satisfiability of formulae of such logics on CTMCs (i.e., stochastic model checkers) have been implemented [10, 20, 24]. The basis for the definition of CTMCs are exponential distributions of random variables. The parameter which completely characterises an exponentially distributed random variable is its rate λ, which is a positive real number. A real-valued random variable X is exponentially distributed with rate λ—written EXP (λ)—if the probability of X being at most t, i.e. Prob(X ≤ t), is 1 − e−λt if t ≥ 0 and is 0 otherwise, where t is a real number. The expected value of X is λ−1 . Exponentially distributed random variables enjoy the so called memoryless property (i.e., Prob(X > t + t | X > t) = Prob(X > t ), for t, t ≥ 0). CTMCs have been extensively studied in the literature (a comprehensive treatment can be found in [23]; we suggest [19] for a gentle introduction). For the purposes of the present paper it suffices to recall that a CTMC M is a pair (S, R) where S is a finite set of states and R : S × S → IR≥0 is the rate matrix. The rate matrix characterises the transitions between the states of M. If R(s, s ) = 0, then it is possible that a transition from state s to state s takes place, and the probability of such a transition to  take place within time t, is 1 − e−R(s,s )·t . If R(s, s ) = 0, then no such a transition can take place.1 We would like to point out that the traditional definition of CTMCs does not include self-loops, (i.e., transitions from a state to itself). On the other hand, the presence of such self-loops does not alter standard analysis techniques (e.g., transient and steady-state analyses) and self-loops moreover turn out to be useful when model checking CTMCs [4]. Therefore we will allow them in this paper. Usually CTMCs are not obtained in a direct way, due to the increasing complexity of the analysed systems, but instead generated automatically from higher-level specifications given in languages such as e.g. stochastic Petri nets, stochastic process algebras or stochastic activity nets [9, 25]. Our approach is no different. We specify our model of thinkteam’s underlying groupware protocol in the stochastic process algebra PEPA (Performance Evaluation Process Algebra) [21]. This specification is consequently read into a stochastic model checker, which then automatically builds a CTMC from it.

4 Stochastic Model Checking In the model-checking approach to performance and dependability analysis a model of the system under consideration is required together with a desired property or performance/dependability measure. In case of stochastic modelling, such models are 1

This intuitive interpretation is correct only if there is only one transition originating from s. If this is not the case, then a race condition arises among all transitions originating from s.

Towards Model Checking Stochastic Aspects

43

typically CTMCs or high-level specification languages to generate them, while properties are usually expressed in some form of extended temporal logic. Here we use Continuous Stochastic Logic (CSL) [2, 3], a stochastic variant of the well-known Computational Tree Logic (CTL) [12]. CTL allows to state properties over states as well as over paths. CSL extends CTL by two probabilistic operators that refer to the steady-state and transient behaviour of the system under study. The steady-state operator refers to the probability of residing in a particular state or set of states (specified by a state formula) in the long run. The transient operator allows us to refer to the probability mass of the set of paths in the CTMC that satisfy a given (path) property. To express the time span of a certain path, the path operators until (U) and next (X) are extended with a parameter that specifies a time interval. Let I be an interval on the real line, p a probability value and  a comparison operator, (i.e.,  ∈ { }). The syntax of CSL is: State formulae:

Φ ::= a | ¬ Φ | Φ ∨ Φ | Sp (Φ) | Pp (ϕ) Sp (Φ) : probability that Φ holds in steady state  p Pp (ϕ) : probability that a path fulfills ϕ  p

Path formulae:

ϕ ::= X I Φ | Φ UI Φ X I Φ : next state is reached at time t ∈ I and fulfills Φ Φ UI Ψ : Φ holds along path until Ψ holds at t ∈ I

The meaning of atomic propositions (a), negation (¬) and disjunction (∨) is standard. Using these operators, other boolean operators like conjunction (∧), implication (⇒), true (TRUE) and false (FALSE), and so forth, can be defined in the usual way. The state formula Sp (Φ) asserts that the steady-state probability for the set of states satisfying Φ, the Φ-states, meets the bound  p. Pp (ϕ) asserts that the probability measure of the set of paths satisfying ϕ meets the bound  p. The operator Pp (.) replaces the usual CTL path quantifiers ∃ and ∀. In CSL, the formula P≥1 (ϕ) holds if almost all paths satisfy ϕ. Moreover, clearly ∃ ϕ holds whenever P>0 (ϕ) holds. The formula Φ U I Ψ is satisfied by a path if Ψ holds at time t ∈ I and at every preceding state on the path, if any, Φ holds. In CSL, temporal operators like 3, 2 and their real-time variants 3I or 2I can be derived, e.g., Pp (3I Φ) = Pp (TRUE U I Φ) and P≥p (2I Φ) = P ?  .. HH @<       i    z  uz(( u q uq @ ql @ @l  OlOlO O  SS   S S  S . .  $$ rrr  OjOjO))jOjj@ @  U@NUNUN U &N & UN  U U .. HHH  1 is shown in Figure 5. It calls newterms

classify(term t) { if (exists c in EQC and matrix(rep(c)) = matrix(t)) put t in c; else new class c’; put c’ in EQC; if (matrix(t) = matrix(go(s)) for state set s) put go(s) in c’; r = go(s); else r = t; fi put t in c’; extend rep so that rep(c’) = r; put r in Novel; fi } Fig. 2. The classify function

Automatic Critiques of Interface Modes

209

redundant(term t):bool { red = false; for (c in EQC) for (q in c) if (not(q == rep(c)) and t == pq) red = true; return red; } Fig. 3. The redundant function newTerms(int n) { Seeds = Novel; Novel = {}; for (t in Seeds) for (e in Unique) if (not(redundant(t.e))) classify(t.e); } Fig. 4. The newTerms function computeEquivClasses(int n) { C = {Id}; r(C) = Id; EQC = {C}; Novel = {}; for (e in E) classify(e); Unique = Novel; if (n > 1) i = 1; do newTerms(i); i++; until (i > n) or Novel = {}; } Fig. 5. The main algorithm for computing equivalence classes

for successive values of n, until the bound is reached or until no new novel terms are introduced by this cycle. In the latter case we say the equivalence classes are saturated: the classification for any larger term can be computed algebraically from the existing classification, and so further classification is pointless. Note that the algorithm is presented in a simple form and considerable efficiency savings could be made, e.g. by using a dynamic programming approach to build up terms during the classification. 5.2 Automation—Identifying Modes N for the set of terms TEN , we can generate Having computed the equivalence classes CE algebraic properties that define action modes. Global properties of the interface can be

210

J. Gow, H. Thimbleby, and P. Cairns

found by equating a term with its class representative, but here we are interested in the non-global properties that define modes. Formally, pairs of equivalence classes C1 , C2 are compared to see if there is a set of states m such that go(m).φ(C1 )

≡

go(m).φ(C2 )

i.e. that matrices for C1 and C2 are equivalent for the rows corresponding to the states of m. If this holds, then m is an action mode defined by the property φ(C1 ) ≡ φ(C2 ). This process may return unmanageably many modes for any non-trivial interface, and the potential modes must be pruned in some way: a minimum mode size for m can be enforced, or a bound on size of property (we treat repetitions of the same event as a single event, e.g. e.e is e2 .) Another technique is to generalise a set of similar modes into a single mode, e.g. e ≡ f for mode m1 , e.e ≡ f for m2 and e.e.e ≡ f for m3 can be generalised to ∃N. eN ≡ f for mode m1 ∧ m2 ∧ m3 . Finally, the designer should be able to review and filter the generated modes to select those they judge useful for further analysis.

6 Discussion Several authors have used formal methods to model mode problems, in particular those caused by abstraction and automation [3]. Rushby used model checking to find divergence between user and system models [10]. In a similar vein, Bredereke and Lankenau provided a more rigorous characterisation of mode confusion [1]. In contrast, our model addresses a different form of mode confusion — specifically caused by inconsistency — and does not require a user model. Other types of mode confusion might be better understood with similar formal models that complement existing heuristic approaches, such as [8]. Inconsistency-related mode confusion is a familiar heuristic concept in HCI. Miller and Potts take a formal approach to avoiding such mode confusions in the context of cockpit interfaces [9]. They prove lemmas in PVS stating that certain switches always act as toggles. In our approach this is expressed as a simple algebraic property, e.g. A.A = N othing. Not only is this a clearer representation, we also formally characterise inconsistent violations of this property, as well as many others. Moreover, we have provided a method for automating this analysis. The scalability of automating our approach is an issue: the ‘combinatorial explosion’ will render our automatic analysis impractical for large enough systems. As discussed above, this can be mitigated with more sophisticated implementations. Comparable limits in model checking have been pushed back so that extremely large state systems can now be analysed. More importantly, even a restricted amount of system analysis may reveal interesting mode inconsistencies. Our priority for further research is the evaluation of the theory and methodology described here, using the prototype implementation in MAUI [4]. This is initially being done by testing the theory on a corpus of interface designs. Our notion of inconsistency could be refined by measuring near-subsets based on a weighting of interface states. As users will spend more time in some states, these will bias their perception of interface behaviour, and therefore their learning (and mislearning) of mode relationships. There is also scope for extending the classification of mode types beyond action/indicator.

Automatic Critiques of Interface Modes

211

Modifying a design is a rather open-ended activity and is of course best suited to human designers. A tool can however still make very useful suggestions for reducing mode inconsistencies. We intend to extend our techniques to suggest possible mode redesigns as well as improving the identification of existing mode inconsistencies. A design tool can establish or check many other sorts of property. Further work should explore convenient ways to express a large range of such properties — and in a way that is ‘designer friendly’ rather than logic-driven. We have various parameters to our methodology as constants: the minimum bound for inconsistency ρ, the maximum product size N , and the minimum mode size. These could, instead, be ‘sliders’ on the design tool: the designer could adjust the slider to get the level of detail (pedantry?) that they want to work with. Perhaps — and we look forward to trying this — it would be insightful to visualise the effects of these parameters by drawing graphs. Further research may develop ways to automatically determine values that give a ‘reasonable’ description of the interface design.

7 Conclusions We have presented a general, formal model of inconsistency-related mode confusion and an accompanying methodology for mode analysis, a significant amount of which can be automated. The model is general enough to provide a framework for further study into consistency and mode confusion. We have argued here that inconsistent modes are an important user interface feature that are likely to cause users problems. Generally, they should best be avoided unless there are contra-indications due to the nature of the user’s task. Unfortunately inconsistent modes are a non-trivial implicit feature of user interfaces and therefore not easily avoided by diligent designers; fortunately, as this paper shows, they can be enumerated automatically by appropriate tools, such as the MAUI system, which we are in the process of evaluating. The approach has the potential to give ordinary designers useful usability insights: a simple specification language is used and, with appropriate tool support and automation, we anticipate that little training would be required. Acknowledgements. Jeremy Gow is funded by EPSRC grant GR/S73723/01. Harold Thimbleby is a Royal Society Wolfson Research Merit Award Holder.

References 1. J. Bredereke & A. Lankenau (2002), “A rigorous view of mode confusion.” In Anderson, Bologna & Felici (eds), Computer Safety, Reliability and Security, Proc. SAFECOMP 2002. LNCS 2434, Springer, pp19–31. 2. E. M. Clarke, E. A. Emmerson & A. P. Sistla (1999), Model Checking. MIT Press. 3. A. Degani (1996), “Modelling human-machine systems: On modes, error and patterns of interaction.” PhD thesis, Georgia Institute of Technology. 4. J. Gow & H. Thimbleby (2004), “MAUI: An interface design tool based on matrix algebra.” In Jacob, Limbourg & Vanderdonckt (eds), Computer-Aided Design of User Interfaces IV, Proc. CADUI 2004. Kluwer.

212

J. Gow, H. Thimbleby, and P. Cairns

5. J. Gow, H. Thimbleby & P. Cairns (2004), “Misleading behaviour in interactive systems,” In Dearden & Watts (eds), Proc. 18th British HCI Group Annual Conference (HCI 2004), Volume 2. 6. D. Harel & A. Naamad (1996), “The STATEMATE semantics of Statecharts,” ACM Transactions on Software Engineering and Methodology, 5(4):293-333. 7. G. J. Holzmann (2003), “The SPIN model checker,” Addison-Wesley. 8. N. G. Leveson, L. D. Pinnel, S. D. Sandys, S. Koga & J. D. Reese (1997), “Analyzing software specifications for mode confusion potential.” In Johnson (ed.) Proc. Workshop on Human Error & System Development, Glasgow, pp132–146. 9. S. P. Miller & J. N. Potts (1999), Detecting Mode Confusion Through Formal Modeling and Analysis. NASA Contractor Report, NASA/CR-1999-208971. 10. J. Rushby (2002), “Using model checking to help discover mode confusions & other automation surprises,” Reliability Engineering & System Safety, 75(2):167–177. 11. H. Thimbleby (1982), “Character level ambiguity: Consequences for user interface design,” International Journal of Man-Machine Studies, 16:211–225. 12. H. Thimbleby (2004), “User interface design with matrix algebra,” ACM Transactions on Computer-Human Interaction, 11(2):181–236.

Quantitative Measurement of Quality Attribute Preferences Using Conjoint Analysis Kwang Chun Lee, Ho-Jin Choi, Dan Hyung Lee, and Sungwon Kang Information and Communications University, 119 Munjiro, Yuseong-Gu, Daejeon, Korea {statkclee, hjchoi, danlee, kangsw}@icu.ac.kr

Abstract. Conjoint analysis has received considerable attention as a technique for measuring customer preferences through utility tradeoffs among products and services. This paper shows how the method can be applied to the area of software architecture to analyze architectural tradeoffs among quality attributes. By eliciting customer utilities through conjoint analysis, software engineers can identify and focus on the useful quality attributes, which will increase the chance of delivering satisfactory software products to the customers. This paper proposes a quantitative method of measuring quality attribute preferences using conjoint analysis and demonstrates its efficacy by applying it to the Project Management Center (PMCenter) project. The proposed method is complementary to the Architecture Trade-off Analysis Method (ATAM) in that ATAM relies on customer’s feedback to elicit important quality attributes, whereas this method can be used to actually measure the utilities of quality attributes in a quantitative manner. Furthermore, our method provides a new framework for choosing architecture styles and design patterns based on customer’s preferences of quality attributes.

1 Introduction Software architecture has become an important area of research and practice within software engineering over the past 15 years [15]. Software architecture is critical for designing high-utility software products because it is an artifact that specifies early design decisions that would greatly affect subsequent development. Before enormous organizational resources have been committed, it would be extremely desirable to have an adequate method to determine whether quality goals can be achieved by the architecture [14]. The ATAM method developed by the Software Engineering Institute aims to assess the consequences of architectural decisions by using quality attributes-based scenarios [15]. However, the ATAM method lets architectural decision go into the heart of architecture construction without giving quantitative measurement of customer’s utility. We believe that by being able to measure the degrees of utilities to the customer we can design higher quality architectures and ultimately provide higher quality products to the customer. The aim of this paper is to propose a quantitative measurement method of quality attribute preferences using conjoint analysis, and to explore its potential impact on the development of software architecture. Measuring customer’s utility quantitatively is aligned with the development of high-utility software architecture. The remainder of S.W. Gilroy and M.D. Harrison (Eds.): DSVIS 2005, LNCS 3941, pp. 213–224, 2006. c Springer-Verlag Berlin Heidelberg 2006 

214

K.C. Lee et al.

the paper is structured in six parts. After this introduction, Section 2 is devoted to the explanation of the concept of software architecture and the ATAM method. Quality attributes play an important role in evaluating software architecture, but when combined with conjoint analysis, they can deliver more useful information. In Section 3 we explore conjoint analysis, followed by a study of the literature and the conjoint analysis process. In Section 4 the conjoint analysis in ATAM has been shown. It provides a new mechanism for quantitative utility measurement of quality attributes in ATAM. In Section 5 the results of PMCenter project are presented. Finally, Section 6 is the conclusion.

2 Software Architecture and ATAM Users naturally focus on specifying their functional, or behavioral, requirements, but there is more to successful software development than just delivering the right functionality. They are known as software quality attributes, or quality factors, and are parts of the system’s nonfunctional requirements [12]. These functional and non-functional requirements are inputs to following software development life-cycle. Recently many researchers and practitioners have realized the importance of software architecture before moving toward detailed design phase. When systems are constructed from many components, the organization of the overall system-the software architecture- presents design issues to software engineers [4]. The Architecture Tradeoff Analysis Method (ATAM) developed by the Software Engineering Institute (SEI) at CMU is a method for evaluating architecture-level designs that considers multiple quality attributes such as modifiability, performance, reliability and security in gaining insight as to whether the fully fleshed-out incarnation of the architecture will meet its requirements [9]. ATAM aims to identify architectural elements affecting quality attributes such that it helps to discover software architecture with high utility to customers. In particular, quality attributes facilitate communications among stakeholders. Even though ATAM has opened a new formal communication channel to deliver satisfactory software architecture to customers, it still assumes that customers are intelligent enough to provide sufficient and reliable information to software architects. In addition to it, measurement process and methods for customer utility have not been clearly documented. Therefore, ATAM aims to deliver high utility software architecture to customers, but it still lacks the ability to measure customer utility in a quantitative manner. Choosing appropriate architectures from the recent activity in cataloging architecture styles or design patterns which provides a broad palette of quality attributes and quantitative measurement of quality attribute preferences under the ATAM framework increases the possibility of delivering high utility software to customers.

3 Conjoint Analysis A customer decision process can be interpreted as a black box as shown in Fig. 1. Inputs are product attributes, external factors, and market information. Outputs are purchase decisions and related market behavior. In order to understand a customer decision process correctly, it is necessary to model cognitive mechanisms explicitly and then use

Quantitative Measurement of Quality Attribute Preferences

215

Fig. 1. Path diagram for the customer decision process adopted from [12]

experimental data to fit this model. Once the model is fitted to the data, a customer behavior prediction can be done through simulation. Since data is a valuable resource in terms of data collection cost and subsequent benefits, it is necessary to separate data collection with information extraction as shown in Fig. 2. Goal-driven or model-driven data collection is a good example. The purposedriven data collection provides analysts with much more information and high-fidelity knowledge sources. The purpose of utilizing models is to make it easier for stakeholders to understand customers correctly. If there are data on customer behavior linked to products or market information, statistical approach can be one of potentials. Recently many researchers and practitioners are paying special attention to data mining associated with data warehouse. Powerful computing and huge storage have made technical break-throughs in data-driven decision support. It is necessary to discover applicable methods in revealing customer preference in software architecture in regard to software data characteristics such as sparsity and small observations. Multi-attribute utility models or Analytical hierarchy process (AHP) can be a candidate, but they are not suitable for software architecture design because designing software architecture involves complex processes associated with many stakeholders communications, whereas both approaches emphasized small numbers of decision makers facing high-level decisions [7]. Conjoint analysis is based on the judgmental approach with defined data collection process. Self evaluation with well-defined data collection procedure enables customers to reveals their intentions. In addition, results of conjoint analysis can be used to simulate market share and effects of product penetration and cannibalization with the help of expert systems. Conjoint analysis is an additive model with compensatory multi-attributes. It assumes that the utility for a product can be expressed as a sum of utilities for its attributes

216

K.C. Lee et al.

Fig. 2. Data collection and information extraction

and utilities can be measured by customers overall evaluation of products. Furthermore estimates of the utilities can be used to predict market share through simulation. Each quality attribute has different functional form to overall utility. ui (QAi ) (1) U = u1 (QA1 ) + u2 (QA2 ) + · · · = i∈attributes

The conjoint analysis can provide a complementary approach in measuring customer utility in a quantitative manner. The conjoint analysis can measure customer utility quantitatively and objectively through well-defined process. In addition to it, it is not necessary for customers to understand ATAM or software system itself. Since the conjoint analysis delivers suitable design sets, the only thing that customers should do is to specify their preferences through ranking or comparisons, and then the defined conjoint analysis process will reveal the hidden customer preferences. Benefits from understanding customer preferences will lead to the development of high-quality software architecture and the smooth transition for the later part of software development life-cycle.

4 Conjoint Analysis in ATAM Conjoint analysis serves as a go-between to elicit customer architectural preference. Even if customers don’t have domain knowledge in quality attributes, architects can figure it out by applying conjoint analysis to ATAM. In order to utilize conjoint analysis in ATAM, four components such as quality attributes, experimental design, scenario generation, and analysis are needed as shown in Fig. 3. Based on quality attributes, architects make appropriate design plans to elicit architectural preference. In the scenario generation phase the design plans are tailored and elaborated to fit customer tastes.

Quantitative Measurement of Quality Attribute Preferences

217

Fig. 3. Conjoint analysis in ATAM

Customers evaluate them and fill out request form. In the final phase, statistical data analysis reveals customer architecture preference. 4.1 Process of Conjoint Analysis Conjoint analysis is one of many techniques for handling situations in which a decision maker has to deal with options that simultaneously vary across two or more attributes [7]. The seminal paper by Luce and Tukey [11] and the experimental design papers by Addelman [1] and Plackett and Burman [13] provided key theoretical underpinnings and motivation for developing conjoint analysis. In this paper, a typical conjoint analysis process [3] has been adopted and tailored for quantitative measurement of quality attributes preference not only to maintain process stability of conjoint analysis but also to embrace architecture quality attributes in the following framework. The process of conjoint analysis consists of six steps as shown by Fig. 4. Quality Attribute Selection. The first step of the conjoint analysis is to define the quality attributes. The SEI had research on refining quality attributes [10]. These quality attributes can be candidate attributes for the conjoint study. Depending on target systems (e.g. web-based system or real-time system), different sets of quality attributes can be defined. In addition, goal of target system affects quality attributes selection. For instance, there are conflicts between modifiability and performance since as real-time Java removed many functionalities to make it lighter, performance sometimes needs trade-offs of maintainability, configurability and so on. The priori information can be utilized to perform effective and efficient research design and reduce redundant subsequent tasks.

218

K.C. Lee et al.

Fig. 4. Conjoint analysis process tailored for preference analysis of quality attributes

Determination of Quality Attribute Levels. The second step is to determine the levels of quality attributes as shown in Fig. 5. Since quality attribute consists of quality attribute levels, quality attribute levels should be mutually exclusive and collectively exhaustive. In that case the quality attribute levels are sufficient to represent the quality attribute. One of quality attributes, performance, can be made of capability, concurrency, and processing time. Levels of quality attribute may be defined in different ways in order to identify customer preferences accurately. In addition, it should be realistic to ensure realism of the scenarios when presented to customers. Compared with prototype-based presentation, the scenarios-based presentation has implicit limitations, such that it should deliver sufficient and clear information through effective message mechanism. For example, utilizing visual images or audiovideo media associated with textual information may overcome limitations and deliver more realistic and detailed scenarios to help customers reveal preferences correctly and easily. Determination of Quality Attributes Combinations. The third step involves determining the combinations of quality attributes. If a customer is asked to rank too many architecture profiles, he/she will be exhausted by evaluating nearly similar and too many profiles. To avoid such wear-out and reduce the number of evaluating scenarios to a more manageable level, fractional-factorial designs are frequently used with orthogonal plans [5][6]. According to Pareto’s hierarchical ordering principle, the number of important factors is small and lower order factors are more likely to be important than higher order factors. Therefore, this approach is useful and relatively straightforward in that more often than not, quality attribute combinations are determined with fractionalfactorial and orthogonal plans.

Quantitative Measurement of Quality Attribute Preferences

219

Fig. 5. Candidate architecture generation using quality attributes and levels

Orthogonality is a strong assumption and sometimes unrealistic since two or three quality attributes are correlated and they become critical for software quality. Therefore, other design schemes to detect these patters are necessary. If priori information is not available, designs to investigate which quality attributes are significant are used in order to screen out potential factors out of trivial many factors. Once significant factors are discovered, fractional designs are used to investigate interaction patterns among quality attributes. The two-stage design strategy is desirable for relaxing orthogonal assumption and identifying interactions. Determination of Approach to Obtaining Customer Judgements. The fourth step is to determine an approach to obtaining customers judgements. There are various ways to obtain customers judgement such as rating, ranking, etc. One of popular presentation methods is to show profile cards or paragraph descriptions to customers. Pictorial materials or actual prototypes are frequently used to enhance realism in representing product characteristics. Once these stimuli are represented, customers are asked to obtain ranking and rating scales judgement for each of stimuli. Profiles do not contain all the attributes, such that fractional-factorial designs are typically used. Attributes are divided carefully, such that profiles contain partial and different attributes. Besides, paired comparisons are common in computer-assisted methods [6]. In computer-aided cases, customers are asked to reveal their preference by selecting only one out of two candidates and repeat this process in a similar manner. Determining How Judgements Will Be Aggregated. The fifth step involves determining how judgements will be aggregated. If there are multiple respondents, it is necessary to determine how those judgements are collected and represented. When dealing

220

K.C. Lee et al.

with different customers, data pooling of similar respondents’ conjoint full-profile responses through clustering algorithms can increase the accuracy of estimation and avoid biases. If software engineers aim to develop high-quality software products focused on multiple customers, influence of customers and interaction with developers should be dealt with in a formal framework. A Bayesian approach can provide a consistent framework to figure out this situation. However, it will be skipped in this research because there is only one stakeholder. Conducting Analysis of Responses. The last step is to conduct analysis of responses. Usually analysis of responses has been fixed in the earliest conjoint analysis. Three analysis methods are popular: regression-based methods, random-utility models, and hierarchical Bayesian estimation. In our method the ordinary-least-square (OLS) regression was selected because the preference judgment is an approximate interval scale and the partworths are represented as dummy variables [8]. Statistical models should be validated through hold-out samples and residual analysis. In design phase, samples are divided into two parts: modeling and validation samples. Since the residual analysis contains important and omitted information, it provides a clue for improving models.

5 Case Study In this section, we apply our method to an industry software development project1 . The client of the project wants to have a software project management system named PMCenter (Project Management System), which supports overall management activities. The PMCenter consists of project planning, monitoring, controlling, and measure analysis. Since conjoint analysis is good at revealing customer preferences on quality attributes, a conjoint study has been set up after reviewing the ATAM quality attributes and meeting customers. After looking at web-based system characteristics, five quality attributes were chosen. They are performance, usability, availability, modifiability, and security. Attributes and levels are summarized in Table 1. Since full-profile analysis, which utilizes all quality attributes instead of partial quality attributes, has the advantage that the respondent evaluates each profile holistically and in the context of all other stimuli, full-profile approach has been selected [8]. The possible scenarios from the selected attributes and levels gave rise to 48 (3×2×2×2×2=48). Since evaluating the 48 scenarios was time-consuming for customers, an experimental design method has been adopted. In order to ensure the absence of multicollinearity, an orthogonal main effects design has been adopted through SPSS ORTHOPLAN2 and 8 scenarios has been generated. Each scenario has been evaluated and ranked by a customer. Based on the defined design and customer responses, ordinary-least-square (OLS) regression model has been fitted to estimate importance of quality attributes. 1

2

ICU-CMU (Information and Communications University - Carnegie Mellon University) MSE (Master of Software Engineering) Studio Project developed a prototype system of the webbased project management system for Korea Telecom (KT). c 2004, SPSS Inc. Copyright

Quantitative Measurement of Quality Attribute Preferences

221

Table 1. Attributes and levels in the PMCenter

Atributes

Levels

Performance Usability Availability Modifiability Security

Capability, Concurrency, Processing Time Efficient Use, Proficiency/Testing Fault Tolerance, High Availability Cost of Change, Prevention of Ripple Effect Confidentiality, Integrity

Fig. 6. Importance of quality attributes

The conjoint analysis results show that the customer paid special attentions to the quality attributes of usability and modifiability, whereas availability and security are not regarded as important to the customer as summarized in Fig. 6. In addition to utilities of quality attributes, importance of quality attributes by levels provided in-depth investigation of quality attributes as shown in Fig. 7. Those findings recommended that software architect should regard the two quality attributes (usability and modifiability) as the key quality attributes to best align PMCenter architecture with customer needs. Since it is clear that what the customer wants is a web-based system with high usability and modifiability, the PMCenter project team designed architectures to maximize these quality attributes and put relatively small weight on security and availability with a palette of architecture styles and design patterns. The layered architecture combined with Model-View-Controller (MVC) pattern supported usability and modifiability compared with other architecture styles or design patterns. The component and connector view of architectural decision is shown in Fig. 8. The layered architecture combined with Model-View-Controller (MVC) pattern supported usability and modifiability. The middle tier, which is located between clients and data server provides service by getting

222

K.C. Lee et al.

Fig. 7. Importance of quality attributes according to levels

Fig. 8. PMCenter: Web-based Project Management System

request from the client and performing proper operation cooperating with data server. The processing of request of client is divided between controller and view components. View components are JSP pages that create the HTML response pages that determine the user interface when rendered by the browser. Controller components do not handle any presentation issues, but rather, process all the HTTP requests from clients. They are responsible for generating any EJB logic beans or objects used by the view components, as well as deciding, according to the user’s actions, which view component to for-

Quantitative Measurement of Quality Attribute Preferences

223

ward the request to. Controller components have been implemented as Servlet. Model components represent enterprise data and the business rules that govern access to and updates of this data. In addition, the quantitative results of conjoint analysis promoted an architectural design of high utility to the customer and facilitated communications among team members when making important design decisions.

6 Conclusion The conjoint analysis has been used in revealing customer preferences among the quality attributes for choosing appropriate architecture styles or design patterns and constructing software architecture in the web-based project management system. After conducting the ATAM process, we constructed a utility tree with stakeholders including the customer. Important quality attributes from the utility tree are in accordance with the result of conjoint analysis, viz. usability and modifiability. In addition, conjoint analysis identified interesting points. From the customer viewpoints software architect should pay special attention to prevention of ripple effects because the customer put more weights on robust software architecture, rather than concerns on rework. When adopting in commercial off-the-shelf (COTS) based software system development, it is more likely to be successful. The COTS products are dealing with mass market such that it is necessary to understand customer preference. The traditional interview method can deliver biased investigation results by selecting inappropriate samples and limited communication channels. Variants of conjoint analysis can overcome these weak points and facilitate successful COTS product development. Since conjoint analysis is relatively new in Human-Computer Interaction (HCI) and software engineering, this method has been applied in custom-built software systems. The result has shown a positive impact on quality attribute preference measurement. Conjoint analysis can be one method that enables us to develop more competitive software products by measuring customer preferences, facilitating smooth transitions, and developing high-utility products.

References 1. Addlelman, S.: Orthogonal main-effect plans for asymmetrical factorial experiments. Technometrics, Vol. 4 (1962) pp.21–46 2. Armstrong, S.: Principles of Forecasting, Kluwer Publishing (2001) 3. Churchill, G. and Lacobucci, D.: Marketing research: methodological foundations, 8/e, South-Western College Pub. (2002) 4. Garlan, D. and Shaw, M.: An introduction to software architecture, CMU/SEI-94-TR-21, ESC-TR-94-21. (1994) 5. Green, P. E. and Srinivasan, V.: Conjoint analysis in consumer research: issues and outlook, Journal of Consumer Research, Vol.5 (1978) pp.103–23. 6. Green, P. E. and Srinivasan, V.: Conjoint analysis in marketing: new development with implications for research and practice, Journal of Consumer Research, Vol.5 (1990) pp.103–23. 7. Green, P. E., Krieger, A. M., and Wind, Y.: Thirty Years of Conjoint Analysis: Reflections and Prospects, Interfaces, 31:3, Part 2 of 2 (2001) pp. S56–S73.

224

K.C. Lee et al.

8. Hauser, J. R. and Rao, V.: Conjoint analysis, related modeling, and applications. In Advances in Marketing Research: Progress and Modeling, Norwell, MA, Ed. Kluwer Academic Publishing (2004). 9. Kazman, R., Klein, M., and Barbacci, M.: The architecture tradeoff analysis method, 4th Int’l Conference on Engineering of Complex Computer Systems (ICECCS98), pp. 67–78. T Longstaff, H. Lipson, J. Corriere, Eds. IEEE Computer Society (1998). 10. Kazman, R., Klein, M., and Clements, P.: ATAM: method for architecture evaluation. Technical Report CMU/SEI-2000-TR-004, Software Engineering Institute, Carnegie Mellon University (2000) 11. Luce, R. D. and Tukey, J.: Simultaneous conjoint measurement: a new type of fundamental measurement, Journal of Mathematical Psychology (1964) pp. 1–27. 12. McFadden, D.: The choice theory approach to market research, Marketing Science Vol 5, No 4. (1986) 13. Plackett, R. L. and Burman, J. P.: The design of optimum multifactorial experiments, Biometrika, Vol. 33 (1946) pp. 305–325 14. Shaw, M. and Garlan, D.: Software architecture: perspectives on an emerging discipline, Prentice Hall, (1996) 15. Smith, D. and Merson, P.: Using architecture evaluation to prepare a large web based system for evolution, Proceedings of the 5th IEEE Int’l Workshop on Web Site Evolution, (2003) 16. Wiegers, K. E.: Software requirements, 2/e”, Microsoft Press, (2003) 17. Wittink, D. R. and Cattin, P.: Commercial use of conjoint analysis: an update”, Journal of Marketing, 53 (1989) pp. 91–96. 18. Wittink, D. R., Vriens, M, and Burhenne, W.: Commercial use of conjoint analysis in Europe: results and reflections”, International Journal of Research in Marketing, Vol. 11, (1994) pp. 41–52.

A Model-Based Design Process for Interactive Virtual Environments Erwin Cuppens, Chris Raymaekers, and Karin Coninx Hasselt University, Expertise Centre for Digital Media (EDM) and Transnationale Universiteit Limburg, Wetenschapspark 2, 3590 Diepenbeek, Belgium {erwin.cuppens, chris.raymaekers, karin.coninx}@uhasselt.be

Abstract. Nowadays, interactive systems are not limited to the desktop. On the one hand they are deployed onto handheld and embedded devices, and on the other hand they evolve into interactive virtual environments which are controlled by direct manipulation interaction techniques. However, the development of these virtual environment user interfaces is not a straightforward process and thus not easily accessible for non-programmers. In this paper, we envision a model-based design process for these highly interactive applications, in order to bridge the gap between the designer and the programmer of the application. The process is based on both requirements of model-based user interface developments processes, and virtual environment development tools and toolkits. To evaluate the envisioned approach, a tool was created that supports the described process, and a case study has been performed.

1 Introduction Virtual Environments are computer generated three-dimensional environments that create the effect of an interactive world in which the user is immersed. For several years our lab has performed research on interaction techniques within these environments and for this purpose several virtual environment applications have been developed that support the use of various interaction techniques. Although Interactive Virtual Environments (IVEs) offer a lot of advantages, the use of these applications is not very widespread. There are several possible reasons for this, including the fact that the development process of an IVE is not easily accessible for non-specialists. In order to investigate alternative methods to facilitate the development of IVEs, we initiated the VR-DeMo project (Virtual Reality: Conceptual Descriptions and Models for the Realization of Virtual Environments). Within this project we elaborate on the possible use of conceptual modelling and high-level interaction descriptions in the IVE design process. We believe that the introduction of a conceptual level will facilitate the development of IVEs for programmers as well as designers. In this paper we propose a model-based approach for the development of IVEs. Nowadays, model-based techniques are mainly used in multi-device user interface (UI) development processes. The description of a UI by means of declarative models offers three major advantages [16]: S.W. Gilroy and M.D. Harrison (Eds.): DSVIS 2005, LNCS 3941, pp. 225–236, 2006. c Springer-Verlag Berlin Heidelberg 2006 

226

E. Cuppens, C. Raymaekers, and K. Coninx

1. The models provide an abstract description of the UI. 2. The models facilitate the creation of methods to design and implement the UI systematically. 3. The models provide the infrastructure required to automate the UI design and implementation processes. We believe that the advantages of model-based design can aid in bridging the gap between the application programmers and the IVE designers because the IVE can be described in a way that is abstracted from its implementation. The majority of the current Model-Based User Interface Development (MBUID) tools focus on topics such as WIMP and speech interfaces. Because of these specific points of interest, most tools are limited to dialog and web-based user interfaces and do not elaborate on direct manipulation techniques. In contrast, user interfaces for IVEs typically focus on the topic of direct manipulation, since interaction mostly happens by means of one (or more) specific interaction techniques or metaphors. Because of these differences, we have to examine which of the existing models or algorithms are useful for the model-based design of IVEs. In the remainder of this paper we will elaborate on the envisioned model-based design process. First, an overview of some MBUID environments and processes will be given, followed by a discussion of several existing VE development tools and toolkits. Afterwards we will describe the analysis that was made in order to gather the requirements necessary for model-based design of an IVE. Once the most important requirements had been determined, they were used to specify a model-based design process that has benefits of both development approaches. Finally this process has been implemented within a tool, called CoGenIVE (Code Generation for Interactive Virtual Environments). Evaluation of CoGenIVE will be done using a case study in which a virtual shop will be designed and generated. An overview of the tool and the case study is given in Sect. 4. We will conclude our paper by analyzing the result of the case study and present ongoing work in Sect. 5.

2 Model-Based IVE Development: The Requirements Before we could specify a model-based design process and develop a code-generation tool to facilitate this process, it was of great importance to determine the requirements necessary for the process and the supporting tool. Since we tried to combine two different development approaches, namely MBUID and the toolkit-based development of IVEs, we had to examine both the MBUID processes and tools, and the virtual environment development tools and toolkits. The results of this analysis are presented in this section. Based on the advantages and properties of the examined tools and processes, we determined the requirements necessary to specify our design process and development tool. 2.1 Model-Based User Interface Design Processes and Tools Although several MBUID environments exist, most of these tools focus on different topics and use alternative design processes.

A Model-Based Design Process for Interactive Virtual Environments

227

A first process is defined within the Cameleon Reference Framework [3]. This framework defines UI development steps for multi-context interactive applications. The process contains four steps, starting from tasks and concepts, evolving via abstract and concrete UIs into the final user interface. After each step the user is able to manipulate any of the generated artefacts. Originally, the Cameleon framework was created by Coutaz et al. in order to specify plasticity of user interfaces [2], but nowadays several other projects such as UsiXML [20], a user interface description language for the specification of multimodal user interfaces, also make use of the framework. The TERESA tool [14] developed by Patern`o et al. is also based on the Cameleon framework and focusses on the development of multi-device user interfaces. The process used in the TERESA tool is described as One Model, Many Interfaces. This means the design process starts with an abstract description of the tasks the interactive system has to support, and gradually transform the descriptions into different concrete user interfaces. In particular, the process starts with a task model and through a number of transformations the specific interface for each of the different devices is generated. The goal of DynaMo-AID [4] developed by Clerckx et al. is the development of context-sensitive multi-device user interfaces. DynaMo-AID uses a process elaborating on the Dygimes framework [13]. Similar to the process used by the TERESA tool, DynaMo-AID starts from a task model representing tasks for different contexts of use, in particular the ConcurTaskTree notation [15]. The first step in the process is extracting the different task sets and derive the dialog model from them. The following step is the generation of an abstract UI out of the task sets and the generated dialog model. This abstract UI will be converted into a concrete UI when the interface is deployed on the target device. Mobi-D [18] is a highly interactive development environment that starts with a usertask elicitation stage and offers testing possibilities for the generated user interfaces. The user-task elicitation exists of an informal task description that evolves into a formal task outline with help from the designer. Next, the developer starts interacting with Mobi-D in order to create the user-task and domain model. In the following step the presentation and dialog model are defined and finally a prototype of the UI will be created. Once generated, Mobi-D aids in the evaluation of the generated prototype interfaces. Although model-based design processes have proven their value in dialog or webbased interfaces, none of these seems to be directly usable in order to design interaction within a VE. Highly interactive interfaces, like an IVE, contain several direct manipulation techniques and are therefore not considered. The overview of these design processes however, shows several common properties which we will take into account in our own design process. Each process starts with a task related model and evolves towards the final user interface using an incremental approach. After each step in the design process, the designer has the possibility to modify the generated artefacts manually. One property that was not really emphasized but nevertheless is very important, is the fact that the process should be iterative in order to easily alter, regenerate and evaluate a prototype UI. Finally, it is essential that manual changes from the designer are preserved when the user interface is regenerated.

228

2.2

E. Cuppens, C. Raymaekers, and K. Coninx

VE Development Tools and Toolkits

We are aware that several tools and toolkits to facilitate the IVE design process already exist, but the number of processes particularly conceptualized for the entire development of an IVE is rather limited. We believe several reasons exist to explain this scarcity. For example, the complexity of interaction in a VE, the wide variety of input and output techniques, the lack of suitable standard notations. One approach trying to support the design of IVEs is the Marigold toolset [21]. The focus of the process lies in the systematic design, evaluation and refinement of interaction techniques by means of extensive visual tool support. The Marigold toolset consists of two tools: the Hybrid Specification Builder, in which the designer can specify interaction techniques using the Flownets notation [19]; and the Prototype Builder, in which parts of code can be specified in order to support different devices, and provide interaction with world objects. Although the process appears to resolve several issues concerning the design of interaction techniques, it also raises some questions. At first, describing interaction using the Flownets notation is no straightforward process and the diagram tends to become very large, even for rather simple interaction metaphors. A second issue concerns the usability of the Prototype Builder for non-programmers since it requires code editing and uses concepts such as input and output variables. Nowadays, standardization in the field of IVE development is limited to file formats, such as VRML and X3D. Because of the lack of standards concerning interaction techniques and development methodologies, there is a wide variety of toolkits, all trying to facilitate the development of these applications. Most existing toolkits are programming API’s, concentrating on the technical details of the application and in most cases focussing on specific development issues. As a result, most toolkits are not easily accessible for non-programmers. CaveLib [6] is a low-level API, used for the creation of VR-applications in projection based set ups. CaveLib especially aims at multi-display and network applications and thus offers no direct support for any specific scene graph technology. VRJuggler [7] is a more high-level approach to develop and run VR-applications. It is an open source platform that introduces a software layer between the application and the device interface to provide a hardware-independent programming API. By means of a graphical user interface, the designer can combine code-blocks (chunks) in order to use input and output devices in his application (which has to be coded by hand). The chunks that are available within VRJuggler contain several functionalities (e.g., scene graph technology, openGL output, input with the 3D mouse or other input devices, CAVE support, tracking). The OpenManip framework [1] provides support for direct object manipulation techniques such as selection and manipulation of scene objects, independent of the underlying scene graph technology. Alice [5] offers an alternative for these technical toolkits is. It is a graphical programming environment, solely for the creation of IVE simulators. The created simulations use the DIVER platform as a rendering engine and device handler. Because of its graphical notation, even environment designers without any programming experience can use Alice in order to create a virtual scene containing some basic animations. More complex behavior can be accomplished by means of Python scripting.

A Model-Based Design Process for Interactive Virtual Environments

229

In contrast with the MBUID tools described in Sect. 2.1, the presented toolkits do not immediately show common characteristics. Kulas et al. identified several research challenges concerning the development of virtual and augmented reality development tools and design processes [12]. The most important issue concerning the development tools is the wide variety of existing toolkits, each focusing on a specific part of the final application. Combining several toolkits is not straightforward since the output of one tool can, in most cases, not be used as input for another tool. Therefore, it is important that several design issues can be integrated within the same tool. Challenges concerning the design process are the specification of a formal process and the possibility of rapid prototyping in order to experiment with different variations of the UI in quick succession. 2.3 Selected Requirements When combining the advantages and requirements of both design processes and development tools, we achieve the following specifications for our model-based design process and the supporting tool: Selected Requirement 1. The process should evolve incrementally, from an abstract (user-task) description and high-level models into a concrete interface and low-level code. Selected Requirement 2. The process should be iterative: once a prototype UI has been generated and evaluated, the designer should be able to alter the models and regenerate the interface. Selected Requirement 3. Since an IVE consists of several direct manipulation techniques, it should be possible to design these interaction techniques by means of an additional description model. In the remainder of this paper we will refer to these description models as Interaction Description Models. Selected Requirement 4. In order to be useful for non-programmers, the process should automatically generate the code for the described IVE. Selected Requirement 5. When the code is regenerated after certain models have been altered, it is essential that manually edited code is preserved. Selected Requirement 6. In order to be useful, graphical tool support and assistance should be offered in order to design the high-level description models and check their correctness.

3 Model-Based IVE Development: The Process Based on the requirements gathered in Sect. 2, we propose a model-based approach for the design and development of IVEs. The process is based on some existing models and algorithms which are adapted in order to support the direct manipulation and interaction techniques that are typical for IVEs. In this section, our envisaged design process will be described and Sect. 4 will present a tool developed in order to support the proposed process.

230

E. Cuppens, C. Raymaekers, and K. Coninx

Fig. 1. Envisaged design process

A schematic overview of our process is shown in Fig. 1. The first step is the creation of a task model of our IVE. This Task Model is done by means of the ConcurTaskTree (CTT) notation [15] (as shown in the top-left part of Fig. 1). The CTT notation, elaborated by Patern`o, is a widely used notation which uses a graphical syntax and offers both a hierarchical structure and support to specify temporal relations between tasks. Four types of tasks are supported in the CTT notation: 1. Application tasks—tasks completely executed by the application. 2. User tasks—tasks performed by the user; usually they are important cognitive activities. 3. Interaction tasks—tasks performed by the user interacting with the system by some interaction techniques. 4. Abstract tasks—tasks which require complex activities whose performance cannot be unequivocally allocated.

A Model-Based Design Process for Interactive Virtual Environments

231

Sibling tasks at the same level in the hierarchy of decomposition can be connected by temporal operators (e.g., choice ( [] ), enabling ( >> ), disabling ( [> ) ). Since we are designing Interactive Virtual Environments, we will concentrate on the interaction tasks within the application. A possible example of an interaction task in the leaf-nodes of a CTT is object selection. In a 2D user interface this is a straightforward task in which the user selects an item from a given list by means of a mouse. In an IVE however, this task becomes more challenging since the interaction techniques in a virtual environment are not limited to keyboard and mouse input. Several well-known selection techniques are grabbing, ray-casting and gogo-selection [17]. Because of the complexity of most interaction tasks in 3D environments, we propose the usage of a graphical notation to describe these interaction techniques in more detail. Attaching these Interaction Description Models (IDM) to an interaction task in the CTT has two advantages. Firstly, the design process of the IVE becomes more flexible since an IDM offers the possibility of altering the used interaction technique for an interaction task, without having to adapt the task model or any other model in the design process. A second advantage results from the fact that by using an IDM to define specific interaction tasks, the design of a task model for an IVE becomes similar to that of a 2D user interface. Once the task model is designed, the algorithm described by Luyten, et al.[13] can be used to automatically extract the application’s Dialog Model from the CTT. The dialog model is based on the enabled task sets which are derived from the application’s task model. An Enabled Task Set [15] (ETS) is defined as: ”a set of tasks that are logically enabled to start their performance during the same period of time”. The resulting ETSs can be mapped onto the different application states, containing all interaction tasks that can be executed in that state. The transitions between the application states are the same as those in the state transition network that represents the dialog model. After the dialog model is extracted, the different states of the application are connected to the interaction techniques, defined by the IDMs. Further, the designer has to merge the dialog model with the Presentation Model. In our process, the presentation model is represented by VRIXML, a description language used to specify interface elements for the resulting IVE. A small extract of a VRIXML menu is shown in Fig. 1. More examples and a motivation for the creation of this user interface description language can be found in [8]. Once the entire design process is completed, the specified models are used to automatically generate a runtime binary of the virtual environment application. In addition, the process generates some repository files that can be interpreted by the application at runtime. These repository files offer more flexibility and typically contain descriptions of the user interface elements (VRIXML files) in order to alter them even after the application is generated. One of the selected requirements, determined in Sect. 2 was “In order to be useful, graphical tool support and assistance should be offered in order to design the high-level description models and check their correctness”. To fulfill this requirement we created a development environment that supports the design process that was described in this section. The functionalities of this tool, together with a case study, will be presented in Sect. 4.

232

E. Cuppens, C. Raymaekers, and K. Coninx

4 Model-Based IVE Development: Tool Support In order to assess the practical use of the envisaged approach, presented in Sect. 3, we started with the development of a design tool, called CoGenIVE (Code Generation for Interactive Virtual Environments). This tool has been used to develop a case study, called VirtuaShop. The VirtuaShop application contains several states in which the user can navigate through the shop, select and drag objects into his shopping cart and check the properties of the products by means of the user interface elements. The process that has been presented in section 3 describes an incremental top-down design and development process for IVE applications (Sel. Req. 1). The implementation of the presented approach for the realization of virtual environments is based on an event-driven framework that has been presented by De Boeck et al. [9]. This bottom-up approach allows gradual extension of the tool with additional high-level descriptions and models, while a basic version of the tool covers essential design development steps such as code generation. As stated in the requirements gathered in Sect. 2 it is highly recommended to provide graphical tool support for a description language or model. In particular, when creating the Presentation Model, the graphical design of user interface elements is supported by CoGenIVE. Within the tool it is possible to draw the interface elements while the result is automatically saved in the VRIXML file-format (Sel. Req. 6). The use of VRIXML offers more flexibility to the application designer since it becomes possible to alter the design and behavior of the user interface elements after the application has been created. In Fig. 2, a menu and a dialog are shown that are described by means of VRIXML. Following the design of the presentation model, we extended CoGenIVE with the Dialog Model. Using this model, the designer can specify the different program states, the possible transitions between these states and the tasks available to the user in each of the states. The designer can also attach one of the created user interface elements to each of the states. Figure 3 shows the state transition network that represents the VirtuaShop application. The application contains four modes and several of these modes have a user interface element attached to them in order to provide the necessary interaction.

Fig. 2. VRIXML user interface elements

A Model-Based Design Process for Interactive Virtual Environments

233

Fig. 3. VirtuaShop States (dialog model) and the connected UI elements (presentation model)

The next step in the development of our tool was supporting the Code Generation Process, based on the models (Sel. Req. 4). The generated application code is built upon an event-driven framework and it is possible to execute the application without further code editing. However, it is likely that the application developer has to perform some minor changes or add some application specific code. These adjustments can best be done with traditional software development tools and in order to support these post-generation adjustments, CoGenIVE generates a MS Visual C++ project file that can be used for further development. In order to support an iterative design process (Sel. Req. 2), we designed the tool in such a way that manual code changes are preserved whenever a model is updated and the application is regenerated (Sel. Req. 5).

5 Preliminary Results and Ongoing Work The size of the VirtuaShop application is about 2500 lines of code of which 2000 lines are generated fully automatic. The other 500 lines contain the implementation of the interaction technique, certain dialog behavior and the implementation of the application specific tasks. The design of the application (requirements analysis, discussion and creation of the models in CoGenIVE) took about half a day and the manual implementation and debugging of the application details took another day and a half. So, in total the creation of the VirtuaShop application took about two days. In contrast, the development of such an application without the CoGenIVE tool could easily take up to two weeks. In Fig. 4, screenshots of CoGenIVE, as well as the generated VirtuaShop application, are shown 1 . The application shows a shop product being dragged into the shopping cart. Since specification of interaction techniques is not yet supported by CoGenIVE, we had to implement them by hand. The majority of this code, however, will also be generated, once a suitable Interaction Description Model is developed and integrated within CoGenIVE (Sel. Req. 3). 1

More screenshots and demonstration videos can be found at http://research.edm.uhasselt.be/ ecuppens/CoGenIVE/

234

E. Cuppens, C. Raymaekers, and K. Coninx

Fig. 4. VirtuaShop and CoGenIVE

Currently, we are evaluating some existing notations like InTml [11], ICon [10] and Statecharts, in order to find a notation that can serve as an Interaction Description Model. In addition, we are extending CoGenIVE by integrating the ConcurTaskTree notation and the dialog model extraction algorithm described by Luyten et al. [13].

6 Conclusions In this paper we have presented a model-based approach for the design of Interactive Virtual Environments, as well as the development of a tool that supports the envisioned design process. The tool, called CoGenIVE, is developed while keeping in mind several requirements that are typical for existing model-based design processes and VR tools or toolkits. As a case study for the tool we designed an interactive virtual shop. Early evaluations of CoGenIVE by means of VirtuaShop have shown that a large part of the application code can already be generated automatically based on the dialog and the presentation model of the application. The current version of CoGenIVE already meets most of the determined requirements but in order to maximize the amount of generated code some requirements still have to be implemented.

Acknowledgments Part of the research at EDM is funded by EFRO (European Fund for Regional Development), the Flemish Government and the Flemish Interdisciplinary institute for Broadband technology (IBBT). The VR-DeMo project (IWT 030284) is directly funded by the IWT, a Flemish subsidy organization. The authors would like to thank Tom De Weyer for his valuable contribution in the development of CoGenIVE and Tim Clerckx for his input on model-based user interface development techniques.

A Model-Based Design Process for Interactive Virtual Environments

235

References 1. Michael Braitmaier, Manfred Weiler, and Thomas Ertl. Openmanip: An extensible crossscene-graph framework for direct object manipulation. In Proceedings of Eurographics Partner Event OpenSG 2003 - Concepts and Components of Software Frameworks for Interactive 3D Graphics, pages 65–72, Darmstadt, Germany, April 1–2 2003. 2. Gaelle Calvary, Jo¨elle Coutaz, and David Thevenin. A unifying reference framework for the development of plastic user interfaces. In Murray Reed Little and Laurence Nigay, editors, EHCI, volume 2254 of Lecture Notes in Computer Science, pages 173–192, Toronto, Canada, May 10–14 2001. Springer. 3. Gaelle Calvary, Jo¨elle Coutaz, David Thevenin, Quentin Limbourg, Laurent Bouillon, and Jean Vanderdonckt. A unifying reference framework for multi-target user interfaces. Interacting with Computers, 15(3):289–308, 2003. 4. Tim Clerckx, Kris Luyten, and Karin Coninx. Dynamo-AID: a design process and a runtime architecture for dynamic model-based user interface development. In Pre-Proceedings of EHCI-DSVIS’04, pages 142–160, Tremsb¨uttle Castle, Hamburg, Germany, July 11–13 2004. 5. Conway, Pierce, Pausch, Steve Audia, Tommy Burnette, Dennis Cosgrove, Kevin Christiansen, Rob Deline, and et al. Alice: Lessons learned from building a 3D system for novices. In Proceedings of CHI’2000, pages 486–493, The Hague, The Netherlands, April 1–6 2000. 6. C. Cruz-Neira. Virtual Reality Based on Multiple Projection Screens: The CAVE and its Applications to Computational Science and Engineering. PhD thesis, University of Illinois, Chicago, May 1995. 7. C. Cruz-Neira, A. Bierbaum, P. Hartling, C. Just, and K. Meinert. Vr juggler - an open source platform for virtual reality applications. In 40th AIAA Aerospace Sciences Meeting and Exhibit 2002, Reno, Nevada, January 2002. 8. Erwin Cuppens, Chris Raymaekers, and Karin Coninx. VRIXML: A user interface description language for virtual environments. In Developing User Interfaces with XML: Advances on User Interface Description Languages, pages 111–117, Gallipoli, Italy, May 2004. 9. Joan De Boeck, Chris Raymaekers, Erwin Cuppens, Tom De Weyer, and Karin Coninx. Taskbased abstraction of haptic and multisensory applications. In Proceedings of EuroHaptics 2004, pages 174–181, Munchen, DE, 2004 June 5–7. 10. Pierre Dragicevic and Jean-Daniel Fekete. Input device selection and interaction configuration with ICon. In Ann Blanford, Jean Vanderdonckt, and Phil Gray, editors, Proceedings of IHM-HCI 2001, pages 443–448, Lille, France, 2001. Springer-Verlag. 11. Pablo Figueroa, Mark Green, and James H. Hoover. InTml: A description language for VR applications. In Proceedings of Web3D 2002, pages 53–58, Tampe, Arizona, USA, February 24–28 2002. 12. Christian Kulas, Christian Sandor, and Gudrun Klinker. Towards a development methodology for augmented reality user interfaces. In Emmanuel Dubois, Philip D. Gray, Daniela Trevisan, and Jean Vanderdonckt, editors, MIXER, volume 91 of CEUR Workshop Proceedings, 2004. 13. Kris Luyten, Tim Clerckx, Karin Coninx, and Jean Vanderdonckt. Derivation of a dialog model from a task model by activity chain extraction. In Joaquim A. Jorge, Nuno Jardim Nunes, and Jo˜ao Falc˜ao e Cunha, editors, Interactive Systems: Design, Specification, and Verification, volume 2844 of Lecture Notes in Computer Science, pages 191–205. Springer, 2003. 14. Giulio Mori, Fabio Patern`o, and Carmen Santoro. Design and development of multidevice user interfaces through multiple logical descriptions. IEEE Transactions On Software Engineering, 30(8):1 – 14, August 2004.

236

E. Cuppens, C. Raymaekers, and K. Coninx

15. Fabio Patern`o. Model-Based Design and Evaluation of Interactive Applications. Springer, 1999. 16. Paulo Pinheiro da Silva. User interface declarative models and development environments: A survey. In Interactive Systems: Design, Specification, and Verification, pages 207–226, Limerick, Ireland, UK, June 5–6 2000. 7th International Workshop, DSV-IS 2001, SpringerVerlag. 17. I. Poupyrev, S. Weghorst, M. Billinghurst, and T. Ichikawa. Egocentric object manipulation in virtual environments: Empirical evaluation of interaction techniques. In Proceedings of EuroGraphics 1998, Lisbon, Portugal, August 31 – September 4th 1998. 18. Angel R. Puerta. A model-based interface development environment. IEEE Software, 14(4):40–47, 1997. 19. Shamus Smith and David Duke. The hybrid world of virtual environments. Computer Graphics Forum, 18(3):297–308, September 1999. 20. Jean Vanderdonckt, Quentin Limbourg, Benjamin Michotte, Laurent Bouillon, Daniela Trevisan, and Murielle Florins. UsiXML: a user interface description language for specifying multimodal user interfaces. In Proceedings of W3C Workshop on Multimodal Interaction 2004, Sophia Antipolis, France, July 19–20 2004. 21. James Willans and Michael Harrison. A toolset supported approach for designing and testing virtual environment interaction techniques. International Journal of Human-Computer Studies, 55(2):145–165, August 2001.

Mapping ConcurTaskTrees into UML 2.0 Leonel Nóbrega1, Nuno Jardim Nunes1, and Helder Coelho2 1

Department of Mathematics and Engineering, University of Madeira, Campus da Penteada, 9000-390 Funchal, Portugal {lnobrega,njn}@uma.pt 2 Department of Informatics of the Faculty of Sciences, University of Lisbon, Bloco C6, Piso 2, 1749-016 Lisboa, Portugal [email protected]

Abstract. ConcurTaskTrees (CTT) is one of the most widely used notations for task modeling, specifically tailored for user interface model-based design. The integration of CTT with a de facto standard modeling language was already identified as an important issue, but there is no consensus about the best approach to achieve this goal. The purpose of this paper is to examine the relative strengths and weaknesses of control and data flow specification in UML 2.0 Activity Diagrams to represent CTT semantics. The analysis is driven by the definition of pattern-based activities for the temporal operators in CTT. In this paper, we propose an extension of the UML 2.0 abstract syntax that fully supports the concepts behind CTTs and provides an adapted graphical notation for a UML-like representation.

1 Introduction Task modeling is a central and familiar concept in human-computer interaction (HCI) but it is seldom used in object-oriented software engineering (OOSE). A task model details users’ goals and the strategies adopted to achieve those goals, in terms of actions that users perform, the objects involved in those actions and the underlying sequencing of activities [1]. Task models capture the dialog model of interactions and are crucial for enabling model-based approaches for building interactive systems. The UML insufficiencies for interaction design are widely recognized [2, 3] and the integration of task model represent a step further in its limitations. The ConcurTaskTree notation, is one of the most widely used notations for task modeling, specifically tailored for model-based user interface design and its integration with UML has been already identified as a desirable goal. Integrating CTT with UML can be generally achieved through the following approaches: − Using the UML extension mechanisms (profiles), to represent elements and operators of a CTT model by an existing UML notation. − Extending the UML metamodel, introducing a separate user task model, and establishing relationships between the CTT elements and existing UML elements. The first solution is feasible and was already proposed in [2]. This approach represents CTT as stereotyped class diagrams. Constraints associated with UML class, S.W. Gilroy and M.D. Harrison (Eds.): DSVIS 2005, LNCS 3941, pp. 237 – 248, 2006. © Springer-Verlag Berlin Heidelberg 2006

238

L. Nóbrega, N.J. Nunes, and H. Coelho

association and dependency stereotypes are defined to enforce the structural correctness of the CTT models. The major drawbacks to this proposal are the expressiveness of the notation and the semantic validation of the CTT temporal constraints in terms of UML class diagrams. The second solution is outlined in [3] and covers the definition of UML for Interactive Systems. The approach proposed describes the integration points between UML models and task models in a complementary way. Yet, a unified integration at the semantic and notational levels should be provided in order for an effective incorporation of task models into UML. In this paper we propose a different approach that enables the integration of CTT with UML through the extensions of UML 2.0 activity diagrams. Our approach takes advantage of the new characteristics of the UML 2.0 semantics, in particular the separation of statecharts and activity diagrams, which enables a better definition of the temporal operators underlying CTT, without compromising the usability of the notation. We strongly believe the enhancements in the UML 2.0 activity diagrams, finally enabled an effective integration of CTT into UML. The solution presented here could provide a common ground for effectively bringing task modeling into software engineering, promoting artifact interchange between tools and practitioners in SE and HCI. The paper is organized as follows. Sections 2 and 3 briefly introduce ConcurTaskTrees and UML 2.0 Activity diagrams. Section 4 reports the evaluation of UML Activities Diagrams to express CTT semantics. Section 5 presents an extension of UML abstract syntax in order to support CTT concepts and the underlying notation. Finally, Sect. 6 concludes the paper.

2 Overview of ConcurTaskTrees ConcurTaskTrees is a notation that has been developed by taking into account the previous experience in task modeling and adding new features in order to obtain an easy-to-use and powerful notation to describe the dialogue in interactive systems. CTTs are based on a graphical notation that supports the hierarchical structure of tasks, which can be interrelated through a powerful set of operators that describe the temporal relationships between subtasks. The formal semantics of the temporal relationships in CTT are defined using Labeled Transition System (LTS) formalism. In addition, CTTs allow designers to indicate a wide set of optional task attributes, such as category (how the task performance is allocated), type, manipulation of objects, frequency, and time requested for performance. The CTT notation is supported by CTTE (the ConcurTaskTrees Environment), a set of freely available tools supporting editing and analysis of task models. The CTT notation is widely recognized as one of the most popular task notations in the HCI field, it is used for teaching and research purposes in several universities, and there is also evidence of usage in development projects. The CTT environment includes a simulator and a number of features enabling, for instance, designers to dynamically adjust and focus their attention on subsets of large task models, while analyzing large specifications.

Mapping ConcurTaskTrees into UML 2.0

239

Figure 1 illustrates a simple task model in CTT (provided in CTTE distribution). As we can see from the example, task models are represented in CTT as inverted trees (the task structure); each task can differ in type (user task, interactive task, abstract task and system task). The temporal relationship between subtasks at the same level is represented through lines annotated with the different temporal relationships. For a full description of CTT refer to [4].

Fig. 1. Example of a ConcurTaskTree

3 Overview of UML 2.0 Activity Diagrams Since the early versions of the standard, UML adopted Harel statecharts as the key notation to represent the dynamical aspects of software intensive systems. In addition, the UML 1.x versions also included activity diagrams, defined as a subset of statecharts. Activity diagrams have since become one of the key diagrams of the UML, in particular for business process modeling and user modeling [5]. Recognizing the problems with UML 1.x activity diagrams, in UML 2.0, activities where redesigned to follow “Petri-like” semantics thus separating activity diagrams from statecharts. Among other benefits, this widens the number of flows that can be modeled, especially those that have parallel flows of control [6]. The fundamental unit of behavior specification of an Activity Diagram is an Action. An action takes a set of inputs and converts them to a set of outputs, although either or both sets may be empty. There are three types of actions, namely: 1. Invocation Actions, used for performing operations calls, signal sending and accept event actions. 2. Read and Write Actions, for accessing and modifying objects and their values. 3. Computation actions, transforming input values into output. Besides actions, an activity diagram can also contain control nodes, object nodes, activity edges and activity groups. In Fig. 2 we represent a subset of the UML 2.0 activity diagram notation, which is of particular interest to the discussion in this paper.

240

L. Nóbrega, N.J. Nunes, and H. Coelho

Among the possible activity groups we highlight the Interruptible Activity Region due to its intensive use in this paper. This type of group is described as an activity group that supports termination of tokens flowing in the portions of an activity [6]. The termination of all tokens occurs when a token leaves an interruptive region via an interrupting edge. A token transition is never partial; it is either complete or it does not happen at all [6].

Fig. 2. UML 2.0 notation for Activity Diagrams

4 Mapping CTT into UML 2.0 Activity Diagrams The analysis of the UML activity diagrams to represent CTT semantics is provided in terms of the behavior obtained by applying a temporal operator between two tasks. For the purpose of the evaluation of the approach described in this paper, one can consider atomic tasks (i.e., tasks that are not refined into subtasks) or composed tasks (resulting from application of temporal operators to subtasks). We highlight these definitions because they are slightly different from the original concepts in CTT. A CTT task is either an atomic task or the task resulting from applying a full sequence of operators to all sibling tasks. Furthermore, the composition of tasks (via temporal operators) requires a definition of starting and terminating conditions of composed tasks. For instance, in the following sequence T1|=|T2>>T3, the T3 task only becomes enabled either after termination of the T1 or T2 tasks (depending upon the selected order). This particular type of dependency between tasks implies that we have to express the start and termination of composed tasks in terms of the start and termination of the tasks being composed. In our UML 2.0 based approach we use signals to control the aforementioned conditions. We assume that an atomic task signals its own start and termination of execution. Hence, the composition of tasks must take into account the precedence of temporal operators. For instance, the sequence T1|||T2[>T3 must be considered as (T1|||T2)[>T3 and not as T1|||(T2[>T3). To prevent this problem, we consider the following sequence of operator precedence: >>, [>, |>, |||, |=|, [].

Mapping ConcurTaskTrees into UML 2.0

241

In our UML 2.0 approach, a CTT task is mapped into an Action, if it is atomic, and into a Call Behavior Action, otherwise. Finally, from the UML 2.0 semantics, a task is enabled if it possesses a token and is otherwise disabled. In the following subsections we examine the UML semantics for each CTT temporal operator. All the operators descriptions used were taken from [7]. 4.1 Independent Concurrency ( T1 ||| T2 ) Description. Actions belonging to two tasks can be performed in any order without any specific constraint. Proposed UML 2.0 mapping. The independent concurrency is captured by a Fork node to create two independent flows of control for each task and a Join node to synchronize them. The start of the composed task T1|||T2 corresponds either to the start of T1 or of T2. This condition could be modeled using two Accept Event actions for the start signals of T1 and T2 and, once one of these actions succeeds, a signal Start T1|||T2 is produced, through a Send Signal action. An interruptible region is necessary because only one signal must be produced. The termination of the composed task occurs when both tasks signal their termination and must wait for both signals before sending a signal that corresponds to the termination of task T1|||T2.

Fig. 3. UML specification for Independent Concurrency temporal operator

4.2 Choice ( T1 [] T2 ) Description. It is possible to choose from a set of tasks and, once the choice has been made, the task chosen can be performed; the other tasks are not available at least until the chosen task has been terminated. Proposed UML 2.0 mapping. In this case both tasks must be enabled at the beginning but once one of them starts its execution the other must be disabled. This can

242

L. Nóbrega, N.J. Nunes, and H. Coelho

Fig. 4. UML specification for Choice temporal operator

modeled using an interruptible region with the task and an Accept Event action for the Start signal of the other task. Using this strategy we ensure that only one task is executed. The start of T1[]T2 occurs when one of the tasks sends its Start signal (only one Start signal will be produced). The same occurs with the task termination. In Fig. 4, two Accept Event actions are used to signal Start T1 (and also to signal Start T2). In fact both signals should be considered as only one. This simplification is adopted here and in the following figures, in order to increase the readability of the diagrams. 4.3 Concurrency with Information Exchange ( T1 | [] | T2 ) Description. Two tasks can be executed concurrently but they have to synchronize in order to exchange information. Proposed UML 2.0 mapping. The solution is identical to the one presented for the independent concurrency operator. Additionally, a Central Buffer node must be used for information exchange purposes. 4.4 Order Independence ( T1 | = | T2 ) Description. Both tasks have to be performed but when one is started then it has to be finished before starting the second one. Proposed UML 2.0 mapping. The solution for this operator is similar to the choice operator. The difference is that when a task is disabled (due to the execution of the other), we must wait for the termination of the execution, before enabling the task again. Moreover, both tasks must be executed before the send of Finish T1|=|T2 signal.

Mapping ConcurTaskTrees into UML 2.0

243

Fig. 5. UML specification for Order Independent temporal operator

4.5 Deactivation ( T1 [> T2 ) Description. The first task is definitively deactivated once the first action of the second task has been performed. Proposed UML 2.0 mapping. If task T1 executes normally, T2 must be disabled after the completion of task T1. This case is ensured by grouping task T2 and an Accept Event action for Finish T1 signal in an interruptible region. The other case, when T2 aborts the execution of T1, is modeled using an interruptible region and an Accept Event action for Start T2 signal. Thus, if T2 starts its execution T1 will be interrupted. The start of T1[>T2 corresponds to the start of T1 or the start of T2 without starting T1. The termination corresponds to the termination of one of the two tasks. 4.6 Enabling ( T1 >> T2 ) Description. In this case one task enables a second one when it terminates. Proposed UML 2.0 mapping. In this case a control flow is used to connect both tasks. The start of T1>>T2 corresponds to the start of T1 and the termination corresponds to the termination of T2.

244

L. Nóbrega, N.J. Nunes, and H. Coelho

Fig. 6. UML specification for Deactivation temporal operator

Fig. 7. UML specification for Enabling temporal operator

4.7 Enabling with Information Passing ( T1 []>> T2 ) Description. In this case task T1 provides some information to task T2 other than enabling it. Proposed UML 2.0 mapping. Similar to the enabling operator, assuming, in this case, an object flow between tasks T1 and T2. 4.8 Suspend-Resume ( T1 |> T2 ) Description: This operator gives T2 the possibility of interrupting T1 and when T2 is terminated, T1 can be reactivated from the state reached before the interruption. Proposed UML 2.0 mapping: There is no evidence in the UML 2.0 specification that any behavior supports the resume functionality. Therefore, this operator is not supported by existing UML semantics.

Mapping ConcurTaskTrees into UML 2.0

245

4.9 Iteration ( T* ) Description. The task is performed repetitively. Proposed UML 2.0 mapping. This unary operator has a straightforward mapping in UML. The Start signal occurs at first execution of task T1 and a flow loop is created for task T1.

Fig. 8. UML specification for Iteration operator

4.10 Finite Iteration ( T1(n) ) Description. It is used when designers know in advance how many times a task will be performed. Proposed UML 2.0 mapping. A finite iteration can be mapped into UML using a local variable for counting the iterations. The start of the iteration begins with the first execution of task T1 and termination is signaled after n occurrences of the Finish T1 signal. We use in this case an exception rule to the normal execution in Activities—if an AcceptEventAction has no incoming edges, then the action starts when the containing activity or structured node does. In addition, an AcceptEventAction with no incoming edges is always enabled to accept events, no matter how many such events it accepts [6].

Fig. 9. UML specification for Finite Iteration operator

246

L. Nóbrega, N.J. Nunes, and H. Coelho

5 An UML Notation for ConcurTaskTrees In the previous section we described how the new UML 2.0 standard can successfully support the CTT semantics by taking advantage of the redesigned activity diagrams. However, even a simple task tree results in very complex sets of activities with a remarkable number of actions and control nodes. This is a well-known problem with statechart-like notations: they become unreadable as the number of states increases. Although semantically correct, the previously described UML mappings to the CTT temporal operators will be completely useless even for a simple task model. This was one of the major problems with the previous proposals to map CTTs into the UML: in order to propose a useful solution to the mapping of temporal relationships one would compromise the semantic correctness and the other way around. The existing graphical representation for CTTs, based on a hierarchical structure, is one of the most significant factors of its success. The hierarchical structure reflects the logical approach of most designers, allowing the description of a rich set of possibilities that is both highly declarative, and generates compact descriptions [4]. In what follows we propose to solve this problem with a small increment to the UML abstract syntax. With this approach the concepts required for modeling CTTs can be added to the UML. In the following figures we detail this original approach to extend the UML abstract syntax. Classes

CommonBehavi ors

Activities

Tasks

Interacti ons

StateMachi nes

UseCases

Actions

Fig. 10. Package dependencies

As we can see from Fig. 10, in order to isolate the extensions from the actual UML specification, we create a new Package named Tasks to contain the new concepts required for task modeling. Figures 11 and 12 detail the Task package. We introduce three new concepts: TaskTree as a specialization of the Activity concept; Task for modeling the concept of task; and TaskEdge for modeling temporal operators. These new concepts allow the creation of a specialized type of Activity Diagrams for modeling task trees (we name these diagrams Task Tree Diagrams).

Mapping ConcurTaskTrees into UML 2.0

Action

Activity

(from BasicActivi ties)

(from BasicActivities)

247

ActivityEdge (from BasicActivi ties)

+subtask {subsets ownedElement} * 0..1 +superTask {subsets owner}

Task multiplicity = 1

0..1

* +/node

{subsets ownedElement}

TaskTree

+/activity {subsets owner}

0..1

+/activity {subsets owner}

*

TaskEdge

+/edge {subsets ownedElement}

Fig. 11. Tasks Package TaskEdge

IndependentConcurrencyEdge

ChoiceEdge

EnablingEdge

OrderIndepenceEdge

DeactivationEdge

SuspendEdge

Fig. 12. Tasks Operators

In order to ease connection with the existing UML 2.0 notation, we decided to maintain a very close relationship between the new task concepts and the existing activity diagrams. Figure 13 illustrates the extension to the UML 2.0 abstract syntax and provides an example for each of the previously described temporal relationships.

Fig. 13. Example and summary of the notation

248

L. Nóbrega, N.J. Nunes, and H. Coelho

Figure 13 depicts a simple task tree that illustrates our approach (already presented in Fig. 1, using CTT notation). The notation used for temporal operators are inspired by UML activity notations, namely Independent Concurrency, Choice and Deactivation. They have obvious similarities with Fork/Join Node, Decision Node and Interrupting Edge, respectively. For information exchange between tasks, we adopt the Object Flow and Pin notation shown in the link between ProvideRequest and ShowResults tasks. The relations between a task and its refinement subtasks are inspired by the notation for showing a Package and its contents in the same diagram, providing an adequate hierarchical representation.

6 Conclusions We showed in this paper that the ConcurTaskTrees semantics can be expressed in terms of UML Activities semantics, allowing a truly unified integration of task model concepts within the UML framework, fostering co-evolutionary development of interactive systems, providing a common ground to effectively bring task modeling into software engineering and promoting artifact interchange between tools and practitioners in SE and HCI. The Petri-net like semantics of UML 2.0 Activities represents a clear improvement over previous versions thus bringing this new opportunity to integrate CTT with UML. The extensions and the adapted notation described here keep the expressiveness and effectiveness of CTT’s notation and reduce the difficulty of acceptance of another notation. Finally, activity-based semantics for CTTs can take full advantage of existing work on verification and execution of activities diagrams and promotes the inclusion of task modeling in model-based approaches.

References 1. van Harmelen, M., Artim, J., Butler, K., Henderson, A., Roberts, D., Rosson, M. B., Tarby, J. C., Wilson, S.; Object Models in User Interface Design, 29(4), SIGCHI Bulletin, New York, ACM, 1997 2. Nunes, N. J., Cunha, J. F.: Towards a UML profile for interactive systems development: the Wisdom approach, in Proceedings of UML´2000 Conference, Kent – UK, A. Evans, S. Kent, B. Selic (Eds.), Springer Verlag LNCS 1939, New York (2000) pp. 101–116 3. Paternò, F: Towards a UML for Interactive Systems, in Proceedings of Engineering for Human-Computer Interaction HCI’2001, LNCS 2254, pp. 7–18, M. Reed Little, L. Nigay (Eds.), Springer Verlag (2001). 4. Paternò, F: Model-Based Design and Evaluation of Interactive Applications, Springer Verlag (1999) 5. Patricio, L., Cunha, J. F., Fisk, R., Nunes, N. J.: Designing Interaction Experiences for Multi-Platform Service Provision with Essential Use Cases in Proceedings of the 9th international conference on Intelligent user interface: Short Papers, Funchal, Madeira, Portugal pp. (2004) pp. 298-300 6. OMG: UML 2.0 Superstructure Specification, Revised Final Adopted Specification (ptc/0410-02) October 8 (2004) 7. Mori, G., Paternò, F., Santoro, C.: CTTE: Support for Developing and Analysing Task Models for Interactive System Design, IEEE Transactions on Software Engineering, Vol. 28, No. 8, IEEE Press, (2002) pp. 797-813

Goal-Oriented Design of Domain Control Panels Christophe Ponsard1 , Nadiya Balych2 , Philippe Massonet1 , Jean Vanderdonckt2, and Axel van Lamsweerde2 1 2

CETIC Research Center, Charleroi, Belgium Universit´e Catholique de Louvain, Belgium

Abstract. Goal-oriented methodologies have demonstrated some adequacy for modelling composite systems, from high level desired properties to operational requirements on responsible agents. This paper shows how to derive a user interface for human agents from such a model, especially with respect to the monitor and control capabilities of those agents. A goal-oriented widget taxonomy was elaborated in order to facilitate selecting widgets that are appropriate for each element of the underlying domain model. A user-friendly tool for building user interfaces, supporting the retrieval of adequate components and their fine tuning at a graphical level, was developed and deployed on the animator of the Objectiver/FAUST requirements toolbox.

1 Introduction For many years, Model-Based Interface Development Environments (MB-IDEs) have been largely driven and inspired by the same suite of typical models such as: task, domain, user, abstract user interface, concrete user interface, final user interface, platform, etc. [17][2]. Among these, two classic models typically initiate the development process: the domain and task models. The former has been largely used during the past decade to automatically generate a graphical user interface. The later was defined to address some shortcomings. Today, it represents the most common model that drives the development process to foster user-centered design. These models have demonstrated some relevance, some convenience, and some efficiency in producing user interfaces for a very specific type of interactive system: information systems, where the User Interface (UI) mainly consists of a predefinition of forms, windows, menu bars, pull-down menus, etc. Typical information systems could be developed in Interface Builders such as Microsoft Visual Basic, C++, Java or Web applications. Traditional MB-IDEs have demonstrated the feasibility of the approach for such systems. But when it comes to developing the UI of a complex, reliable system that is not an information system (e.g., a control system, a simulator), in particular when the UI cannot consist of predefined widgets with a predefined behavior, it seems more difficult to reuse the same suite of models. Since in this case these models have not been expanded enough to capture sufficient information to initiate the development process, perhaps other models need to be used. In addition, the task model is widely recognized and used in the Human-Computer Interaction (HCI) community, whereas the Software Engineering (SE) and more specifically Requirements Engineering (RE) community, tends to ignore such a model and S.W. Gilroy and M.D. Harrison (Eds.): DSVIS 2005, LNCS 3941, pp. 249–260, 2006. c Springer-Verlag Berlin Heidelberg 2006 

250

C. Ponsard et al.

rather prefer to exploit models that are more traditionally used in their field. This paper investigates whether the shortcomings of most MB-IDEs for complex, reliable, time constrained interactive systems could be developed following a model-based approach, but based on another suite of models than those which are traditionally used in HCI. In particular, the task model usually represents in HCI the user’s viewpoint by recursively decomposing the task into sub-tasks that are connected with temporal operators to end up with leaf tasks. Of course, each task is associated with one or several goals that need to be achieved when the task has been carried out. In contrast, in RE, a goal model represents the system’s viewpoint by specifying a decomposition of goals into sub-goals that are linked together with several operators to end up with leaf goals assigned to an agent. As in HCI, the initial goal model does not come alone. It is then related to three other models that progressively capture relevant information for the other aspects: object model, agent model, and operation model (Sect. 2). These models are frequently used in the area of RE which provides capabilities to reason about human agent interface design with respect to the requirements under its responsibility (Sect. 3). Therefore, when it comes to specifying the components of the final user interfaces, i.e. the widgets to be used, instead of having a widget classification that is based on the task and/or the domain, the widget ontology should also be revisited. It should provide a rich framework to select the most appropriate combination of displays/controls for each agent to realize its goals (Sect. 4). Then, an animator should provide agent-oriented animations in the same way as the task can be simulated in traditional MB-IDEs [14][1] (Sect. 5). Finally, related work will be reviewed to highlight the contribution and limitations of our approach. Throughout this paper, a non-trivial train system will be used as running example. Although simplified for fitting the size constraints of this paper, this system is based on implementations taken from real world railway signaling systems.

2 Background: Goal-Oriented Modeling This paper considers goal-oriented modelling with the KAOS language which is organised in 4 models: (i) the central model is the goal model which captures and structures the assumed and required properties; (ii) the object model captures the relevant vocabulary to express the goals; (iii) the agent model takes care of assigning goals to agents in a realizable way; (iv) the operation model details, at state transitions level, the work an agent has to perform to reach the goals he is responsible for. 2.1 Building the Goal and the Object Models Although the process of building those 4 models is intertwined, the starting point is usually a number of key properties of the system to-be. Those are expressed using goals which are statements of intent about some system (existing or to-be) whose satisfaction in general requires the cooperation of some of the agents forming that system. Agents are active components, such as humans, devices, legacy software or software-tobe components, that play some role towards goal satisfaction. Some agents thus define

Goal-Oriented Design of Domain Control Panels

251

Fig. 1. Object Model

Fig. 2. Portion of the Goal graph

the software whereas the others define its environment. Goals may refer to services to be provided (functional goals) or to the quality of service (non-functional goals). Goals are described informally in natural language (InformalDef) and are optionally formalized in a real-time temporal logic (FormalDef) [3][8][12]. In our example, the goals relate to safety of transportation: avoiding collision between trains, with other vehicles (especially at railroad crossings), securing passenger (eg., by closing doors when moving). This goal can be stated as follows: Goal Maintain[DoorsClosedWhileMoving] InformalDef: Doors should be closed when the train is moving. FormalDef: (∀tr : T rain) tr.moving ⇒ tr.doorClosed

In the above formulation, we have identified the Train entity with its moving and doorClosed attributes. Those are incrementally added to the structural model which captures passive (entities, relationships and events) and active objects (agents). Unlike goals, domain properties are descriptive statements about the environment, such as physical laws, organizational norms or policies, etc. (eg., a train requires some distance to come to stop—law of inertia). A key characteristic of goal-oriented requirements engineering is that goals are structured and that guidance is provided to discover that structure and refine it until agents can be found to realize those goals in cooperation. In KAOS, goals are organized in AND/OR refinement-abstraction hierarchies where higher-level goals are in general

252

C. Ponsard et al.

strategic, coarse-grained and involve multiple agents whereas lower-level goals are in general technical, fine-grained and involve fewer agents [4]. In such structures, ANDrefinement links relate a goal to a set of subgoals (called refinement) possibly conjoined with domain properties; this means that satisfying all subgoals in the refinement is a sufficient condition in the domain for satisfying the goal. OR-refinement links may relate a goal to a set of alternative refinements. Figure 2 shows the goal structure for our system. It was set up starting from a few initial goals and by asking respectively ”WHY” and ”HOW” questions to discover parent goals (such as Maintain[SafeTransportation]) and son goals (such as Maintain[DoorClosedWhileMoving]). 2.2 The Agent Model Goal refinement ends when every subgoal is realizable by some individual agent assigned to it, that is, expressible in terms of conditions that are monitorable and controllable by the agent [10]. A requirement is a terminal goal under responsibility of an agent in the software-to-be; an expectation is a terminal goal under responsibility of an agent in the environment. For example: Agent TrainDriver Kind: Human ResponsibleFor: Maintain[DoorClosedWhileMoving], Achieve[TrainProgress... Monitors: Block.signal Controls: T rain.moving, T rain.doorClosed, T rain.blockOf

In our design, all agents are part of the automated system except the train driver, a human which stays in control of the moving state and the location of the train. The door and motor controllers are running on board of the train, while the signal controller and the gate controller are ground-based. In our case study, a very important problem to reason about is the way to relay ground and board information w.r.t their monitor/control needs. Figure 3 shows the agent interface view which displays the flow of monitored/controlled information among agents.

Fig. 3. Agent Interface Model

2.3 The Operation Model Goals are operationalized into specifications of operations to achieve them [3]. An operation is an input-output relation over objects; operation applications define state

Goal-Oriented Design of Domain Control Panels

253

transitions along the behaviors prescribed by the goal model. The specification of an operation is classical with precondition (necessary), postcondition (target state) and trigger condition (sufficient). An important distinction is also made between (descriptive) domain pre/postconditions and (prescriptive) pre-, post- and trigger conditions required for achieving some underlying goal(s). For example, the OpenDoors operation may be specified as follows: Operation OpenDoors Input: tr:Train/doorClosed Output: tr:Train/doorClosed DomPre: tr.doorClosed DomPost: ¬tr.doorClosed ReqPre: for Saf eRailroadCrossing ¬tr.moving ReqTrig: for F astP assengerT ransf ert (∃st : Station) at(tr, st)

A goal operationalization is a set of such specifications. For example, to be complete, our operationalization of the goal DoorClosedW hileM oving would also require to strengthen the StartTrain operation.

3 Overview of the Panel Design Process Designing a control panel from a correctly refined and operationalized model can be done in a systematic way as the model, and more specifically the agent sub-model, captures all the relevant information. The overall process is the following: – For each human agent in the goal model, retrieve all the requirements under his responsibility – For each human agent in the agent model, identify all the information he has to monitor and to control w.r.t the realization of those requirements. – For each human agent in the in the operation model, identify the operation(s) under the performance of that agent and through which he may affect controlled elements. – For each monitored element, select an appropriate display widget and map it on the monitored element. – For each controlled element, select an appropriate control widget and map it on the related operation(s). In our example, the TrainDriver is responsible for the goal Maintain [DoorClosedWhileMoving]. The agent model shows he has to control both the doorClosed state and the moving state. The T rainDriver is also responsible for other goals such as Maintain[ProgressWhenGoSignal] and Maintain[StopOnRedSignal] which requires the ability to monitor Signal and again to control the moving state. For the controlled part: doorClosed and moving are boolean attributes whose control is achieved through the Start/Stop and OpenDoors/CloseDoors pair of operations. In this case, an adequate control widget is a two-state switch for which each transition has a corresponding operation in the model. It also provides feedback on the controlled state. As human agents are limited in many ways, it is important to check for the effective monitorability/controlability of the considered information. Lack of monitorability may be caused by limitation in perception capabilities (eg. danger of missing/misinterpreting

254

C. Ponsard et al.

track information at high speed), limited focus (eg. looking at track signals and on-train controls), etc. Lack of controllability may be caused by limitation in response time (eg. emergency braking at high speed), high load, etc. Those specific properties can be taken into account when reasoning about the realizability of the design of the system using a number of available techniques (obstacle[20], agents tactics[10]). For example, when reasoning about the monitorability of block occupation, direct physical perception of track signals is only possible at low speed. High speed would be an obstacle which can be resolved by a more elaborate system design, with in-cabin reporting and relying on ground-cabin communications. Human agents can also forget things and make mistakes: the KAOS framework can model and reason about this using knows/belief predicates in goal formulations. The reasoning can be done directly, at refinement time, or more preferably later, using obstacle analysis[20] performed on an ideal model to evaluate possible consequences and mitigate them.

4 Building the Widget Taxonomy In order to facilitate the design of interactive panels with respect to the underlying goal model, several real-world control panels were studied in a number of domains such as transportation, industrial control and domestic use. They helped in the definition of a widget taxonomy in terms of goals (being able to monitor/control state, to report dangers, etc.) instead of directly being focused on data or tasks. So far, several widget taxonomies have been investigated, but based on other models such as domain model [21] or a task model [13]. In those existing taxonomies, widgets are classified according to the underlying data or domain model they can manipulate, but do not differ whether the data are involved as input, output, or w.r.t their impact on system goal. Rather, in the present taxonomy, it is possible to directly map the previously identified goals and sub-goals (especially the leaf goals) to the widget they can best represent. The resulting taxonomy is partially shown in Fig. 4. It is structured much in the same spirit as a KAOS model: the first level of the classification is a generic model capturing the goals the UI should address. Each goal is refined until relevant widget classes are identified. Those are then structured based on a more traditional data type hierarchy. At the bottom of the figure, some typical instances are illustrated. In the resulting taxonomy, a number of conceptual attributes were identified such as display/control/alarm kind (goal level) and the type of data shown (data level). Based on the study of several widget instances, a number of graphical attributes, not part of the taxonomy, were also identified: those help in tuning the visual aspect: layout, divisions, labels, units, etc. For the speedometer dial shown on the left of Fig. 5, conceptual attributes are: display modality, continuous data range; graphical attributes are: angular layout, subdivisions, unit. All those features are captured by a single concept which is the “computer version” of that widget and of other “dial” widgets sharing the same conceptual attributes. It is implemented by a corresponding class. In this work, the Java language was used together with a JavaBeans interfacing mechanism and the Swing graphical toolkit.

Goal-Oriented Design of Domain Control Panels

255

Fig. 4. Widget Taxonomy

Fig. 5. Physical (left) and modeled (right) dials from various domains

5 Deployment on a Requirements Animator An important aspect of using models from the beginning of the development process, especially for complex systems like interactive monitoring and supervision systems, is the capability to execute the elicited models in some way to animate a first version of the future system for validation purpose. So, it is crucial that the underlying models are expressive enough to obtain a running interface. For instance, the Visual Task Model Builder [1] mainly exploits the task model to animate the ordering of tasks in time. This is certainly interesting but is not detailed enough to obtain a working prototype that is executable enough to demonstrate non-trivial interaction sessions. Similarly in CTTE [14], it is possible to animate the task model to see possible orderings of tasks in time, but the task model is not expressive enough to demonstrate a complete executing of a task. For this purpose, we wanted to exploit all underlying models as exposed in Section 2 to obtain an animator that is really working without coding or modeling more aspects. The FAUST requirements animator supports the animation of KAOS goal-oriented models [19], [16], [18]. Relying on the Objectiver RE platform[15], the FAUST animator helps in the design of the system model, by the ability to generate and replay execution traces and in the validation, by allowing domain experts to interact with an executable model using a familiar UI. The existing animator supports the compilation of operationalized goal-models into finite state machines (FSM) which are then run in a simulator engine on a server. Several client actors can then connect on that simulator to

256

C. Ponsard et al.

Fig. 6. An Animation Scenario

interact with the model in a multi-user way, enabling interesting validation scenarios to be played. The animator is complemented by a monitor which reports goal violations. Presently, the animator suffers from a three important shortcomings: (1) the lack of control using domain specific interfaces, (2) the lack of consistent agent-based UI (currently an animator actor is not specially bound to an agent in the model, it may not give enough monitor/control or too much) and (3) the lack of a support for the development of such interfaces. The first and second points were addressed in the previous sections. On the tool side, the composition and mapping is supported by a visual tool allowing the animation designer to assemble the panel by performing queries on the widget library for mapping each relevant variable. The tool was implemented in Java with the Swing graphical library. It supports composition by drag-and-drop of components on the panel. A JavaBeans based property editor is available for instantiating the available widgets and tuning their graphical rendering. A number of common widgets are also proposed for domains such as automotive, railroad, aerospace and industrial control. The integration within the animator is achieved using a mapping component which manages the consistency between the underlying conceptual model (ie. states and transitions of the generated FSM) and the UI (controls and displays) of the animation. To achieve maximal flexibility, it can be defined at type level and tuned at instance level. The mapping is fully described in [19] and can be roughly summarized as follows: – Display widgets are mapped on state elements (which are also linked to instances of the object model). The type of the widget and the underlying state should be compatible.

Goal-Oriented Design of Domain Control Panels

257

– Control widgets are mapped on an operation which is applied when a user action is performed. The performer is the human agent associated with the enclosing panel. Operation arguments are derived from the input capabilities of the widget (eg., rate of acceleration) and from other observable states (eg., current speed used as set point for a cruise control). Additional constraints can also be expressed using instance information (eg., speed applies to train controlled by the agent). Figure 6 shows a typical animation scenario in two steps, respectively at top and bottom of the figure. The control panel, the lateral view of the train and the FSM instances are displayed from left to right. The user playing the ”driver” role makes a request to start the train (1). It is forwarded to the simulator (2,3) which accepts it (the guard being enabled because doors are closed). After the resulting transition (4), the train is now moving and a state refresh is triggered on the control panel (speedometer) and the lateral view (“forward” arrow) (5,6). In the above scenario, note that if the doors were opened when requesting the start, that user action would have been rejected. This could also be signalled at the UI level using information widgets. This is an interesting feature for modelling automated backup mechanisms behind a human agent.

6 Related Work FAUST and its animator, as outlined in this paper, mainly differs from existing MB-IDE approaches in the sense that four models are borrowed from requirements engineering. Therefore, these models address functional (FR) and non-functional requirements (NFR) in the different models as opposed to solely some NFR in task-based approaches. For instance, it is possible in FAUST to automatically execute the underlying models to obtain a genuine dialog whereas in traditional MB-IDEs, this dialog model should be generated from the task model, which represents a complex task. Furthermore, FAUST is based on all types of requirements, whereas traditional MB-IDEs mainly focus on user’s viewpoint and requirements, such as portability, usability, etc. They decompose the task into sub-tasks, but without considering seriously FR such as domain constraints, robustness, reliability, performance, avoiding of conflict. Such properties are automatically obtained by construction and by generation in the FAUST process, whereas they usually need to be done by hand in MB-IDEs, based on the existing models [21]. Most animations exploit the task model [1] [13], whereas FAUST exploits all four models. Other animation approaches combine system modelling and domain-based visualization: – State-machines based approaches, such as in Statecharts or UML state diagrams. Tools like Statemate and Rhapsody allow those FSM to be executed and coupled with graphical views. Recent work in the area explores reactive animations [5] in order to combine and merge efforts in reactive design (using statecharts) and animation techniques (such as Flash). Our approach has a similar purpose but focuses more on earlier steps: our FSM are less structured but are consistent with goals. Both approaches and tools look essentially complementary and definitively worth combining.

258

C. Ponsard et al.

– Tabular-based approaches, such as SCR and RSML and supported with tools like SCR-toolset [7] and SpecTRM [9]. They focus on the system and model the inputoutput relation with a number of tables. The SCR animator has a visual composer with a library of display and control widgets which can be mapped on table variables. However the SCR library lacks a conceptual structure. – Labeled transition system (LTS). LTSA, an LTS animator relies on scenebeans, a descriptive XML-based animation framework [11]. It provides low level animation primitives (similar to SVG or Flash) which are easy to deploy and reuse even with other underlying modelling languages. – In existing MB-IDEs approaches, the model that is usually chosen for representing the dialog, such as a state-transition diagram, a statechart or a Petri net, should be added and constructed by exploiting merely the task model, which leaves the problem typically underspecified. It is therefore the responsibility of the designer to manually choose the right design options and to tweak the dialog model to obtain a version that is detailed enough to work. The above approaches are based on operational specifications and lack the ability to capture the goals, model the environment or reason about agents. Another goal-oriented approach is Formal Tropos which also has an animator but without visualization capabilities [6]. Finally note the focus in this work is on the the design of display/control panels for control systems—other approaches attempt to be more generic.

7 Conclusion and Future Work In this paper, we exposed how goal models, borrowed from requirements engineering, can help in the design of control panels by providing a property driven paradigm as alternative to traditional data-oriented or task-oriented paradigms. A method to design consistent control panel user interfaces from goal models was proposed as well as a goal-oriented widget library to assemble them. The result has then been deployed on a requirements animator as a tool for designing agent-oriented animations. The work has been tested on a number of case studies such as a baggage lockers and a safety injection system. It is now being validated on a larger industrial case: a floor door system for an automated train. FAUST and its animator mainly differ from existing MB-IDEs in that they exploit models borrowed from Requirements Engineering to produce a fully executable UI. In this way, we can also say that the underlying models are executable and dynamic, but they are also more expressive to the point that the dialog and a complete animation can be automatically generated. In addition, it is possible in existing MB-IDEs to apply model-checking techniques to verify properties of interest, such as IFIP Dialog principles, but they need to be run by a human operator. In contrast, here, there is no direct need to rely of these techniques because the resulting interface satisfies the FR and NFR by construction. It is impossible to produce a UI that is not compliant with the constraints imposed by the various models. In the case the requirements were somehow flawed/incorrect in the first place, the goal-directed methodology provides means to detect that because a conflict or inconsistency is likely to become apparent as the

Goal-Oriented Design of Domain Control Panels

259

refinement/agent assignment/operationalization process would fail at some point. Finally, the most interesting difference is that the first model, i.e. the goal model, contains both FR and NFR intertwined, as opposed to user goals only in traditional task-based models. In the end, both approaches should not be presented as alternatives but rather as complementary: the focus is here more upstream in the design process and based on property refinement rather than task refinement. The resulting operation model can be seen as a task model which can be handled by standard HCI techniques. The benefit of using the presented RE-based approach is the access to interesting reasoning techniques about the system, its environment and the interactions across their borderlines which impact the UI. This calls for a more in-depth comparison of HCI and RE approaches and the ways they can cross-fertilize. At short term, we envision to address a number of limitations. Currently, our work focuses mainly on control systems with agents responsible for a small part of the system. We would like to support supervising agents which have global monitoring/control capabilities on the system (eg., train dispatcher). Better structuring mechanisms are also needed for mapping more elaborated data type and helping in the reuse of preassembled sub-panels. We also plan to provide an integration of the goal monitor to reports alarms at interface level.

Acknowledgement This work is financially supported by the European Union (ERDF and ESF) and the Walloon Region (DGTRE).

References 1. M. Biere, Birgit Bomsdorf, and Gerd Szwillus. The visual task model builder. In Chapter 20, in Proceedings of CADUI’99. 2. G. Calvary, J. Coutaz, D. Thevenin, Q. Limbourg, L. Bouillon, and J. Vanderdonckt. A unifying reference framework for multi-target user interfaces. Interacting with Computers, 15(3), June 2003. 3. A. Dardenne, A. van Lamsweerde, and Stephen Fickas. Goal-directed requirements acquisition. Science of Computer Programming, 20(1-2):3–50, 1993. 4. R. Darimont and A. van Lamsweerde. Formal refinement patterns for goal-driven requirements elaboration. In 4th FSE ACM Symposium, San Francisco, 1996. 5. S. Efroni, D. Harel, and I. Cohen. Reactive animation. In Proc. 1st Int. Symposium on Formal Methods for Components and Objects (LNCS 2852), 2002. 6. A. Fuxman, L. Liu, M. Pistore, M. Roveri, and P. Traverso. Specifying and analysing early requirements in tropos. Requirements Engineering Journal, 2004. 7. C. Heitmeyer, J. Kirby, and B. Labaw. Tools for formal specification, verification, and validation of requirements. In Proc. COMPASS ’97, Gaithersburg, 1997. 8. R. Koymans. Specifying message passing and time-critical systems with temporal logic, LNCS 651. Springer-Verlag, 1992. 9. G. Lee, J. Howard, and P. Anderson. Safety-critical requirements specification and analysis using spectrm. In Proc. 2nd Meeting of the US Soft. Syst. Safety WG, 2002.

260

C. Ponsard et al.

10. E. Letier and A. van Lamsweerde. Agent-based tactics for goal-oriented requirements elaboration, 2002. 11. J. Magee, N. Pryce, D. Giannakopoulou, and J. Kramer. Graphical animation of behavior models. In Proc. ICSE’2000, Limerick, 2000. 12. Z. Manna and A. Pnueli. The Reactive Behavior of Reactive and Concurrent System. Springer-Verlag, 1992. 13. G. Mori, F. Patern´o, and C. Santoro. Design and development of multi-device user interfaces through multiple logical descriptions. IEEE TSE, 30(8), August 2004. 14. F. Patern´o. Model-based design and evaluation of interactive applications. In Springer Verlag, November 1999. 15. The Objectiver RE platform. http://www.objectiver.com. 16. C. Ponsard, P. Massonet, A. Rifaut, J.F. Molderez, A. van Lamsweerde, and H. Tran Van. Early verification and validation of mission critical systems. In 8th FMICS Workshop, Linz, 2004. 17. A.R. Puerta. A model-based interface development environment. IEEE Software, 14(4), July/August 1997. 18. The FAUST toolbox. http://faust.cetic.be, 2004. 19. H. Tran Van, A. van Lamsweerde, P. Massonet, and C. Ponsard. Goal-oriented requirements animation. In 12th IEEE Int.Req.Eng.Conf., Kyoto, September 2004. 20. A. van Lamsweerde and E. Letier. Handling obstacles in goal-oriented requirements engineering. IEEE Transactions on Software Engineering, Special Issue on Exception Handling, 26(10), October 2000. 21. J. Vanderdonckt. Advice-giving systems for selecting interaction objects. In Proc. of 1st Int. Workshop on UI to Data Intensive Systems, Edimburgh, 1999.

Future Challenges of Model-Based Design Sandra Basnyat, Joan De Boeck, Erwin Cuppens, Leonel Nóbrega, Francisco Montero, Fabio Paternò, and Kevin Schneider

When we consider models in model-based design (MBD) approaches in the HCI field, we can say that the first generation of tool for user interface construction was based on database models. The second generation of MBD approaches includes models such as the user model, task model, cognitive model, system model etc. However, the third generation of models is the one facing current and future challenges. In this summary report, we present our discussion on the future challenges of MBD. We begin by discussing users, which are complex entities that must be considered in User Centred Design (UCD) approaches and in MBD approaches. Much of their behaviour can impact the models they are represented in. Emotions can change the way people perform tasks for example. Users are not perfect, not always predictable and can perform in an erroneous manner. MBD is usually considered from an errorfree perspective however boundaries much be extended to account for errors. Since we are dealing with humans to achieve UCD, we are dealing with fuzzy information, emotions, behaviour, actions etc. These types of information are difficult to capture in the models we are creating. To what extent are we able to model quality aspects of UI design and incorporate experience in models, or should we accept that there are limitations in MBD approaches. How can we obtain more aesthetically pleasing UIs by extending the use of models? In the field of software engineering, MBD approaches are a big success. For example, UML is widely accepted. However there seems to be a gap between models used in software engineering and MBD approaches used in HCI. Perhaps our models are not accessible, usable and maybe we use too many different models. There are also issues of integration between models while maintaining consistency between them. We need to bridge this gap and have mutual recognition of contributions from different communities. Requirements gathering is an important aspect when bridging the gap between MBD in different communities. MBD should provide support for a wider variety of interaction techniques including virtual reality, haptic touch, multimodality, gesture and voice recognition etc and since we generally model from a single-user perspective, MBD must also cater for multi-user environments which are commonly found in safety-critical systems. UCD is generally an iterative process. In MBD, there is an issue of redesign within models. Modifying models should require little effort. Moreover, models would be useful if they were reusable. There are many other aspects that are generally not addressed in MBD that could improve future UIs including, working with guidelines, patterns, templates and incorporating non-functional requirements in models such as safety.

S.W. Gilroy and M.D. Harrison (Eds.): DSVIS 2005, LNCS 3941, p. 261, 2006. © Springer-Verlag Berlin Heidelberg 2006

Supporting Values Other Than Usability and Performance Within the Design Process Nick Chozos, Jennifer G. Sheridan, Özcan Mehmet, Amir Naghsh, Kwang Chun Lee, and Ann Blandford

When we design computerised systems, we mainly focus on meeting values such as efficiency, reliability, usability and performance among other obvious design requirements. However, computer technologies have evolved to such a level that they have redefined the way humans, companies, organizations, and even society operate, a fact which suggests design has to consider more than just achieving usability and performance. Through experience it has been realised that the way in which technology intertwines with the social and human elements requires that design focuses on supporting human and social values as well. These values vary across domains of application, whether it is safety-critical systems, management information systems, the internet, games, performance arts and so on. Rather than discussing values according to domain of application, we have decided to consider the role of technology in terms of its interaction with the user, the organization and society. The value of usability mainly concerns the user, where the designer’s goal is to design a system that the user can understand, manage and control to a desirable standard. At the level of Human–Computer Interaction, there is a great number of values which are considered as able to enhance and improve both the user’s personal satisfaction and experience, and overall performance, which is probably the most obvious of all desired design values. Research has been investigating design approaches towards facilitating values such as creativity, aesthetics, and even fun. Although the benefits of adding these values to an application are recognised, it will take time before they are considered to be as important as usability for companies. Discussion around design values is far more complicated when considering companies and organizations. Perhaps they can all be summarised under ‘quality’, however quality has many dimensions. On the technical side, reliability, dependability, expandability and other “–ities” are achievable and measurable to a certain extend. However, as mentioned in the beginning of our discussion, when considering other values apart from usability and performance, we have focused on values which are not given enough attention, mainly of a human and social nature. Assuring privacy and fairness, as well as reconciling cultural differences, are some of the challenges of design. It should be noted though that we are not referring only to the design of technology; in order to design technology towards meeting these values, organizations have to evolve towards considering these values as priorities that will affect their performance and financial growth. The last notion highlights the relevance of ethics to design. Especially since the emergence of the World Wide Web, the debate around ethics and computing is constantly growing. The WWW offers a great amount of creativity; however, it is almost S.W. Gilroy and M.D. Harrison (Eds.): DSVIS 2005, LNCS 3941, pp. 262 – 263, 2006. © Springer-Verlag Berlin Heidelberg 2006

Supporting Values Other Than Usability and Performance

263

completely unregulated, facilitating even criminal activities. Furthermore, accidents have occurred due to systems’ failure originating from ‘poorly’ designed systems, suggesting ethically un-sound design. The Internet and computer technology in general have, and are, reshaping morality of our times, constantly challenging the role of the designer. It could be suggested that ethics is one of the most important values to be supported by the design process. However, ethics does not only demand professionalism from the side of the designers, but from many other stakeholders that are involved, such as adopting organizations, users and even the government and regulatory agents.

Ambience and Mobility Gavin J. Doherty, Lydie du Bousquet, Jos´e Creissac Campos, El Mustapha El Atifi, Gilles Falquet, Mieke Massink, and Carmen Santoro

Mobile users generate a number of new problems by changing the context of interaction with the system. While context has always been relevant to interaction, the fact this can change, and the fact that tasks may be dependant on these contexts adds a new dimension to the design problem. Furthermore in some cases applications should be able to adapt to be pertinent to the current context, adding to the complexity of the applications to be constructed. With regard to “ambient” interaction, where systems are attempting to intelligently and unobtrusively help the user, understanding the user’s intentions and providing relevant and adequate responses is a new problem. Furthermore, supporting the construction of such applications provides an additional challenge. From a design perspective, an important activity is to determine what part of the context is relevant for the tasks of the user or for that particular application. We considered what level of detail and complexity for context models is necessary for design. In terms of modelling the context it was felt that there is a need for useful abstractions for reasoning about aspects of context of relevance to the user, but also aspects of context which the sytem may be responding and adapting to. Particular problems identified in this regard were context switching and context superposition. Where these are complex enough to justify tool support, there are issues to be addressed regarding the types of models which are appropriate for specification and validation purposes. One can question whether a specific and seperate model to express the context is necessary, and particularly whether augmentations of task models could be sufficient. The answer to this may depend on the complexity of the situation being considered. Possible additional dimensions to be addressed by context models would include real time issues, modes, adaptative interfaces, user models, domain models and device models. Another issue which may be resolved through the use of models is to examine multiple applications existing in the same context, potentially using the same context infrastructure. For ambient applications knowledge of user intentions may be required to propose appropriate behaviour by the system. How can we model user intentions for the purposes of building such systems? It was proposed that there might there be typical mistakes to avoid, and methods or patterns for providing particular kinds of ambient “service”. A final question concerns how user intentions may be dependant on the context, and whether this can be incorporated into models.

S.W. Gilroy and M.D. Harrison (Eds.): DSVIS 2005, LNCS 3941, p. 264, 2006. c Springer-Verlag Berlin Heidelberg 2006 

Outdated Ideas of the Design Process and the Future of Formal Models, Methods and Notations Dominic Furniss, Alan Dix, Christophe Ponsard, and Guo-Qiang Zhang

This topic implies that the future of formal techniques is tied to outdated ideas of the design process, perhaps of the ‘waterfall model’ variety, in contrast to more informal, fast and iterative techniques such as agile methods, which tend to be prototype-centric and less analytical. Indeed, these more agile techniques appear to be gaining importance where industry is moving towards more mobile and ambient technologies. A future challenge of formal techniques is how they could contribute to these areas, and how they can fit into the less formal conceptions of the design process. It is also important to understand industrial design contexts and fit with their conduct rather than trying to impose radical changes. The diverse toolbox of formal techniques can be used to add value in design. Formal techniques differ in the extent of their formalness, from strict mathematical models to less formal notations and diagramming techniques. There is wide variation both in their application to different contexts and in the investment in terms of the formalness involved in applying a particular technique. Both of these should be considered by the designer when choosing a technique to add value to a design process. It was recognised that a future challenge was to better communicate when to use a particular technique, what bits of it and how much. Formal techniques can be used for a variety of different purposes, including model checking, developing an understanding of a situation, and communication within design groups and stakeholders. Each plays a part in different design contexts, and it is up to the designers to deploy these techniques correctly. Importantly, the process of applying a formal technique develops an understanding of the situation in the designer, beyond any representation they may create. The application of the model/method/notation by the designer necessarily shapes the situation someway; this interplay between the designer, situation and representation leads them to reconceptualise the situation by noticing certain properties and features within it, which ultimately develops their understanding of it. The value of formal techniques is likely to be realised differently in different contexts, and so their potential is tied to the values of the context in question. For example, the value of guaranteeing the safety of a system will be higher in critical environments than in website development. It is therefore likely that formal methods will be successful in some contexts and less so in others. Adding value in different contexts is no doubt a critical factor for potential adoption. In addition, the value of formalisms tend to be evident only long after use; getting more immediate perceived/actual benefit is critical to future adoption of formal methods. The extent to which formalisms will be utilised continues to depend on the values of the design context and the value they can give to the design process and designer. It appears there is still work to be done in adapting, developing, and communicating these techniques to increase the perceived/actual value they provide.

S.W. Gilroy and M.D. Harrison (Eds.): DSVIS 2005, LNCS 3941, p. 265, 2006. © Springer-Verlag Berlin Heidelberg 2006

Author Index

Balych, Nadiya 249 Basnyat, Sandra 51, 261 ter Beek, Maurice H. 39 Benford, Steve 15 Berti, Silvia 149 Blandford, Ann 26, 262 Blythe, Mark 1 Bouchet, Jullien 102 du Bousquet, Lydie 102, 264

Lee, Kwang Chun 213, 262 Limbourg, Quentin 161 L´ opez-Jaquero, V´ıctor 161 Lozano, Mar´ıa 161

Cairns, Paul 201 Campos, Jos´e Creissac 188, 264 Choi, Ho-Jin 213 Chozos, Nick 51, 262 Coelho, Helder 237 Coninx, Karin 114, 225 Cuppens, Erwin 225, 261

Naghsh, Amir M. 90, 262 N´ obrega, Leonel 237, 261 Nunes, Nuno Jardim 237

De Boeck, Joan 114, 261 Dearden, Andy 90 Dix, Alan 15, 265 Doherty, Gavin J. 188, 264 Dupuy-Chessa, Sophie 102 El Atifi, El Mustapha

126, 264

Falquet, Gilles 126, 264 Furniss, Dominic 26, 265 Gonz´ alez, Pascual 161 Gow, Jeremy 201 Graham, T.C. Nicholas 137 Johnson, Chris Kang, Sungwon

51

O’Malley, Claire 15 ¨ Ozcan, Mehmet B. 90 Palanque, Philippe 51 Paquette, David 78 Patern` o, Fabio 67, 149, 261 Phillips, W. Greg 137 Ponsard, Christophe 249, 265 Raymaekers, Chris 114, 225 Reeves, Stuart 15 Santoro, Carmen 149, 264 Schneider, Kevin A. 78, 261 Shen, Gongqin 173 Sheridan, Jennifer G. 15, 262 Sun, Jiayang 173 Thimbleby, Harold Tian, Ye 173 Vanderdonckt, Jean Volpe, Marco 67

213

van Lamsweerde, Axel Latella, Diego 39 Ledru, Yves 102 Lee, Dan Hyung 213

Massink, Mieke 39, 264 Massonet, Philippe 249 McCarthy, John 1 ¨ Mehmet B. Ozcan 262 Montero, Francisco 161, 261

249

201 161, 249

Wolfe, Christopher Wright, Peter 1

137

Zhang, Guo-Qiang

173, 265