Lecture Notes in Computer Science Edited by G. Goos, J. Hartmanis, and J. van Leeuwen 2806 3 Berlin Heidelberg New Y...

33 downloads 1366 Views 6MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!

DOWNLOAD PDF

Lecture Notes in Computer Science Edited by G. Goos, J. Hartmanis, and J. van Leeuwen

2806

3

Berlin Heidelberg New York Hong Kong London Milan Paris Tokyo

Jesus Favela Dominique Decouchant (Eds.)

Groupware: Design, Implementation, and Use 9th International Workshop, CRIWG 2003 Autrans, France, September 28 - October 2, 2003 Proceedings

13

Series Editors Gerhard Goos, Karlsruhe University, Germany Juris Hartmanis, Cornell University, NY, USA Jan van Leeuwen, Utrecht University, The Netherlands Volume Editors Jesus Favela CICESE Computer Science Department km. 107 Carr. Tijuana-Ensenada Ensenada, B.C. Mexico E-mail: [email protected] Dominique Decouchant Laboratoire LST-IMAG Logiciels Systèmes Réseaux 681, rue de la Passerelle, BP 72, 38402 Saint-Martin d’Heres Cedex, France E-mail: [email protected] Cataloging-in-Publication Data applied for A catalog record for this book is available from the Library of Congress. Bibliographic information published by Die Deutsche Bibliothek Die Deutsche Bibliothek lists this publication in the Deutsche Nationalbibliografie; detailed bibliographic data is available in the Internet at .

CR Subject Classification (1998): H.5.2, H.5.3, H.5, K.3.1, K.4.3, C.2.4 ISSN 0302-9743 ISBN 3-540-20117-3 Springer-Verlag 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-Verlag. Violations are liable for prosecution under the German Copyright Law. Springer-Verlag Berlin Heidelberg New York a member of BertelsmannSpringer Science+Business Media GmbH http://www.springer.de © Springer-Verlag Berlin Heidelberg 2003 Printed in Germany Typesetting: Camera-ready by author, data conversion by PTP-Berlin GmbH Printed on acid-free paper SPIN: 10949900 06/3142 543210

Preface

This volume constitutes the proceedings of the 9th International Workshop on Groupware (CRIWG 2003). The conference was held in the city of Autrans, on the spectacular Vercors plateau in the foothills of the French Alps. The organizing committee could not have thought of a better setting to inspire lively discussions and reﬂection on open issues facing the ﬁeld of groupware. The CRIWG workshops have been motivated by advances in ComputerSupported Cooperative Work, and by the need for CSCW to meet the challenges of new application areas. With this ninth meeting, CRIWG aimed to provide a forum for academic researchers and professionals to exchange their experiences and ideas about problems and solutions related to the design, development, and use of groupware applications. The selection of papers followed a strict refereeing process by a renowned international committee. We received 84 contributions with ﬁrst authors from 21 diﬀerent countries, from which 30 papers were selected to be presented and published in this proceedings volume. The papers in these proceedings include 18 long papers presenting mature work and 12 short papers describing promising work in progress in the ﬁeld. We thank all members of the Program Committee for their valuable reviews of the papers. In addition, we were pleased to have as invited speaker Prof. Saul Greenberg from the University of Calgary in Canada, a renowned specialist in Groupware and HCI. An extended abstract of his lecture is included in these proceedings. In putting together this conference, we had the pleasure of working with an outstanding group of people. We thank them all for their hard work on behalf of this conference. In particular we would like to thank Christine Ferraris, Sonia Mendoza, Alberto L. Moran, and Irma Amaya. We extend a special acknowledgment to our sponsoring organizations: the C.N.R.S. (Centre National de la Recherche Scientiﬁque), the I.M.A.G. (Institut d’Informatique et de Math´ematiques Appliqu´ees de Grenoble), the Conseil R´egional Rhˆ one-Alpes, the Mairie de Grenoble, the Conseil G´en´eral de Savoie, the I.N.P.G. (Institut National Polytechnique de Grenoble), the Universit´e de Savoie, and the U.J.F. (Universit´e Joseph Fourier, Grenoble), in France, and CINVESTAV-IPN and CICESE in Mexico. Last, but certainly not least, we thank you for your interest in CRIWG 2003, and very much hope you found your experience at the conference to be enriching.

September 2003

Jesus Favela Dominique Decouchant

Conference Organization

Program Committee Chair Jesus Favela (CICESE, Ensenada, Mexico)

Conference Chair Dominique Decouchant (Laboratoire LSR, IMAG, Grenoble, France)

Program Committee Pedro Antunes (Universidade de Lisboa, Portugal) Beatriz Barros (UNED, Madrid, Spain) Karin Becker (PUCRS, Porto Alegre, Brazil) Marcos R.S. Borges (Federal University of Rio de Janeiro, Brazil) Gregory Bourguin (Universit´e du Littoral Cˆ ote d’Opale, Calais, France) Patrick Br´ezillon (University of Paris VI, Paris, France) Jo¨elle Coutaz (CLIPS-IMAG, Grenoble, France) ´ Bertrand David (Ecole Centrale de Lyon, Lyon, France) Dominique Decouchant (LSR-IMAG, Grenoble, France) Giorgio De Michelis (University of Milano - Bicocca, Milano, Italy) ´ Pierre Dillenbourg (Ecole Polytechnique F´ed´erale de Lausanne, Switzerland) Yannis Dimitriadis (Universidad de Valladolid, Spain) Henrique Domingos (Universidade Nova de Lisboa, Portugal) Jesus Favela (CICESE, Ensenada, Mexico) Christine Ferraris (Universit´e de Savoie, Chamb´ery, France) Borko Fuhrt (Florida Atlantic University, Boca Raton, Florida, USA) Hugo Fuks (PUC/RJ, Rio de Janeiro, Brazil) J´erˆome Gensel (LSR-IMAG, Grenoble, France) Luis Guerrero (Universidad de Chile, Santiago, Chile) J¨ org M. Haake (FernUniversit¨ at Hagen, Germany) Andreas Harrer (University of Duisburg, Germany) Gerd Kortuem (Lancaster University, UK) Gloria Mark (University of California, Irvine, USA) Herv´e Martin (LSR-IMAG, Grenoble, France) Ana M. Mart´ınez (CINVESTAV-IPN, Mexico D.F., Mexico) Jos´e A. Pino (Universidad de Chile, Santiago, Chile) Jean-Charles Pomerol (University of Paris VI, Paris, France) Wolfgang Prinz (Fraunhofer FIT, Sankt Augustin, Germany)

VIII

Conference Organization

Mike Robinson (University of Jyvaskyla, Finland) Ana Carolina Salgado (Fed. Univ. of Pernambuco, Olinda, Brazil) J. Alfredo S´ anchez (UDLA, Puebla, Mexico) Ivan Tomek (Acadia University, Wolfville, Canada) Gert-Jan de Vreede (University of Nebraska at Omaha, USA) Aurora Vizcaino (Universidad de Castilla-La Mancha, Ciudad Real, Spain)

Reviewers P. Antunes A. Barbosa B. Barros K. Becker M. Borges G. Bourguin P. Br´ezillon J. Coutaz B. David D. Decouchant G. De Michelis P. Dillenbourg Y. Dimitriadis H. Domingos J. Favela C. Ferraris B. Fuhrt H. Fuks J. A. Garc´ıa-Mac´ıas J. Gensel M. A. Gerosa V. M. Gonz´ alez

L. Guerrero J. M. Haake A. Harrer G. Kortuem G. Mark H. Martin A. M. Mart´ınez A. I. Mart´ınez R. Menchaca A. L. Mor´ an J. A. Pino J. C. Pomerol W. Prinz L. H. Raja Gabaglia M. Robinson M. Rodr´ıguez A. C. Salgado J. A. S´ anchez I. Tomek G. J. de Vreede A. Vizcaino

Sponsoring Institutions Centre National de la Recherche Scientiﬁque, France Institut d’Informatique et de Math´ematiques Appliqu´ees de Grenoble, France Conseil R´egional Rhˆ one-Alpes, France Mairie de Grenoble, France Conseil G´en´eral de Savoie, France Institut National Polytechnique de Grenoble, France Universit´e de Savoie, Chamb´ery, France Universit´e Joseph Fourier, Grenoble, France CINVESTAV-IPN, Mexico D.F., Mexico CICESE, Ensenada, Mexico

Table of Contents

Opening Keynote Enhancing Creativity with Groupware Toolkits . . . . . . . . . . . . . . . . . . . . . . . Saul Greenberg

1

Workspaces and Groupware Infrastructure MARS: Modelling Arenas to Regulate Collaborative Spaces . . . . . . . . . . . . Carmen Mezura-Godoy, Michel Riveill, Stephane Talbot

10

Transparent Latecomer Support for Synchronous Groupware . . . . . . . . . . . Stephan Lukosch

26

COVE: A Design and Implementation of Collaborative Object-Oriented Visualization Environment . . . . . . . . . . . . . . . . . . . . . . . . . . Hyung-Jun Kim, So-Hyun Ryu, Young-Je Woo, Yong-won Kwon, Chang-Sung Jeong

42

Tailoring Designing Tailorable Groupware for the Healthcare Domain . . . . . . . . . . . . Robert Slagter, Margit Biemans

58

Two-Level Tailoring Support for CSCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . J¨ org M. Haake, Till Sch¨ ummer, Anja Haake, Mohamed Bourimi, Britta Landgraf

74

The Reciprocity Project. A P2P Meta-groupware Supporting Co-evolution and Reciprocity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fr´ed´eric Hoogstoel, Ludovic Collet, Alain Derycke, Xavier Le Pallec Symba: A Tailorable Framework to Support Collective Activities in a Learning Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Marie-Laure Betbeder, Pierre Tchounikine

82

90

Evaluating Groupware The Impacts of Awareness Tools on Mutual Modelling in a Collaborative Video-Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nicolas Nova, Pierre Dillenbourg, Thomas Wehrle, Jeremy Goslin, Yvan Bourquin

99

X

Table of Contents

Perceived Value: A Low-Cost Approach to Evaluate Meetingware . . . . . . . 109 Pedro Antunes, Carlos J. Costa Exploring Interaction Behaviour and Performance of Online Collaborative Learning Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Thanasis Daradoumis, Fatos Xhafa, Joan Manel Marqu`es

Flexible Workﬂow A New Language to Support Flexible Failure Recovery for Workﬂow Management Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Gwan-Hwan Hwang, Yung-Chuan Lee, Bor-Yih Wu Constraint-Based Flexible Workﬂows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Jacques Wainer, F´ abio de Lima Bezerra Workﬂow Recovery Framework for Exception Handling: Involving the User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Hernˆ ani Mour˜ ao, Pedro Antunes

CSCL COW, a Flexible Platform for the Enactment of Learning Scenarios . . . . . 168 Thomas Vantroys, Yvan Peter Competency Management for Group Formation on the AulaNet Learning Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Hugo Fuks, Lu´ıs Henrique Raja Gabaglia Mitchell, Marco Aur´elio Gerosa, Carlos Jos´e Pereira de Lucena Dynamic Generation of Adaptive Web-Based Collaborative Courses . . . . . 191 Rosa M. Carro, Alvaro Ortigosa, Estefan´ıa Mart´ın, Johann Schlichter Collaborative Authoring, Use, and Reuse of Learning Material in a Computer-Integrated Classroom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Nelson Baloian, Jos´e A. Pino, Olivier Motelet

Awareness Supporting Collaborative Drawing with the Mask Versioning Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Alexandre Pereira Meire, Marcos R.S. Borges, Renata Mendes de Ara´ ujo, An Agent Framework to Support Opportunistic Collaboration . . . . . . . . . . 224 Melfry Moreno, Adriana Vivacqua, Jano de Souza

Table of Contents

XI

Supporting Collaborative Processes Groupware Support for Cooperative Process Elicitation . . . . . . . . . . . . . . . . 232 Rosa M. de Freitas, Marcos R.S. Borges, Fl´ avia Maria Santoro, Jos´e A. Pino Improving the Use of Strategies in Computer-Supported Collaborative Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 C´esar A. Collazos, Luis A. Guerrero, Jos´e A. Pino, Sergio F. Ochoa Supporting Complex Decision Making Processes with Collaborative Applications – A Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Patrick Br´ezillon, Fr´ed´eric Adam, Jean-Charles Pomerol

Workﬂow Management Systems An Architecture for Supporting Disconnected Operation in Workﬂow: An XML-Based Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Pedro Arroyo-Sandoval, Ana I. Martinez-Garcia, Cristina Ramirez-Fernandez Interoperability of Workﬂow Engines Based on Agents Using Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 Gabrielle D’Annunzio Cavalcanti, Pedro Porf´ırio Muniz Farias

Context in Groupware A Conceptual Framework for Analyzing the Use of Context in Groupware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 M´ arcio G.P. Rosa, Marcos R.S. Borges, Flavia M. Santoro Application Design Based on Work Ontology and an Agent Based Awareness Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314 Rosa Alarc´ on, David A. Fuller Supporting Context-Aware Collaboration in a Hospital: An Ethnographic Informed Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330 Miguel A. Mu˜ noz, Victor M. Gonzalez, Marcela Rodr´ıguez, Jesus Favela

Supporting Communities MADE – A Groupware Application to Support Real-Time Activities of Distributed and Cooperating Communities . . . . . . . . . . . . . . . . . . . . . . . . . 345 Pekkola Samuli, Arto Rikalainen, Tero Toivonen, Saku Hujala, Niina Kaarilahti, Risto Lintinen, Pasi Pohjola

XII

Table of Contents

Collaborative Scenarios to Promote Positive Interdependence among Group Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 C´esar A. Collazos, Luis A. Guerrero, Jos´e A. Pino, Sergio F. Ochoa Building Virtual Communities for Information Retrieval . . . . . . . . . . . . . . . 371 Daniel Memmi, Olivier N´erot

Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381

Enhancing Creativity with Groupware Toolkits Saul Greenberg Department of Computer Science, University of Calgary, Alberta T2N1N4 Canada [email protected] http://www.cpsc.ucalgary.ca/~saul/

Abstract. Effective groupware toolkits not only make it possible for average programmers to develop groupware, but also enhance their creativity. By removing low-level implementation burdens and supplying appropriate building blocks, toolkits give people a ‘language’ to think about groupware, which in turn allows them to concentrate on creative designs. This is important, for it means that programmers can rapidly generate and test new ideas, replicate and refine ideas presented by others, and create demonstrations for others to try. To illustrate the link between groupware toolkits and creativity, I describe example toolkits we have built and how others have leveraged them in their own work.

1

Introduction

The first true vision and implementation of real time groupware happened at the Fall Joint Computer Conference in 1968, where Douglas Engelbart demonstrated many important concepts including terminal-sharing, multiple pointers and turn-taking over shared displays, and audio / video conferencing [5]. This tour-de-force was far ahead of its time, and it was not until 15 years had passed that a few other researchers began replicating and extending Engelbart’s ideas, most notably Sarin’s [15] and Foster’s [6] PhD theses. Shortly afterwards, the field of Computer Supported Cooperative Work (CSCW) formed (late 1980s). A veritable explosion of research followed, and CSCW is now considered a relatively mature discipline. In spite of this history and the many research advances made since 1968, groupware has not made many inroads into the everyday world, especially when compared to the advanced made in desktop publishing (which also started with Engelbart). Why is this the case? I argue that a key technical problem is that average programmers do not have sufficient tools to design, prototype and iterate real time groupware. Current available tools are far too low level. For example, most commercial toolkits provide basic communication facility such as socket programming or remote procedure calls, but little else. This has several serious implications: − most programmers eschew groupware development because it is too hard to do − those who do decide to develop groupware place most of their creative efforts into low level implementation concerns − resulting designs are often fairly minimal ones, with little attention paid to necessary design nuances (even ones well known in the CSCW literature) simply because they are too hard to implement.

J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 1–9, 2003. © Springer-Verlag Berlin Heidelberg 2003

2

S. Greenberg

The consequence of inadequate development tools is that—excepting members of a small specialist community—there has been relatively little evolutionary development and dissemination of groupware systems. The solution is that we as a community must develop groupware toolkits appropriate for the everyday programmer. By appropriate, I mean that a good groupware toolkit should: − be embedded within a familiar platform and language in common use so that people can leverage their existing knowledge and skills − remove low level implementation burdens common to all groupware platforms (e.g., communications, data sharing, concurrency control, session management) − minimize housekeeping and other non-essential tasks − encapsulate successful design concepts known by the research community into programmable objects so they can be included with little implementation effort − present itself through a concise API that encourages how people should think about groupware − make simple things achievable in a few lines of code, and complex things possible. I believe that effective groupware toolkits not only make it possible for others to develop groupware, but also enhance their creativity. If we remove low-level implementation burdens and supply appropriate building blocks, we provide people a ‘language’ to think about groupware, which in turn allows them to concentrate on creative designs. While some may question this premise as over-simplistic, we must recognize that toolkits in other domains have a proven record of enhancing creativity in the general programming community. For example, GUI toolkits, such as Visual Basic, supply a large set of interface components (widgets) and an interface builder for laying them out on the display. Because GUI toolkits encourage programmers to think in terms of widgets, programmers have created a plethora of applications that ‘glue’ these components together in interesting ways [14]. Another example is Macromedia’s Flash, which encourages both programmers and non-programmers to think in terms of scripted animations. Because Flash makes it easy to do, we now see a proliferation of many quite amazing animations on the Web. To illustrate the link between groupware toolkits and creativity, I will provide in this paper several examples of groupware toolkits we have built and how students— both graduates and undergraduates—have leveraged these tools in their own work. Before doing so, I want to explain a recurring pattern that emerged over the years in our group’s investigation of the human and technical factors of groupware, and how recognizing this pattern has led to our appreciating the value of good tools. 1. Human Factors Perspective. Our initial goals in our groupware projects are typically oriented towards human factors. Essentially, we wanted to understand how people interact together when using a particular style of yet-to-be developed groupware application. We would then generalize this understanding to inform other groupware designs. 2. Initial Prototype. Next, we would set about building the first version of the groupware application. This typically involved huge effort as measured by lines of code, time, learning, failed attempts, debugging, and so on. In spite of this effort, the result was often a fragile and rudimentary system.

Enhancing Creativity with Groupware Toolkits

3

3. Prototype Testing. We would then have people try out this prototype. Because are first design attempts, we often saw major usability problems that required fixing. 4. Iterative Prototypes. To fix these usability problems, we would then iteratively redesign the prototype. Yet this often proved impractical to do. The prototype code was often too complex to change, or the system itself was too fragile. Redesigning from scratch, while possible, was onerous due to the time involved. 5. Retrenchment: Building a Groupware Toolkit. We would then realize that—in the long run—iterative prototyping would be far easier if we took the time to build a robust toolkit. Thus we would set ourselves a new technically-oriented goal, where we would delve into the challenges of understanding and building this toolkit and its accompanying run-time architecture. This often meant that we had to defer work on our main human factors goal. 6. The Payoff: Rapid Prototyping. After building the toolkit, we would release it to our internally community. There would then be an explosion of activity. Those with core interests in the human factors challenges would rapidly develop and test a variety of groupware interaction techniques and applications. Those with interests lying elsewhere would often create innovative groupware applications as a side project just to satisfy their own curiousity. 7. Improvement and Dissemination. Because we would develop the toolkit and applications side by side, we would bring good application ideas back into the toolkit as building blocks that could be trivially included in other applications. Examples included common architectural features, widgets, interface components, and interaction techniques. In the remainder of this paper, we will briefly summarize our experiences with several toolkits that we developed for three groupware domains: real time distributed groupware, single display groupware (SDG), and physical user interfaces.

2 Toolkits for Real Time Distributed Groupware My first foray into groupware echoed the above pattern. In 1989, I and my students decided to build a simple drawing application for distributed participants designed around John Tang’s human factors observations of how small design teams draw together [17]. The result was GroupSketch [11], a program written over several months by student Ralph Bohnet. While simple in functionality, the actual program was quite complex. Its more than 5000 lines of code had to deal with many things: setting up the basic communication architecture and protocol for data exchange, creating a session manager that would let people join an existing conference, managing an event stream that handled simultaneous local and remote user actions, creating labeled telepointers for each participant, and creating the actual drawing surface and actions. All this had to work efficiently so that the participants would see no noticeable lag, and this required quite a bit of time and experimentation to get right. Shortly after, student Roseman built GroupDraw [11], an object-based drawing system. As with GroupSketch, the majority of the GroupDraw programming effort went into developing the underlying architecture and worrying about performance issues vs designing the actual group-drawing interface.

4

S. Greenberg

Fig. 1. a) the portrait radar view, b) a fisheye editor; both show where others are working

Both systems worked well enough to give us insights into what we wanted to do next, but were just too large and too finicky to extend. Consequently, we turned our efforts into developing GroupKit, a toolkit for building distributed real time groupware applications [10]. Our experiences with GroupSketch and GroupDraw helped us identify elements common to real time distributed groupware applications, and our GroupKit design would provide these elements to the programmers. − A run-time architecture automatically managed processes, their interconnections, and communications; thus programmers did not have to do any process or communications management. This came for free. − Session managers let end-users create, join, leave and manage meetings. A selection of session managers came as pre-packaged interfaces (one is visible on the top right of Fig 1b), and the programmer could use these ‘out of the box’. However, the programmer could craft their own session manager if they wished. − A small set of groupware programming abstractions let a programmer manage all distributed interactions. Through an RPC-like mechanism, the programmer could broadcast interaction events to selected participants. Alternatively, the programmer could manage interaction via a shared data model: programmers would then think about groupware as a distributed model-view-controller system. Local user actions would change data in the shared model, and remote processes would detect these and use the altered data to generate the view. − Finally, groupware widgets were included that let programmers add generic groupware constructs of value to conference participants. Our first widgets were telepointers, which a programmer could add with a single line of code. Later widgets included awareness widgets such multi-user scrollbars and radar views. GroupKit considerably simplified groupware development e.g., using GroupKit we reimplemented GroupSketch in a few hours in less than a page of code. What was more important is that we could now explore various design ideas through rapid prototyping. For example, our group created a flurry of systems illustrating different methods for supporting awareness within a visual workspace, sometimes turning around several different design ideas in a single day. Figure 1 shows two example

Enhancing Creativity with Groupware Toolkits

5

systems illustrating how people within a group could maintain awareness of others’ actions [13,9]. Because we could now try out our ideas, we could quickly determine which ones were worth pursuing and which were not. While GroupKit was very useful for prototyping real-time distributed graphical user interfaces, it did not handle multimedia. Consequently, we built a new toolkit called the Collabrary [3] that would let us rapidly prototype multimedia groupware. It provides extremely easy access and manipulation of multimedia information. For example, discov- Fig. 2. Presence History (M. Boyle) ering a video camera and acquiring an image takes two line of Collabrary code. It also provides a straightforward API that lets people distribute this information between groupware program instances through a shared data model. Similar to GroupKit, students began creating multimedia groupware because it was easy to do. One example is the Presence History system included in Figure 2, built by Michael Boyle. The remote video is displayed, and a graph at its bottom shows a history of other people’s presence and activity in the scene, determined by image analysis. The entire program is 38 lines of code. Another much more complex example is Michael Rounding’s Notification Collage [12], where colleagues post multimedia elements onto a real-time collaborative surface that all members can see.

3 Toolkits for Single Display Groupware Researchers in Computer Supported Cooperative Work (CSCW) are now paying considerable attention to the design of single display groupware (SDG) i.e., applications that support the work of co-located groups over a physically shared display [16]. Our own work in SDG began with an investigation of transparent menus as an interaction technique that would minimize how people working close together would interfere with each other [19]. Fortunately, Bederson and Hourcade [1] had developed the MID toolkit that let one access multiple mice from Microsoft Windows‘98. While it was still difficult to develop SDG, their toolkit made our own development a reasonable prospect. The problem was that MID did not work with later versions of Windows. Consequently, we decided to re-implement and significantly extend some of the ideas in MID in our own SDGToolkit [18]. SDGToolkit automatically captures and manages multiple mice and keyboards (as does MID), and it also presents them to the programmer as uniquely identified input events relative to either the whole screen or a particular window. Unlike MID, it transparently provides multiple cursors, one for each mouse. To handle orientation issues for tabletop displays (e.g., people seated across from one another), programmers can specify a participant’s seating angle, which automatically rotates the cursor and translates input coordinates so the mouse behaves correctly. Finally, SDGToolkit provides an SDG-aware widget class layer that significantly eases how programmers create novel graphical components that recognize and respond to multiple inputs.

6

S. Greenberg

Fig. 3. a) SDG TableTop Drawing; b) SDG MagicLenses

With SDGToolkit, simple things are simple. For example, Figure 3a illustrates a simple drawing application designed for a square tabletop with four seated people, one per side. Cursors and text labels are oriented appropriately, and the person’s mouse behaves correctly given their orientation. It is written in 20 lines of code. Another example illustrates how students Nicole Stavness and Edward Tse reimplemented Xerox PARC’s ToolGlass interaction technique as an SDG widget. Each user has two mice. Using the first mouse in with their non-dominant hand, each moves his/her toolglass around. With their other hand and mouse, they click through the lens to choose a color. Their programming effort to manage and identify multiple input devices and to package it up as an SDG widget was relatively small; instead most efforts went into the creative aspects of the ToolGlass graphics. More recently, we received a DiamondTouch surface from MERL, which detects multiple simultaneous touches by multiple people and that reports them to a programmer through a basic SDK. We created the DiamondTouch toolkit that wraps this SDK and adds extra capabilities to it, considerably simplifying how people program multi-user / multi-touch applications [4]. Similar to our SDGToolkit, the toolkit identifies multiple inputs on a per-user basis. It generates events that reports when people tap or double-tap the surface, the bounding box surrounding one person’s multiple touches, and a set of vectors reporting the signal strength of a person’s touches. To illustrate, Figure 4 shows SquiggleDraw, a paint program written in approximately 10 minutes in about 15 lines of code. SquiggleDraw has two interesting properties. • A person adjusts line thickness on the fly. One draws by changing the bounding region of the drawing with two fingers. One draws thin lines by holding their thumb and forefinger close together, and progressively thicker lines by spreading their fingers apart. • Up to four people can draw simultaneously, with each person’s lines appearing in a different color. Because of the availability of both the SDGToolkit and the DiamondTouch Toolkit, many other students in our laboratory are now working on single display groupware. Some are concentrating on quite serious research projects, and are rapidly implementing ideas just to test them out. Others are ‘dabbling’ for their own curiosity, but are producing fairly interesting systems. For example, student Tony Tang combined

Enhancing Creativity with Groupware Toolkits

7

Fig. 4. Two people using SquiggleDraw.

both the SDGToolkit and the Collabrary to create a tabletop application that handles both co-located and distance-separated participants.

4 Toolkits for Physical User Interfaces In the last few years, researchers have developed groupware designs that include physical user interfaces augmented by computing power. These typically involve ambient displays for showing awareness information, or collaborative physical devices that are controlled by multiple (perhaps distributed) people. While this is an exciting new area, everyday programmers face considerable hurdles if they wish to create even simple physical user interfaces. Most lack the necessary hardware training. Those willing to learn find themselves spending most of their time building and debugging circuit boards, firmware and low-level wire protocols rather than on their physical user interface designs. The problem is that we have not provided programmers with adequate building blocks for rapidly prototyping physical user interfaces. This leaves them in a position similar to early GUI researchers who had to build their widgets from scratch, or to early graphics researchers who had to build their 3D environments by brute force. Given this onerous situation, it is no wonder that most research on physical user interfaces come from top researchers at major university and industrial research laboratories. As with our other areas, our solution was to develop a toolkit for rapid development of physical widgets, or phidgets [8]. Our approach was to provide programmers with pre-packaged hardware devices that can be ‘dropped into’ software applications. This familiar programming paradigm is directly analogous to how graphical user interface (GUI) widgets are programmed. I gave phidgets to undergraduate students with no hardware expertise to see what they could do with them. These typically took the form of a short two week assignment. The results were remarkable. While some students replicated examples of physical user interfaces reported by other researchers, most produced their own innovative designs [8].

8

S. Greenberg

Fig. 5. a) Messenger Frame, b) MC Status, c) Appointment Assistant, and d) FoosWars

A few example of groupware systems they built are illustrated in Figure 5. The first two are physical notification devices attached to MSN Instant Messenger. In Messenger Frame by Mike Hornby-Smith (5a), a contact’s photo is lit up and a sound cue generated as that contact appears online or changes their activity status. One sends a message directly to that contact by touching his photo. In MC Status by Christian Leith (5b), contacts are represented by figurines. Offline figurines face the wall, and online figurines face forward. Touching the area in front of the figurine initiates a message. Appointment Assistant by Zaid Alibhai (5c) is an ambient appointment reminder display that interacts with a user’s on-line calendar to remind them of upcoming appointments. As an appointment approaches, the figure on the top of the display moves along the scale and LEDs light up to further indicate the time remaining before the next appointment. FoosWars by Mike Larke and Mike Clark (5d) is a soccer table for distributed participants. One person plays on the physical table while the other plays over the web. The remote player has a live aerial view of the table captured via a web camera located above the table, and directly manipulates his or her players through use of physical sliders. Other example phidget projects are found at www.cpsc.ucalgary.ca/grouplab/phidgets/gallery.

5 Closing Thoughts Groupware development parallels Gaines’ BRETAM phenomenological model of developments in science technology [7]. The model states that technology-oriented research usually begins with an insightful and creative breakthrough, followed by many (often painful) replications and variations of the idea. Empiricism then occurs when people draw lessons from their experiences and formalize them as useful generalizations. This continues to theory, automation and maturity.

Enhancing Creativity with Groupware Toolkits

9

Within this context, we can now see how groupware toolkits affords creative research. Toolkits make it easier for researchers to create new breakthroughs through rapid prototyping of many new ideas. They let others replicate and evolve ideas reported in the literature. They also let researchers more easily move into empiricism by making it easy to create different versions of testable systems.

References 1. Bederson, B. & Hourcade, J.: Architecture and implementation of a Java package for Multiple Input Devices (MID). HCIL Technical Report No. 9908. (1999) 2. Bier, B. & Freeman, S.: MMM: A user interface architecture for shared editors on a single screen. Proc ACM UIST (1991) 79–86. 3. Boyle, M. and Greenberg, S.: GroupLab Collabrary: A Toolkit for Multimedia Groupware. In J. Patterson (Ed.) ACM CSCW 2002 Workshop on Network Services for Groupware, November (2002) 4. Diaz-Marino, R.A., Tse, E, and Greenberg, S.: Programming for Multiple Touches and Multiple Users: A Toolkit for the DiamondTouch Hardware. Department of Computer Science, University of Calgary, Calgary, Alberta CANADA. June. Includes video (2003) 5. Engelbart, D. and English, W. Research Center for Augmenting Human Intellect, Proc. Fall Joint Computing Conference, AFIPS Press (1968) 395–410 6. Foster, G.: Collaborative Systems and Multi-user Interfaces. PhD Thesis (UCB/CSD 87/326), Computer Science Division (EECS), Univ of California at Berkeley USA (1986) 7. Gaines, B.: Modeling and forecasting the information sciences. Information Sciences 57/58, (1999) 13–22 8. Greenberg, S. and Fitchett, C.: Phidgets: Easy Development of Physical Interfaces through Physical Widgets. Proc ACM UIST (2001) 209–218 9. Greenberg, S., Gutwin, C. and Cockburn, A.: Using Distortion-Oriented Displays to Support Workspace Awareness. In A. Sasse, R. Cunningham, R. Winder (Eds), People and Computers XI (Proc HCI'96) Springer-Verlag (1996) 299–314 10. Greenberg, S. and Roseman, M.: Groupware Toolkits for Synchronous Work. In M. Beaudouin-Lafon, editor, Computer-Supported Cooperative Work (Trends in Software 7), John Wiley & Sons Ltd (1999) 135–168 11. Greenberg, S., Roseman, M., Webster, D. and Bohnet, R.: Human and technical factors of distributed group drawing tools. Interacting with Computers, 4(1) (1992) 364–392 12. Greenberg, S. and Rounding, M.: The Notification Collage: Posting Information to Public and Personal Displays. Proc ACM CHI (2001) 515–521 13. Gutwin, C., Greenberg, S. and Roseman, M.: Workspace Awareness in Real-Time Distributed Groupware: Framework, Widgets and Evaluation. In A. Sasse, R. Cunningham, R. Winder (Eds), People and Computers XI (Proc HCI'96) Springer-Verlag (1996) 281–298 14. Myers, B.: State of the Art in User Interface Software Tools. In R. Baecker, J. Grudin, W. Buxton and S. Greenberg (Eds) Readings in Human Computer Interaction: Towards the Year 2000. Morgan Kaufmann (1995) 323–343 15. Sarin, S. Interactive On-Line Conferences, PhD thesis, MIT/LCS/TR330, MIT USA (1984) 16. Stewart, J., Bederson, B. and Druin, A.: Single display groupware: a Model for Co-present Collaboration, Proc ACM CHI (1999) 286–293 17. Tang, J.C.: Findings from observational studies of collaborative work. International Journal of Man Machine Studies, 34(2), Academic Press (1991) 143–160. 18. Tse, E. and Greenberg, S.: Rapidly Prototyping Single Display Groupware through the SDGToolkit. Report 2003-721-24 Computer Science, University of Calgary, Canada (2003) 19. Zanella, A. and Greenberg, S.: (2001) Reducing Interference in Single Display Groupware through Transparency. Proc ECSCW, Kluwer (2001).

MARS: Modelling Arenas to Regulate Collaborative Spaces Carmen Mezura-Godoy1, , Michel Riveill2 , and Stephane Talbot1 1

2

SysCom Team Savoie University, Campus Scientiﬁque 73376, Bourget du Lac, France {cmezu,stalb}@univ-savoie.fr I3S Lab., Nice-Sophia Antipolis University ESSI Building, BP 145 06903 Sophia Antipolis Cedex, France [email protected]

Abstract. Social regulation is the process by which a workgroup create and negotiate rules controlling their collaborative activities. Although regulation is an intrinsic aspect of collaborative work, most existing contributions ignore it, and in the cases where regulation is considered, it is conﬁned to a single workspace. This paper proposes the MARS regulation model which enables users to deﬁne their workspace (arena) and the rules governing it. A key feature of this model is that it allows one to create complex arenas by composing simple ones. In order to validate our approach, a java-based prototype supporting the MARS model has been implemented. This prototype ensures that the group activity is executed according to the current regulation.

1

Introduction

In order to carry out a joint activity, members of a group collaborate. Collaboration takes several forms: (a) persons communicate constantly with each other in order to exchange their ideas or points of view, (b) they share information or their workspace and (c) they coordinate their activity (time, space and resources). These aspects are strongly attached to the social organisation of the work group and imply rules to control its activity. In Sociology, social regulation is the process which enables groups to create and modify social rules controlling their individual and collective actions[5]. Regulation enables people to describe how they wish to take part in the activity and the minimal conditions of work’s execution; in other words, it enables people to create, negotiate and apply rules controlling their collaborative activity. Regulation does not imply a complete description of an activity, but rather a deﬁnition of minimal rules, and personal rights and responsibilities, in order to improve the group activity. Regulation is attached to the natural evolution of the activity; so, the work rules change along with the activity.

Supported by the CONACyT of the Mexican Government.

J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 10–25, 2003. c Springer-Verlag Berlin Heidelberg 2003

MARS: Modelling Arenas to Regulate Collaborative Spaces

11

Nowadays, groupware tools supporting collaborative work enable users to communicate [19,6,3,14,20], to coordinate [13,1,24,23] and to cooperate in speciﬁc tasks [21,25,16]. Nevertheless, these tools rarely incorporate social activity aspects. Moreover, they do not enable users to regulate their activity. A ﬁrst eﬀort to incorporate regulation aspects in groupware tools was done by Martel et al [8]. This work proposed a regulation model for collaborative activities, called ”participation model”. This model allows the deﬁnition of an activity inside a workspace called an ”arena”. In the arena are placed all the activity’s components: the persons that take part in the activity and which are identiﬁed by a social role, the tools allowing carry out the activity, the objects produced and handled during the activity, the scenarios expressing how an activity can carry out, and also personal information (status and preferences) expressing with whom people wish to collaborate or with which tool they want to work. This model was implemented in a drawing tool [9], that allows children to draw according to the rules established by the teachers. An important limitation of this work is that it only considers possible to deﬁne activities in a single workspace, i.e an arena. Nevertheless, we can observe that people collaborate in several activities at the same time. For instance, members of a research team take part in meetings, in projects, in paper writing, etc., so people take part in several arenas. For this reason, we propose to develop groupware applications supporting multi-arena work group, as a cooperation of several single arenas. We consider important to include a model activity in groupware applications. We propose for that a new multi-arena regulation model for groupware design. This new model enables developers of groupware applications to create new regulated applications from simple ones. In order to illustrate our approach, let us imagine the following scenario: we want to develop a collaborative writing application enabling users to write a paper together and also enable them to access university library, to facilitate the paper’s documentation. We can represent the application’s supporting model in a ”writing arena”, which cooperates with other two arenas, the ﬁrst one specialized in ”text writing” (a writing tool) and the second one specialized in ”book borrowing” (the university library). This cooperation between arenas must enable to create a more complex and richer application from existing ones. This paper proposes MARS, a regulation multi-arena model that enables developers to design and implement regulated groupware tools. In order to validate our model we implemented a software prototype. It illustrates how several regulated applications can be assembled in order to create more complex applications. The rest of the paper is organized as follows. Section 2 surveys related work to establish the context of our research. Section 3 describes the MARS regulation model. Section 4 present some scenarios showing model applications. Section 5 introduces our experimental software prototype. Finally section 6 summarizes the contributions of this paper and introduce some research directions.

12

2

C. Mezura-Godoy, M. Riveill, and S. Talbot

Related Work

We can classify research works introducing social aspects in groupware into three diﬀerent areas : (i) coordination systems, (ii) workﬂow models, and (iii) social activity models. 2.1

Coordination Systems

Intermezzo[7], COCA[15] and DCWPL[4], oﬀer infrastructures allowing the introduction of social aspects in groupware tools, under the term ”coordination policies”. These policies enable to coordinate an activity in terms of access control to the production groupware space (private or shared workspace). Even though, these systems oﬀer the means to incorporate social aspects of an activity work (participants, roles, policies, rights). However, social aspects are deﬁned at a low level of abstraction (coordination language). In order to enable users to deﬁne their activity, we believe that it is necessary to provide them with more powerful mechanisms to facilitate the deﬁnition of social aspects of collaborative activities. Moreover, the models proposed by these systems focus only coordination aspects, rather than on the complete collaborative activity. For instance, the role concept is used to control access to shared resources (production space). For us, role is a collaboration concept: an actor in the activity has a particular role in the group (e.g. leader, coordinator, etc.). The role is then a social concept in model’s activity, rather than a computational concept. 2.2

Workﬂow Models

In order to coordinate their activity, people can use workﬂow technologies. Workﬂow systems enable the modelling and distribution of tasks, and the automation of document ﬂow in collaborations. When an activity is complex, it is useful to produce an explicit representation to guide and support its execution. Unfortunately, though workﬂow systems are easy to use in very rigid procedures, they are not ﬂexible enough to allow people to modify or to adapt the representation of the activity during its execution. In order to coordinate cooperative procedures, this rigidity is not acceptable. This is because, collaboration implies the voluntary and spontaneous participation of people, and it also implies the modiﬁcations of the activity during its execution. Research contributions in workﬂow ﬂexibility like 2Flow [22], GPSG [11], and COO [12] propose diﬀerent approaches (component design and implementation, grammatical rules and anticipation of activities) allowing workﬂow to become usable for coordination in groupware. This works model social coordination such as task distribution and object handling during tasks. However other aspects of regulation are not included, like the possibility of enabling users to deﬁne their preferences and desires, i.e. their real engagement in the group activity.

MARS: Modelling Arenas to Regulate Collaborative Spaces

2.3

13

Activity Models

In the works previously cited social aspects are limited to activity coordination. So, the models they propose are focused on the coordination aspect of collaborative work. We believe that a model for collaborative activities must allow the deﬁnition of the activity and its context, which means enabling users to deﬁne group members taking part in the activity (their duties, rights and preferences), their social role, tools to facilitate doing their activity, and naturally groupwork rules. Including a complete model of the activity in groupware can aid end-users to use them better and adopt them more easily. Works like, Worlds [10], DARE [2], as well as participation model(PM) [8] propose activity models for groupware applications. These models are founded in works in social sciences and they oﬀer concepts enabling users to deﬁne a group activity in a workspace. This workspace called, a ”locale”(Worlds), ”support of activity”(DARE) or ”arena”(PM), represents the group’s activity and its context, i.e it has the activity components and it establishes necessary conditions for the activity execution. All these works take into account the evolutionary aspect of a group activity. Worlds and DARE are based on reﬂexive models to enable users to modify the activity model in run time. DARE and PM consider redeﬁnition of the activity as part of the activity itself. An activity model must also make it possible to improve the design of groupware applications and, consequently allow users to better use them. Nevertheless, Worlds and DARE do not consider social aspects of activities, like people engagement in the activity and social work rules as PM does. Even though, the PM oﬀers a social regulation model of collaborative activity, none of them enables the idea of ”reusing” deﬁned spaces in order to create more complex collaborative spaces.

3

The MARS Regulation Model and Associated Operators

In this section we present, the MARS Multi-Arena Regulation model [18]. This model (inspired from PM[8]) allows one to represent regulated group activities supported by groupware tools. MARS model considers the interaction as the basic building block of an activity. An interaction represents regulated actions carried out by members of a group inside an arena, but interactions distributed across several arenas. 3.1

Elementary Concepts

A group activity is deﬁned by interactions taking place in a collaboration space called arena. The users executing interactions are called actors. An actor represents a person, a software agent or a group. Throughout an activity, the actors handle and produce objects, such as documents, ﬁles, notes, etc. A family

14

C. Mezura-Godoy, M. Riveill, and S. Talbot

groups actors or objects having the same set of features (e.g. ”writers”, ”readers”, ”books”, or ”papers” families). During the activity, actors and objects plays diﬀerent roles, depending on the speciﬁc interaction they execute or take part. For instance during the ”writing” interaction an actor plays the ”writer” role, and the object handled in this interaction plays the ”draft” role. In order to regulate their activity, actors deﬁne scenarios for each interaction. A scenario describes how an interaction is carried out (operations or interactions that must be executed), who can participate in the interaction, and what objects can be handle. The scenarios represent the social protocols taking place in the arena. An interaction can be executed in several forms, each one described in a diﬀerent scenario. For instance, in a ”meeting arena”, the voting interaction can be executed following three scenarios: ”vote by showing hands”, ”secret vote”, or by ”proxy vote”. In the following let A, O, R, S, AF and OF , be the sets of actors, objects, roles, scenarios, actors family and objects family respectively, and α and β two functions returning respectively the family of an actor or an object. 3.2

Interaction and Arena

An ”interaction model” deﬁnes a regulated interaction inside the arena. It speciﬁes all the actors’ and objects’ families taking part in the interaction, roles attributable to actors and objects during the interaction, and the scenarios describing how the interaction can be carry out. Deﬁnition 1 (Interaction Model) An interaction model is a tuple < nI , E, Af , Of , Rs , Ss , π, ρ >, where nI is the name of the interaction, E is a set of interaction states, Af ⊆ AF , Of ⊆ OF , Rs ⊆ R, Ss ⊆ S, π is a relation from Af → Rs and ρ is a relation from Of → Rs

Let us imagine the model for the interaction ”to borrow” deﬁned as follows: < toBorrow, {active, f inished}, {student, teacher}, {book}, {borrower, borrowed}, {scenario T o Borrow}, {( student, borrower), (teacher, borrower)}, {(book, borrowed)} >1 . This model authorize the ”to borrow” interaction to ”teachers” and ”students”, it limits the objects handled in this interaction to ”books”, it deﬁnes the ”borrower” role assigned to teachers and students and the ”borrewed” role assigned to the books. It speciﬁes the ”scenarioToBorrow” as the only scenario describing how this interaction can be carried out. An ”interaction”, represents an interaction in execution. An interaction must always be according to an interaction’s model. Deﬁnition 2 (Interaction) Given an interaction model < nI , E, Af , Of , Rs , Ss , π, ρ >, an interaction is a tuple < nI , e, A, O, s, σ, ω >, where, nI is the name of the interaction, e ∈ E, 1

We identify in all our examples, actors, objects, roles, scenarios, interaction’s models and interaction instances by their name.

MARS: Modelling Arenas to Regulate Collaborative Spaces

15

A ⊆ A and ∀a ∈ Aα(a) ∈ Af , O ⊆ O and ∀o ∈ Oβ(o) ∈ Of , s ∈ Ss , σ is a relation from A → Rs , and ω is a relation from O → Rs . An interaction representing the actor ”carmen” borrowing the ”javaBeans” book in the library’s arena could be the following: < toBorrow1 , active, carmen, javaBeans, (carmen, borrower), (javaBeans, borrowed) >. Deﬁnition 3 (Arena) An arena is a tuple < nE , As , Os , Ms Is >, where nE is the name of the arena, As ∈ A, Os ∈ O, Ms is a set of interaction models and Is is a set of interactions.

An example of a library arena is the following: < universityLibraryX, {car men, stephane}, {java Beans, corba, xml}, {toBorrowIntM, toReturnIntM }, {toBorrow1 , toBorrow2 } > where universityLibraryX is the name of the arena, ”carmen” and ”stephane” are the actors who can perform interactions in this arena, ”javaBeans”, ”corba”, ”xml” are the accessible books and ”toBorrow1 ” ”toBorrow2 ” are the running interactions. 3.3

View and Complex Arena

As deﬁned above, a collaborative activity is deﬁned inside an arena. Nevertheless, members of a work group do not collaborate only within a unique group of people, nor within only one activity. People take part in several activities in diﬀerent spaces, i.e. several arenas. For instance the members of a research team collaborate at the same time on projects, on writing articles or documents, on the organization of conferences or work meetings, etc. Each of these collaborative spaces is controlled by speciﬁc work rules associated with the activities these spaces contain and deﬁned by the group. Let us consider now that each of these activities can be deﬁned in an arena: it can thus be useful, even necessary, to make these arenas ”cooperate” in order to take into account the relationships between the activities, they represent. In order to make this ”cooperation” possible, we introduce the view concept (cf. Fig. 1). A ”view” groups, actors, objects and interactions that an arena can share with another.

11 00 00 11 00 11 00 11 00 11 Arenax

View

11 00 00 11 00 11 00 11 00 11 00 11 00 11 00 11 11 00 00 11 11 11 00 00 00 11 00 11 00 11

Fig. 1. Cooperation between arenas via the use of views.

Arenay

16

C. Mezura-Godoy, M. Riveill, and S. Talbot

Deﬁnition 4 (View) Given an arena < nE , As , Os , Ms , Is >, a view is a tuple < nE , Av , Ov , mv >, where nE is the name of the arena that produce the view, Av ⊆ As , Ov ⊆ Os and mv ⊆ Ms . Let us imagine, that two universities’ libraries will cooperate to make their books accessible to each other. The university library located at site ”X”, produces a view with the objects it will share with the library located at site ”Y”. The view deﬁned by arena ”X” is: < {michel, edgard}, {c++, prolog}, toBorrow IntM >, where ”toBorrowIntM” is the interaction that will be accessible from ”Y”, ”michel” and ”edgard” are the actors with the possibility of borrowing books from the site Y, and ”c++” and ”prolog” are the books from site ”X” accessible for all the students and professors from site Y. Arenas importing ”remote” objects from other arenas are called ”complex arenas”. Deﬁnition 5 (Complex Arena) Given an arena < nX , As , Os , M s , Is > and a view< nY , Av , Ov , mv >, a complex arena is a tuple < nX , As Av , Os Ov , Ms mv , Is >. The universityLibraryX is an example of a complex arena because it imported remote objects from the universityLibraryY: < universityLibraryX, {carmen, stephane, michel, edgard, }, {java Beans, corba, xml, c + +, prolog}, {toBorrowIntM, toRetourn IntM }, toBorrow1 , toBorrow2 >. 3.4

Arena’s and View’s Operators

The arenas evolve according to the creation and the execution of interactions. For this reason, we deﬁned operators which allow to manage arena and view objects. Each of these operators ensures the passage of an arena or a view from one coherent state to another, always respecting the arena regulation. Table 1 summarizes the operations to allow adding and removing actors, objects, interaction models and interactions to/from an arena. We also deﬁned operators allowing the same operations for views [17]. Table 1. Operators enabling the addition and deletion of actors, objects, interactions and model interactions to/from arenas. Operator addActor deleteActor addRobject deleteRobject addModelInteraction deleteModelInteraction addInteraction addInteraction

Enter (E, a) (E, a) (E, o) (E, o) (E, m) (E, m) (E, i) (E, i)

Exit E = (n, A {a}, O, I, M ) E = (n, A − {a}, O, I, M ) E = (n, A, O {o}, I, M ) E = (n, A, O − {o}, I, M ) E = nE , A, O, I, M {m}) E = (nE , A, O, I, M − {m}) E = (nE , A, O, I i, M ) E = (nE , A, O, I − {i}, M )

MARS: Modelling Arenas to Regulate Collaborative Spaces

17

We deﬁned two operations to enable to cooperate arenas. These operators allow them to share their objects by export and import views. Operator 1 (Export View.) Given an arena E =< n, A, O, I, M >, a set Av ⊆ A, a set Ov ⊆ O and a set Mv ⊆ M , the result of ExportV iew(n, Av , Ov , Mv ), is the following view V =< n, Av , Ov , Mv >. Operator 2 (Import View.) Av , Ov , Mv ), the reGiven an arena E =< nx , A, O, I, M >, and a view V= (ny , sult of ImportV iew(E, V ) is an arena E =< nx , A Av , O Ov , I, M Mv >.

Consider the following ”writing arena”: writingArena =< {carmen, michel, stephane}, {crigw03Article}, {toW riteM Int, toReviewM Int}, {toW ri te1 , toW rite2 } >. This arena deﬁnes an space for joint paper’s writing. Inside this arena, ”carmen”, ”michel” and ”stephane” can ”write” and ”review” a paper for the Criwg03 workshop. Now, we want to enable these actors to access the univertisty library, in order to ease the paper’s documentation. For that, the ”universityLibraryX” exports a view (with actors, objects and interaction) to the ”writing arena”, as the following: ExportV iew =< universityLibraryX, {carmen, stephane, michel}, {cscw02, criwg02, ciwg01}, toBorrowM int >. The operation ImportV iew adds to the ”writing arena” the objects of the library’s view. The new ”writing arena” is: < writingArena , {carmen, michel stephane}, {crigw03Article, cscw02, criwg02, ciwg01}, {toW riteM Int, toReviewM Int, toBorrowM Int}, {toW rite1 , toW rite2 } >. As we can see, in a multi-arena context, arenas have ”local” and ”remote” objects. So, in order to enable arenas handling with remote objects a propagation of operators is then necessary. We identiﬁed several constraints that must be satisﬁed during the application of the operators in order to ensure coherence between arenas. For instance, for the addition of one interaction (addInteraction) in an importing arena, ArenaImp, if the objects handled in the interaction are ”local” the regulation to apply is the local one, so the operator addInteraction is done normally (cf. table 1). But, if the objects are ”remote”, it is necessary to apply the regulation of the exported arena ArenaExp, so it is necessary to propagate the operation. In order to ensure the application of remote regulation, we deﬁned certain rules which determine the cooperation between arenas to control interactions shared between arenas. For instance, the following rule determines the case of adding an interaction in ArenaImp.

18

C. Mezura-Godoy, M. Riveill, and S. Talbot

Rule : WHEN operation to do is addInteraction(ArenaImp, i) IF ∃o ∈ i such origin(o) = view ∃ArenaExp = origin(view) isP ossibleInteraction(ArenaExp, i) = true THEN addInteraction(ArenaImp, i) addInteraction(ArenaExp, i) This rule states that when the operation to do is addInteraction in ArenaImp, it is necessary to know: (i) if the origin of objects taking part in the interaction is a view, (ii) the origin of the view (ArenaExp) and (iii) and if it is possible to add the interaction in ArenaExp. The function ”isPossibleInteraction” indicates the possibility of creating an interaction in ArenaExp. If the remote regulation makes possible to carry out the interaction, a new interaction is added in both arenas.

4

Multi-arena Scenarios

In this section we explore diﬀerent collaborative deﬁnitions of group activities. The goal here is to demonstrate how an activity supported by a groupware can be deﬁned using the MARS model. The ﬁrst scenario illustrates the deﬁnition of an arena and their elementary concepts like actors, object, roles, scenarios and interactions. The second one shows complex arena composition, by introducing the view concept. 4.1

Scenario 1: Collaborative Writing

This scenario consists in deﬁning a collaborative writing activity. Let us suppose that we have a text editor tool at our disposal. This tool oﬀers basic editing functions like: open, save, copy, cut, etc. and also functions to manage ﬁle’s versions. We design a regulated arena called ”writing arena” supported by this tool, allowing users to write a document together, for instance a paper, a project, a report, etc. Table 2 summarizes the ”writing arena” components. The ”to write” interaction enable users only to write text and the ”to review” interaction enable users to make remarks or notes into the document. Actors are ”main” or ”second authors” and objects are ”documents” (composed by sections). The interactions are deﬁned as follows: the ”to write” interaction can be executed only by ”main author”, the handled object is a ”document”. This interaction deﬁne the ”writer” role for actors and the ”inDraft” role for objects. The scenario describing how this interaction can be carry out is ”scWriting”, which states that the ”to write” interaction can be ”executed by two persons at the same time, only if they don’t access the same section. The ”to review”

MARS: Modelling Arenas to Regulate Collaborative Spaces

19

Table 2. Collaborative writing arena’s components. Component Properties Domaine Actor actorFamily {main/second author} name String Object objectFamily document name String paragraphs Object: section ”to write” actorFamily main author objectFamily document scenario scWriting actorRole writer ObjectRole inDraft ”to review” actorFamily second author objetFamily document scenario scReviwing actorRole reviewer objectRole inReview

interaction can be executed by the ”second author”, the object in this interaction is also the ”document”, the role for the actor executing this interaction is ”reviewer” and the role for the object is ”inReview”. The scenario for this interaction states that only one user can execute this interaction, and also that this interaction can be performed at the same time that ”to write” one. The text editing tool functions can be wrapped as interactions. For instance, the copy, save, or open ﬁle functions are wrapped as the ”to write” interaction. And the open, save and insert note functions are wrapped as the ”to review” interaction (see[17] for details). 4.2

Scenario 2: Collaborative University Libraries

This scenario illustrates the composition of complex arenas. Let us imagine that two universities libraries wish to share their collections with the goal of making a larger number of their books accessible. Both libraries are deﬁned with the same arena model. Only two interactions can be executed in the libraries: ”to borrow” a book and ”to return” the borrowed book. The ”to borrow” interaction enables users to order the order the delivery of the book to the user’s geographical address, while the ”to return” interaction enables the personal responsible for the library’s administration system to register the book’s return. Table 3 summarizes the components of the library arena. The interactions are deﬁned as follows. The ”to borrow” interaction can be executed by ”students” and ”teachers”, its objects are ”books”, the actor’s role is ”borrower” and the object’s role is ”inBorrow”. The scenario describing how this interaction can be performed is ”scBorrowing”, which enables the actors to borrow available books, and states that the period for borrowing a book is a month for students and two weeks for teachers. The ”to return” interaction

20

C. Mezura-Godoy, M. Riveill, and S. Talbot Table 3. University’s library arena. Component Properties Domaine actor actorFamily {student, teacher, administrator library} name String object objectFamily book name String ”to borrow” actorFamily {student, teacher} objectFamily book scenario {scToBorrow, actorRole borrower objectRole inBorrow ”to return” actorFamily administrator library objectFamily book scenario scReturning actorRole librarian objectRole inReturn

can be executed by the librarian and its objects are ”books”. The actor’s role is ”librarian” and the object’s role is ”inReturn”. The scenario describing how to perform this interaction is ”scReturning”, which speciﬁes that this interaction can be executed only if there is in the arena an interaction of borrowing of the same book. In order to enable universities libraries to share theirs books, actors and interactions, it is necessary to deﬁne their views. A library view speciﬁes which interactions (to borrow) and objects (books) can be executed and handled from the other library, and also which actors (students) can execute them. Table 4. Exported view between university library arenas. View Component viewLibrary actor object interaction model

Domain {student} books ”to borrow”

As the same model of arena is deﬁned for both libraries, (i.e., the arenas have the same interaction model and the same object and actor families); it is necessary to distinguee the procedure to be followed when the objects and actors taking part in the ”to borrow” interaction are local or remote (they were exported). For that, we included a property called ”origin” in the deﬁnition of actors and objects. We also redeﬁned ”scToBorrow” scenario, in two diﬀerent scenarios, ”scToBorrowLocal” and ”scToBorrowRemote”. The ”scToBorrowLocal” scenario describes the execution of the interaction when it only includes local objects or actors, so the interaction is local. The ”scToBorrowRemote”

MARS: Modelling Arenas to Regulate Collaborative Spaces

21

scenario describes the execution of the interaction when it includes remote objects, this execution includes the propagation of the interaction to the exported arena for its remote execution. As in the case of text editing tool, the functions of the administration library system can be wrapped as interactions. For instance, the functions that enable the borrowing of books, like, searchBook() and addBorrow(), are wrapped as the ”to borrow” interaction, while the function deleteBorrow() is wrapped as the ”to return” interaction.

5

Prototype

In order to demonstrate the feasibility of our approach, we have developed a java-based prototype implementing the MARS model. It allows to connect two regulated library applications in order to make available to its users all or some books from the other library and to control the interactions oﬀered. We suppose that only one library is located in Chambery city and the other in Grenoble city. The libraries have the arena model presented in section 4. The users of each library can in a transparent borrow books from their library but also books from the other. As each library has diﬀerent operation rules (e.g. periods of borrowing or penalisations), the operations carried out on the books must be done by respecting the regulation of the arena where the books were exported from. The interactions to be controlled in these arenas are limited to ”borrowing” and to ”returning” books. 5.1

Architecture

Figure 2 shows the prototype architecture. It is inspired by the generic regulated architecture proposed in[17]. Each library application is composed of a functional core (the library system), a regulation layer that supports the collaborative activity (the arena), a wrapper and a user interface. Both libraries communicate with each other, to share their regulation components (actors, objects and interactions) and to control interactions comprising remote books. User Interface. It enables users to access to the library site and to request the ”to borrow” and ”to return” interactions. In order to make a request, a user types her/his name, ﬁrst name and the book ISBN. The user interface transmit then this information to the wrapper and notiﬁes users of the success or failure of interactions. Functional Core. It is the core functionalities oﬀered by the library system such as consultation and update of the catalogue of books (searchBook(), add/deleteBook()) and the catalogue of users (searchUser(), add/deleteUser()), and add and delete in the data base library (add/deleteBorrow()).

22

C. Mezura-Godoy, M. Riveill, and S. Talbot Chambery Library

Adminis tration tool

init config

User

init config

export/import Regulation Layer

Regulation Layer interaction’s control

users’ request

interface

Grenoble Library

Adminis tration tool

interaction execution Wrapper

Wrapper

User interface

function execution

Functional Core

Functional Core

Fig. 2. Library’s prototype architecture.

Wrapper. It wraps the functionalities oﬀered by the library system as interactions (regulated operations). For instance, searchUserInfo() and addBorrow() are wrapped as the ”to borrow” interaction, and deleteBorrow() as the ”to return” interaction. The wrapper transfers to the regulation layer the information from the user interface (interaction request, who makes the interaction and with which object) to control the interaction. It also executes the functions associated to an interaction when the regulation layer request to do it. Regulation Layer. It is responsible for the application of the arena’s regulation (interaction control). It authorizes the execution of the interactions according to the scenarios. For that, it evaluates the information (interaction, actor and object) from the wrapper, and executes the procedure deﬁned in the scenarios. In order to apply arenas regulation, we have divided the regulation layer functionalities in three components: (i) an arena manager, (ii) a regulation engine, and (iii) a view manager. The arena manager creates the arena and all its components (actors, objects, roles, scenarios) and their relationships. The regulation engine creates, deletes, up-dates and executes interactions (according to the scenarios). For that, it applies operators rules. So, it must verify the origin of the objects taking part in the interaction in order to know what regulation need to be applied (local or remote). If the interaction concerns remote objects, the regulation engine must send the interaction to the other library. In the other library, the regulation engine must apply its own regulation, verifying for instance if the book is available, if the user is not penalised for previous loans, etc. If the remote regulation enables this interaction to be done, an interaction must be created in both arenas. When the return of the book is made, the ”to borrow” interaction can be deleted in both arenas. The view manager, produces and exports arenas views. It also adds to the arena the objects of the imported view.

MARS: Modelling Arenas to Regulate Collaborative Spaces

5.2

23

Example: Borrowing an Imported Book

Let us imagine, that the actor ”carmen” wishes ”to borrow” the ”javaBeans” book at the Chambery’s library. Carmen is a student at the Chambery University and the javaBeans book was imported from the Grenoble University library. Carmen accesses the library from Chambery site, and types her name and the book ISBN on the user interface. The wrapper receives this information, transforms it into regulation information(interaction, actor and object) and transmits it to the regulation layer. The regulation layer regulate the interaction and control its execution according to the scenarios. For that, it must identify the regulation to apply (local or remote). It veriﬁes the origin of actor and object. In this case ”carmen” is a local actor, but the ”javaBeans” is a remote book. So, this interaction must be executed in the other library. For that, the Chambery’s library sends the interaction request to the other library. When Grenoble’s library receives the request, it veriﬁes the local conditions to execute this interaction (local regulation). If the book is available, and ”carmen” can execute this interaction (she is not penalised) a new interaction is created in both libraries. Then, the regulation layer of the Grenoble library order the wrapper to execute the functions making possible to deliver the book (searchUserInfo(), addBorrow()). Finally, the wrapper notiﬁes ”carmen” the success of the interaction. A couple of days later, she receives the book at her address.

6

Conclusion and Future Work

Regulation is a natural social aspect of collaboration. In order to collaborate, people need to establish minimal rules, personal rights, preferences, availabilities and responsibilities in order to carry out their activity. Nevertheless, groupware tools rarely incorporate regulation. We believe, that if groupware applications are made to support group activities, they must consider the model of this activity. This has two advantages: on the one hand, it facilitate developers the implementation of these applications and, on the other hand, it enables end-users to better adapt and use them This paper proposed MARS, a multi-arena regulation model. This model enables to deﬁne the necessary interactions to carry out an activity in a single arena, but also it enables to deﬁne interactions taking place in several arenas. In order to support interactions placed in several arenas, we proposed the view and the arena complex concepts to enable arena to cooperate. A view enables the arenas to share (by export and import operations) their objects in order to make more complex and rich applications. We also proposed several operators that enable handling objects in arenas and views. In order to validate our approach, we implemented a java-based prototype. This prototype implements the multi-arena regulation model and control interactions according to arena regulation. It allows to incorporate application functions in terms of interactions. This architecture shows a regulated application composed by a regulation and a function layer, connecting by a wrapper.

24

C. Mezura-Godoy, M. Riveill, and S. Talbot

A limitation of our model is that currently, the deﬁnition of scenarios is simple. They are represented as a set of pre-conditions (specifying the actors and objects that can take part in the associated interaction) and a sequence of possible actions. Our future work includes modelling scenarios in a more detailed way in order to regulate complex interactions. Scenarios must also be modelled in a ﬂexible way to enable end-users to modify them at run time. Acknowledgements. We wish to thank the anonymous referies of this paper for theirs useful comments. We also thank Thomas Coutelen for his contribution to the MARS prototype development.

References 1. W. Appelt and P. Mambrey. Experiences with the BSCW Shared Workspace System as the Backbone of a Virtual Learning Environment for Students. In World Conference on Educational Multimedia, Hypermedia and Telecommunications, EDMEDIA’99, Seattle, June 1999. 2. G. Bourguin and A. Derycke. A Reﬂective CSCL Environment with Foundations Based on the Activity Theory. In Fifth International Conference on Intelligent Tutoring Systems ITS’2000, pages 272–281, Montreal, Canada, June 2000. 3. Cartable Electronique, 2003. http://www.univ-savoie.fr/Portail. 4. M. Cortez and P. Mishra. DCWPL : A programming Language for Describing Collaboration Work. In ACM Conference on Computer Supported Cooperative Work, CSCW’96, Cambridge MA, USA, November 1996. 5. J. Couet and A. Davie. Dictionnaire de l’essentiel en sociologie. Edition Liris, Paris, France, 1998. 6. Cuseeme, 1998. http://cu-seeme.cornell.edu. 7. W. K. Edwards. Policies and Roles in Collaborative Applications. In ACM Conference on Computer Supported Cooperative Work, CSCW’96, Cambridge MA, USA, November 1996. 8. C. Ferraris and C. Martel. Regulation in Groupware: the Example of a Collaboration Drawing Tool for Young Children. In Sixth International Workshop on Groupware, CRIWG’00, Madeira, Portugal, October 2000. 9. C. Ferraris, C. Martel, and P. Brunier. Drawing Together in the Classroom: an Application of the cartable ´electronique (r) Project. In 13th World Conference on Educational Multimedia, Hypermedia and Telecommunications (Ed-Media 2001), Tampere, Finland, June 2001. 10. G. Fitzpatrick, W. J. Tolone, and S. M. Kaplan. Locales and Distributed Social Worlds. In Proceedings of Fourth European Computer Supported Cooperative Work, ECSCW’95, Stockholm, Sweden, September 1995. 11. N. S. Glance, D. S. Pagani, and R. Pareschi. Generalized Process Structure Grammars (GPSG) for ﬂexible Representation of Work. In ACM Conference on Computer Supported Cooperative Work, CSCW’96, Cambridge MA, USA, November 1996. 12. C. Godart, O. Perrin, and H. Skaf. COO: a workﬂow operator to improve cooperative modelling in virtual process. In Ninth International Workshop on Research Issues on Data Engineering: Information Technology for Virtual Enterprises RIDE-VE’99, Sydney, Australia, March 1999.

MARS: Modelling Arenas to Regulate Collaborative Spaces

25

13. A. Grasso, J.-L. Meunier, D. Pagani, and R. Pareshi. Distributed coordination on the world wide web. Computer Supported Cooperative Work: The Journal of Collaborative Computing, 6(2-3):175–200, 1997. 14. S. Greenberg and M. Rounding. The Notiﬁcation Collage: Posting Information to Public and Personal Display. In ACM Conference on Human Factor in Computing Systems, Seattle, USA, Mars 2001. 15. D. Li and R. R. Muntz. COCA : Collaborative Objects Coordination Architecture. In ACM Conference on Computer Supported Cooperative Work, CSCW’98, Seattle WA, USA, November 1998. 16. D. McKechan and C. Allison. Design Consideration for Creditor: A Collaborative Report Writing Editor. In ACM SIGGROUP’01, Third Annual Collaborative Editing Workshop, 2001. 17. C. Mezura. An architecture to support social regulation in groupware. Technical report, Communicants Systems Team, Savoie University, Mars 2003. 18. C. Mezura-Godoy and S. Talbot. Towards Social Regulation in ComputerSupported Collaborative Work. In Seventh International Workshop on Groupware, CRIWG’01, Darmstadt, Germany, September 2001. IEEE Press. 19. Ms NetMeeting, 2003. http://www.microsoft.com/netmeeting. 20. C. Neustaedter, S. Greenberg, and S. Carpendale. IMVis: Instant Messenger Visualization. In ACM Conference on Computer Supported Work, New Orleans, USA, November 2002. 21. M. Romero and D. Decouchant. Structured Cooperative Authoring for the World Wide Web. Computer Supported Cooperative Work: The Journal of Collaborative Computing, 1997. 22. K. Sa¨ıkali and B. David. Using Workﬂow for Coordination in Groupware Applications. In Human Computer Interaction HIC’2001, Lille, France, September 2001. 23. C. Steinﬁed, C.-Y. Jang, and B. Pfaﬀ. Supporting Virtual Team Collaboration: the TeamSCOPE System. In GROUP’99, International Conference on Supporting Group Work, 1999. 24. Toxic farm, 2003. http://woinville.loria.fr/nToxic/php/. 25. J. Whitehead and Y. Y. Goland. WebDAV: A network authoring on the web. In Proceedings of the Sixth European Conference on Computer Supported Cooperative Work, ECSCW’99, Copenhagen, Denmark, 1999. Kluwer Academic Publisher.

Transparent Latecomer Support for Synchronous Groupware Stephan Lukosch University of Hagen Computer Science II – Cooperative Systems 58084 Hagen, Germany [email protected]

Abstract. In a collaborative session users may join and leave. A user who joins a session is called a latecomer. A latecomer needs the current state of the collaborative session to participate in the session. There exist diﬀerent approaches to accommodate a latecomer. The runtime system can, e.g., transfer the state to the latecomer or replay how the session state was reached. If the state is maintained on a well-known server, it is quite simple to supply the latecomer with the current state. However, if the server is not available, the latecomer cannot join. To increase the fault-tolerance, the runtime system has to use a decentralized approach. In this case, race conditions must be taken into account. DreamObjects is a platform that simpliﬁes the development of shared data objects. It supports a direct state transfer as well as a replay and lets a latecomer choose how to join a session. Both approaches are completely integrated in the runtime system, work completely decentralized, and do not block the other participants in their current work.

1

Introduction

Synchronous groupware is a technology that facilitates teamwork. It supports the communication and coordination between team members who are geographically distributed, but connected via a network. It encompasses a wide range of applications like collaborative whiteboards, text editors or Web browsers. These applications have to share a common state to enable collaboration. Normally, one user starts a collaborative session and other users join it. A user who joins a session is called latecomer. A latecomer needs the current shared state to participate in the session. Lauwers and Lantz [8] discuss some basic mechanisms that allow a latecomer to join a session and provide the latecomer with the current state. A latecomer can join a session with a replay of how the current state was reached. The basic idea of this mechanism is to log all modifying events in a history list. When a latecomer joins the session, this history list is replayed to bring the latecomer up-to-date. However, if, e.g., an event depends on external information, it may not be possible to replay the log correctly. In addition to this, histories can require a lot of memory space and replaying can be time-consuming. Compared to a replay, the direct state transfer provides a faster J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 26–41, 2003. c Springer-Verlag Berlin Heidelberg 2003

Transparent Latecomer Support for Synchronous Groupware

27

way to bring the latecomer up-to-date, as the shared state is directly transferred from a supporting site to the latecomer’s site. As long as the shared state is maintained on a well-known site, it is simple to support the latecomer with the current state. As soon as the shared state is replicated or even partially-replicated, this task becomes quite diﬃcult. DreamObjects is a platform that simpliﬁes the development of shared data objects. It supports diﬀerent distribution schemes for shared data objects, i.e. a replicated, an asymmetric, and an adaptive one, and hides all mechanisms that are necessary to keep the shared data objects consistent [9]. DreamObjects supports both mechanisms to accommodate a latecomer, as it depends on the latecomer which mechanism is reasonable. Prakash et al. [16] postulate that a latecomer support has to be fault-tolerant, e.g. the site that supports a latecomer can leave the session, and it must not block the current participants of the session in their work. The latecomer support of DreamObjects fulﬁlls these requirements. Additionally, both mechanisms – work completely decentralized, i.e. there is no well-known site that supports all latecomers, – are completely integrated in the runtime environment, and – relieve a developer from the task to supply the latecomer with a consistent state. After discussing related work, this paper describes the basic features of DreamObjects and how it accommodates latecomers.

2

Related Work

Most of the existing groupware platforms only oﬀer a rudimentary latecomer support or even leave it to the developer to implement the necessary mechanisms. Roseman and Greenberg, e.g., believe that there is no generic way for a toolkit to handle latecomers [17]. Their platform GroupKit [6] leaves it completely to the developer to accommodate latecomers. As GroupKit relies on a replicated state architecture this is a quite diﬃcult task. However, there are some platforms that relieve a developer from this task. The Collaboratory Builder’s Environment (CBE) [16] uses a communication infrastructure that bases on a central Corona Server [21]. This server handles the group communication, keeps a copy of the shared state, and logs all messages that are sent between the participants. Because of this, it is quite simple for the server to provide the latecomer with the current state. The latecomer support is independent from client failures, but depends on the availability of the server. Habanero [2] is a groupware platform that focuses on making Java applets available in a distributed environment. The applets must be available as source code and in most cases can be converted into a distributed applet (called Hablet) without too much eﬀort. The state of a hablet is replicated to every participating site. To keep the shared state consistent, Habanero intercepts user interface events and forwards them to a well-known server. This server is also responsible

28

S. Lukosch

for the latecomer accommodation. It requests the state from an arbitrary client and forwards it to the latecomer. The Real-Time Application Level Protocol for Distributed Interactive Media (RTP/I) [14] is an application level protocol that is derived from the Real-Time Transport Protocol (RTP) [20]. While RTP focusses on the transmission of audio and video data, RTP/I is used by collaborative applications and deals with distributed interactive media. It partitions the state of the distributive interactive media in subcomponents and replicates it to every participating site. RTP/I offers some generic services, e.g. a consistency service [22] and a generic late-join service [23]. The late-join service deﬁnes diﬀerent late-join policies, e.g. eventtriggered late-join, immediate late-join, etc. These policies can be assigned to the diﬀerent subcomponents. Based on the deﬁned policies, the subcomponents are transferred to the latecomer. The consistency service ensures that the latecomer gets a consistent state of the subcomponents. It bases on the optimistic Timewarp algorithm [4]. As RTP/I uses physical timestamps to deﬁne the necessary total order of the state changing events, it requires that the participating sites synchronize their physical clocks, e.g. with the help of GPS receivers or the Network Time Protocol (NTP) [15]. Chung et al. [3] describe a replay service for a central architecture. The service bases on a latecomer accommodation server which is called the logger. At the site of a participant, a so-called loggable captures all events that change the local user interface and sends these events to the logger. Thereby, the logger is informed about all changes that a client applies to the user interface of a shared application. When a latecomer wants to join a session, the logger replays all logged events to the latecomer’s loggable. Based on these events, the latecomer’s loggable creates the user interface. As the log can become very large, the system compresses the log by only logging the events that resulted in a state change. The above approaches only consider a single distribution scheme of the shared state. In the CBE, Habanero, and the system of Chung et al. a well-known site coordinates the latecomer support. If this site is unavailable, a latecomer cannot join the session. RTP/I demands that the physical clocks of the participating sites are synchronized. Normally, this cannot be assumed, as this requires that a participating site is either equipped with special hardware or can use NTP. Compared to these approaches, the latecomer support of DreamObjects handles a variety of distribution schemes. For fault-tolerance, it works completely decentralized and does not rely on a central server that logs all events. Additionally, it does not require any special hardware, like e.g. GPS receivers.

3

DreamObjects

DreamObjects is a platform that simpliﬁes the development of shared data objects. It consists of two parts, an object-oriented framework and a runtime environment. Both are entirely implemented in Java. The object-oriented framework oﬀers building blocks for the development of shared data objects. These building blocks oﬀer a lot of conﬁguration possibilities and even allow a developer to

Transparent Latecomer Support for Synchronous Groupware

29

integrate own solutions. A developer can feel free to compose data objects or reuse existing data classes from single-user applications. The runtime environment oﬀers a set of services for data sharing. DreamObjects takes DreamTeam [18] as a starting point. DreamTeam is a platform for synchronous collaboration. It focusses on the coordination and communication of distributed users. DreamTeam is also implemented in Java and mainly consists of a development environment and a runtime environment. The development environment oﬀers a huge hierarchical class library with groupware speciﬁc solutions, e.g. awareness widgets or tracking windows. The runtime environment provides an infrastructure with special groupware facilities. DreamTeam uses the session metaphor [5], which restricts the collaboration of a team to so-called sessions. To support users when organizing sessions, the runtime environment, e.g., starts a session manager that is responsible for starting, joining, and leaving sessions. The session manager stores the information about a session, e.g. the used applications, in a so-called session proﬁle. A rendezvous manager [19] determines the actual network addresses of all team members and allows users to distribute invitations for upcoming sessions. These invitations can include the applications that are used in the session. All managers access the network via the network kernel interface (NKI) that encapsulates all network related services. Concerning shared data, DreamTeam just oﬀers a rudimentary support. During the development of several groupware applications, e.g. a brainstorming tool, a collaborative Web browser, and a distance teaching environment [11], we noticed that the main obstacles are concerned with data sharing issues. For this reason, we extended DreamTeam with DreamObjects. They complement one another, reduce the development costs for a collaborative application, and even allow a developer to reuse existing single-user applications [10]. DreamObjects divides a collaborative application in data objects and user interface objects. The data objects are split up in shared ones and private ones. The user interface objects control the user interface behavior of an application and display the content of the data objects. Users collaborate by modifying the shared data objects via the user interface of the application. DreamObjects oﬀers a set of services to handle the shared data objects, e.g. distributed method calls, object creations, and object duplications. Most of the services are handled completely transparent for developers [9], i.e. they can use a shared data object like a local object of a single-user application. To achieve this transparency, DreamObjects replaces a developer-deﬁned data object with a substitute [12]. For this purpose, a developer has to call a special method in the runtime system which creates the substitute and informs the other participating sites about the new shared object. Fig. 1 shows the class hierarchy for a sample shared data object. A developer can reuse existing data classes to implement complex data classes like they are needed by, e.g., scientiﬁc collaborative applications [1]. The class for a shared data object, e.g. SampleObject, just has to implement the SharedObject interface and to deﬁne a MODIFYING_METHODS ﬁeld.

30

S. Lukosch

SampleObject +MODIFYING_METHODS

ConcurrencyControlScheme

ConstructorArgs

«Interface» «Schnittstelle» SharedObject

SampleSubstitute

«Interface» «Schnittstelle» Substitute

SORepresentation

SharedObjectReference

Evaluator

Bytecode

ApplicationReference

Toolkit-provided class Toolkit-generated class Developer-defined class

Fig. 1. Class hierarchy for a shared data object

The interface serves as an identiﬁcation for the runtime system and does not require to implement any method. The ﬁeld speciﬁes the modifying methods of the data object. The runtime system uses the information about the modifying method to reduce the network load. Depending on the distribution scheme of a shared data object, some sites can execute reading method calls locally, while modifying method calls must be distributed to the other sites to keep the shared state consistent. The SampleSubstitute class extends the SampleObject class and, like all substitute classes, overwrites some of their methods to add functionality, e.g. the mechanisms for modifying and reading method calls. As it oﬀers the same interface as the developer-deﬁned data class, it can easily be used to replace a developer-deﬁned data object. A developer can either generate the substitute class from the command-line or can leave it to the runtime system to generate the substitute class, when it is needed. Each substitute class contains an instance of the SORepresentation class. This class contains the runtime representation of a shared object, i.e. its consistency scheme, its reference, the used constructor arguments, its bytecode, and an evaluator. As some parts of the conﬁguration, e.g. the evaluator, are deﬁned, when a shared object is created, a developer may use diﬀerent instances of the same data class with diﬀerent conﬁgurations without any programming eﬀort. Developers can choose between two diﬀerent consistency schemes which deﬁne how the shared object is kept consistent. One allows to implement ﬂoor control mechanisms, while the other allows to maximize concurrent work by executing conﬂicting methods under mutual exclusion [9]. Similarly, developers can choose between diﬀerent distribution schemes for a shared object which are controlled by diﬀerent evaluators. Currently, DreamObjects supports predeﬁned evaluators for an asymmetric, a replicated, and an adaptive distribution scheme. Depending on the evaluator, diﬀerent sites hold the

Transparent Latecomer Support for Synchronous Groupware

31

data of the object. In the asymmetric case, only the object creating site holds the data, while the other sites only create an empty substitute instance and access the remote data via this instance. In the replicated distribution scheme, every participating site holds the data of the object and thus can execute method calls locally. Compared to these static distribution schemes, the adaptive distribution scheme dynamically adapts the distribution of a shared data object according to a user’s working style or according to the topology of the connecting network. Thereby, it improves the system performance. A site that holds the data of the shared object is called data holder and thus can execute a method call locally. A site that does not hold the data of a shared object must involve a data holder in the execution of a method call. Then the substitute for the shared object maps possible method calls to data holding sites. For this purpose, DreamObjects uses mechanisms that reduce the number of involved sites to a minimum [9]. A reading method call is, e.g., only executed by one data holding site, while a modifying method call is executed by all data holding sites to ensure the consistency of the shared data objects.

4

Direct State Transfer

A ﬁrst, naive approach for the direct state transfer is to let the latecomer’s site select a participating site to support it with the current state of the session. The next three examples show what can happen, if this approach is used.

s1

s2

s3 CON REQ

d.m

SUP MC

t

d.m

d.m

t

t

CON: Connecting message, MC: Method call message, REQ: State request message, SUP: State supporting message

Fig. 2. A latecomer’s site receives a consistent state

Fig. 2 shows, how the site s2 supports the latecomer’s site s3 with a consistent session state. First, the site s3 sends a connecting message to all sites. Thereby, these sites know that s3 joins the session. By sending a state request message, s3 requests the session state from the site s2 . The site s2 sends a state supporting message to the latecomer’s site s3 and so s3 receives the session state. After the site s3 received the session state, the site s1 executes a method call d.m, where

32

S. Lukosch

m is a method of a shared data object d. As the sites s2 and s3 have a consistent session state, they can handle the method call message that was distributed by s1 and execute the method call d.m to keep the shared state consistent. Fig. 3 shows that this naive approach does not guarantee a consistent state for the latecomer. Again, the site s3 joins the session and selects the site s2 as the supporting site. The site s1 executed a method call d.m before it received the connecting message of the latecomer. Thus, it did not distribute the method call message to the latecomer. Due to network latencies, the supporting site s2 receives the corresponding method call message, after it sent the session state to the latecomer. Thereby, the latecomer has an outdated state.

s1

s2

s3

d.m

CON MC REQ d.m

t

t

SUP

t

CON: Connecting message, MC: Method call message, REQ: State request message, SUP: State supporting message

Fig. 3. A latecomer’s site does not receive a modifying message

A requirement for the latecomer support is not to block the already participating sites. Thus, these sites can modify the session state during a site supports the latecomer. Fig. 4 shows what can happen, when a site executes a modifying method call, after the latecomer’s site sent a connecting message. Again, the site s3 joins the session and selects the site s2 as the supporting site. The site s1 executes the method call d.m and sends a method call message to the sites s2 and s3 . The latecomer buﬀers the message as it does not yet have the session state. The site s2 executes the method call before it sends the session state to the site s3 . Thereby, the latecomer receives a session state in which the method call d.m is already included. If the latecomer’s site also executes the method call d.m, its session state can become inconsistent. To address the above problems DreamObjects, splits up the latecomer support in three phases, a connection, an initial, and a ﬁnal one. In the connection phase, the latecomer’s site establishes its connections to the other participating sites. From this point of time, the other sites partly include the latecomer’s site in the message exchange for state changes. In the initial phase, the latecomer’s site requests an initial state from an arbitrary site. As the other sites continue in their work and possibly change the state, this initial state can be outdated. For this reason, the latecomer’s site uses a ﬁnal phase to balance the received state with the other participating sites.

Transparent Latecomer Support for Synchronous Groupware s1

s2

33

s3 CON

d.m d.m

MC

REQ Buffer d.m SUP

t

t

t

CON: Connecting message, MC: Method call message, REQ: State request message, SUP: State supporting message

Fig. 4. A latecomer’s site receives a modifying message twice

4.1

Connection Phase

If a user wants to join a session, he has simply to select it in the session window of DreamTeam (see ﬁg. 5) and decide if he wants to join with a direct state transfer or with a replay. Then the connection phase is started.

Fig. 5. A user joins an active session

Each site maintains a set of participating sites S and a logical clock according to [7]. In the connection phase, the session manager of DreamTeam updates the set S at every participating site, i.e. the latecomer’s site slc is added to it. After this, slc initializes the network connections to all other sites in S. Whenever a site distributes a message to other sites in the session, it includes a timestamp, denoted by ts, and increments the value of the clock. A timestamp consists of the current value of the clock at the sending site and an identiﬁer for the sending site. Whenever a site receives a message from another site, it extracts the included timestamp and, if necessary, updates the local clock value.

34

S. Lukosch

A timestamp uniquely identiﬁes a message. A site can use the timestamps to deﬁne a total order of the received messages. Each site to which the latecomer connects returns a conﬁrmation message that just contains such a timestamp. The latecomer stores this as the connection timestamp tss→slc . In the ﬁnal phase, the latecomer’s site slc uses the stored timestamps to determine, whether its session state is outdated or not. Remember that the participating sites may not be blocked and can modify the session state, while the latecomer’s site slc joins the session. For this reason, each site partly includes the latecomer’s site in the message exchange for state changes and so slc , e.g., receives a method call as well as a method call result message for every modifying method call. When the latecomer’s site slc ﬁnally joins the session, it informs all other sites. Then slc just receives the messages as speciﬁed in [9]. Until then, slc adds all above messages to a message buﬀer. 4.2

Initial Phase

Depending on the network connection and delay, the latecomer’s site slc selects a site ssup ∈ S as the initial supporter that supplies it with an initial state. To request the state from ssup , the latecomer’s site slc sends an initial support request message to ssup . Let D denote the set of shared data objects that are used within a session, Dsup the set of shared objects that have to be transmitted to slc , and Dlc denote the objects that have already been transmitted to the latecomer’s site slc . When the initial supporter ssup receives a request message, it sets Dsup = D and Dlc = ∅. As DreamObjects supports diﬀerent distribution schemes, the initial supporter may not be a data holder of every shared data object and thus may not be able to supply the latecomer’s site with the data of all shared objects. Let the set DHd ⊆ S denote the sites that hold the data of a shared object d ∈ D. The initial supporter ssup determines the shared data objects ∈ DHd and for which the respective evaluator (see section d ∈ Dsup with ssup 3) decides that slc does not become a data holder. If a shared object, e.g., uses an adaptive distribution scheme, a latecomer normally does not become a data holder. Thereby, a site can gradually acquire the shared objects, when the working style of the local user changes. For each of these objects, ssup sends an initial representation support message to slc , adds d to Dlc , and removes it from the set Dsup . Apart from a timestamp, the message contains a representation for the shared object that enables the latecomer’s site slc to create an empty instance of d ∈ D. When the latecomer’s site slc receives a representation support message, it uses the contained information to create an empty instance of the shared object d and adds this instance to the local object registry. Thereby, slc does not become a data holding site. However, as the substitute for d hides the distribution characteristics, the latecomer’s site can use the shared object d like a local object and access its data. After the initial supporter ssup sent the initial representation support messages, it supplies the latecomer’s site slc with the remaining data objects in Dsup .

Transparent Latecomer Support for Synchronous Groupware

35

For this purpose, the site ssup sends for each of the remaining objects an initial object support message to the latecomer’s site slc . When the site ssup transfers the data object d to the latecomer’s site slc , it automatically transfers all objects that d contains to slc . Let Id denote these shared objects. The data object d can contain some of the data objects that have already been transferred to the latecomer. To avoid that a data object is transferred twice, the site ssup replaces all objects in Id ∩Dlc with their reference. Fig. 4 shows that a latecomer’s site executes a method call, though it is already included in the received state. To solve this problem and later to allow a join with a replay, every site maintains a history list. For every state change, the history list contains the respective message. The messages in the history list are sorted according to their timestamps. As not every site participates in a session from its start or executes every modifying method call, the content of the history list can vary from site to site. Let H denote the complete history list of a session and H s ⊆ H denote the history list at a site s. To inform slc about the state changes that were applied to the objects contained in an object support message, an initial supporter extracts the timestamps of the respective messages from its local history list H ssup and includes them in the object support message. After the message was sent, the site ssup removes the transferred objects from Dsup and adds them to Dlc . When Dsup is empty, the supporting site ssup sends a message to slc that indicates the end of the initial phase. When the latecomer’s site slc receives an object support message, it – replaces possible shared data object references for the objects in Dlc with their corresponding local instances, – adds each other shared data object, i.e. {d} ∪ (Id \ Dlc ), to the local object registry, and – stores the received timestamps in its local history list H slc . The initial supporter ssup does not transfer the complete session state at once. Instead, it transfers the state on a per-object basis. If the ﬁrst selected supporter fails before it completely delivered the session state, the latecomer’s site selects a new initial supporter which resumes the latecomer support instead of starting a new latecomer support. 4.3

Final Phase

After the initial phase is ﬁnished, the latecomer’s site has an initial session state. This state can be outdated, as the other sites continued their work and possibly changed the session state. When a site changed the session state, after it connected with the latecomer’s site, the latecomer’s site received and buﬀered the respective message. However, ﬁg. 3 shows what can happen, if a site changed the session state, before it connected with the latecomer’s site. In this case, the latecomer’s site is not informed about the modiﬁcation and the initial state may not contain this modiﬁcation. The following approaches solve this problem:

36

S. Lukosch

1. The supporting site can supply the latecomer’s site with all messages that it receives, after it connected with the latecomer’s site. However, as the supporting site never knows, when to stop forwarding the messages, the latecomer does not really join the session. Besides, the latecomer’s site can receive some messages twice, which unnecessarily increases the network load. 2. Each site to which the latecomer’s site connects sends the connection timestamp via the supporting site to the latecomer’s site. If the connecting network delivers messages in order, this ensures that the supporting site received and applied all messages sent by a site before the latecomer’s site initialized its connections. However, in this case one central site manages the latecomer support and it is not possible to resume it, when the supporting site fails. 3. The latecomer’s site can ask every participating site, if there are some messages left that it did not receive, but has to receive. If there are such messages, the site supplies the latecomer’s site with them. Thereby, the latecomer’s site gets all the information it needs to balance the initial state. DreamObjects uses the last approach, as it ensures that the latecomer definitely joins a session and does not rely on a central site. As soon as the latecomer’s site slc receives the message that indicates the end of the initial phase, it distributes a ﬁnal state request message to all other sites. Besides a timestamp of the latecomer’s site slc , this message contains the connection timestamps that the latecomer’s site stored during the connection phase. Furthermore, the message contains the timestamps of the state changes that were executed before the latecomer initialized its connections. Due to the connection phase, the latecomer’s site slc received all necessary messages from a site s ∈ S with a timestamp ts > tss→slc . For this reason, a ﬁnal state request message must only contain the timestamps in H slc that are less than the corresponding connection timestamps. The message also contains two sets of shared object references. One contains the references of the shared data objects for which the latecomer is a data holder, i.e. slc ∈ DHd , and the other for which ∈ DHd . the latecomer is not a data holder, i.e. slc Each site that receives such a message is called ﬁnal supporter. Let ssup ∈ S denote such a site. When a ﬁnal supporter ssup receives a ﬁnal state request message, it adds slc to the sets DHd as speciﬁed by the message. Then it checks, if its local history list contains any messages that the latecomer did not receive by now, but needs to balance the initial state. A ﬁnal supporter ssup only has to check the messages in its local history list H ssup with a timestamp ts < tss→slc . Such a message must be forwarded to the latecomer’s site, when it fulﬁlls the following requirements: 1. The timestamp of the message is not in the set of timestamps that is speciﬁed in the ﬁnal state request message. Otherwise, the initial state already contains the corresponding state change. 2. The message is not directed to a shared data object d ∈ D of which the ∈ DHd . To balance the initial state, latecomer is not a data holder, i.e. slc the latecomer’s site slc only needs a message that is directed to an object of which it is or may become a data holder.

Transparent Latecomer Support for Synchronous Groupware

37

After a supporting site ssup determined the messages that it must forward to the latecomer, it sends a ﬁnal state support message to slc . Whenever the latecomer’s site slc receives a ﬁnal state support message from a ﬁnal supporter ssup , it adds the contained messages to its message buﬀer. As every ﬁnal supporter forwards messages to the latecomer’s site, slc can receive some messages twice. However, as the messages are uniquely identiﬁed by their timestamp, slc simply replaces them in the message buﬀer. When the latecomer’s site slc received a ﬁnal state support message from every participating site, and the sites that had to send one, but did not do this left the session, slc received all necessary messages to balance the initial state. For this purpose, slc locally re-executes the content of its message buﬀer according to the order given by the timestamps of the messages. The latecomer’s site slc does not re-execute a method call, if this call is directed to a data object d with slc ∈ DHd . However, if the result of such a method call is needed, slc looks up the corresponding method call result message in the message buﬀer. Until the message buﬀer is not empty, the latecomer’s site slc adds all messages that it receives to its message buﬀer. As the local re-execution does not cause any network traﬃc, it is much faster than the execution in a distributed context. This ensures that the message buﬀer gets empty. As soon as the message buﬀer is empty, the latecomer’s site slc distributes a join complete message to all other sites and starts all applications that are needed for the session. From now on, the latecomer’s site slc does not buﬀer messages anymore, instead it participates in the message exchange for a state change. Similarly, the other participating sites only include the latecomer’s site slc in the message exchange, if this is necessary. Though the latecomer now joined the session, a ﬁnal supporter ssup still can receive messages that the latecomer’s site slc needs. Fig. 6 illustrates this problem. In this ﬁgure, the user at the site s4 joins the session as a latecomer. After the site s4 initialized the connections to the other sites, it chooses the site s3 as the initial supporter. The site s3 supplies the latecomer’s site s4 with an initial state. Then the latecomer’s site s4 distributes a ﬁnal state request message to all participating sites. Before the site s1 can serve the request of the site s4 , it leaves the session. However, the sites s2 and s3 serve the request of the latecomer’s site s4 . After they distributed the ﬁnal state support message, they receive a method call message from the site s1 . As s1 distributed this message, before s4 initialized its connections, s1 did not send the message to s4 . As a result, the sites s2 and s3 execute the method call d.m and the latecomer’s site s4 does not. For this reason, each ﬁnal supporter ssup has one further task, after it send the ﬁnal state support message to the latecomer’s site slc . Whenever a ﬁnal supporter ssup receives a message or adds a message to its local history, it checks, whether the message must be forwarded to the latecomer’s site or not. Again, a ﬁnal supporter ssup must forward a message from a site s ∈ S, if – its timestamp ts is lower than the respective connection timestamp tss→slc ,

38

S. Lukosch s1

s2

s3

s4

d.m CON MC

CON CON

CON ISR IOS ISF FSR FSS FSS d.m

t

t

d.m

t

t

CON: Connecting message, FSR: Final state request message, FSS: Final state support message, IOS: Initial object support message, ISF: Initial support finished message, ISR: Initial state request message, MC: Method call message

Fig. 6. Final phase problem

– its timestamp ts is not in the set of timestamps included in the ﬁnal state request message, and – the message is directed to an object d ∈ D with slc ∈ DHd . When the latecomer’s site slc receives such a delayed message from a ﬁnal supporter, it either adds it to the message buﬀer, if it is still re-executing its content, or executes it directly. The latecomer’s site slc supplied each ﬁnal supporter with the set of its connection timestamps. With the help of these connection timestamps, a ﬁnal supporter can ﬁnish the above task as soon as 1. it either received from every site s ∈ S a message with a timestamp ts > tss→slc or 2. every site s ∈ S for which the latecomer provided a connection timestamp left the session. In the ﬁrst case, a ﬁnal supporter ssup cannot receive a message with a timestamp ts < tss→slc from another site s ∈ S anymore, as the network kernel interface (NKI) of DreamTeam (see section 3) ensures that messages are delivered in order. In the second case, a ﬁnal supporter can be sure that he does not receive such a message, as DreamObjects uses the reliable multicast service of the NKI.

Transparent Latecomer Support for Synchronous Groupware

5

39

Replay

Apart from the direct state transfer, DreamObjects also supports a join with a replay of how the current session state was reached. The basic idea is to let the latecomer’s site select a participating site that supports it with the complete history list H. The latecomer’s site uses the stored messages in the history list H to re-execute the state changes and thus to replay how the session state was reached. As the history list only contains the messages that resulted in a state change, compared to the system by Chung et al. [3], additional compression techniques are not necessary. If a latecomer chooses to join with a replay, the runtime system opens a conﬁguration dialog like in ﬁg. 7. This dialog window allows a user to select how many percent of the session state are replayed visually. Additionally, a user can deﬁne the delay between two replayed state changes and thus the speed of the replay. During the replay, he can use the dialog window to vary the speed.

Fig. 7. Conﬁguration dialog for a join with a replay

As for a join with a replay the same problems as for a direct state transfer have to be solved, the latecomer support again is split up in three phases, i.e. a connection, an initial, and a ﬁnal one. The phases are similar to the ones of the direct state transfer. As soon as the user conﬁrms his conﬁguration in the dialog window, the connection phase is started. In the connection phase, the latecomer’s site initializes its connections to the other participating sites. In the initial phase, the latecomer’s site chooses an initial supporter that supplies it with an initial history. Again, the latecomer’s site uses the ﬁnal phase to balance the received history with the other participating sites. As soon as the balance is ﬁnished, the latecomer’s site knows the complete history H, opens the user interface, and starts to re-execute the history. When the re-execution is ﬁnished, the latecomer’s site has a consistent session state.

6

Conclusion

This paper described how DreamObjects accommodates latecomers. DreamObjects supports two mechanisms to support latecomers with the current state: a direct state transfer and a replay. Both mechanisms are integrated in the runtime environment and work completely transparent for the developer. A developer does not have to care about how a latecomer receives a consistent shared state.

40

S. Lukosch

The latecomer support works completely decentralized, i.e. it does not rely on a central site. If the ﬁrst supporter fails and the latecomer already received a part of the session state, an arbitrary site can resume the latecomer support. Additionally, the latecomer support does not block participating sites and thus does not constrain the current users in their collaboration. There are still some open issues. The replay bases on the re-execution of all modifying distributed actions. For this reason, the runtime system at every site maintains a history list. If the group is very active or is collaborating for a long time, the history list can be very large. In [13], Manohar and Prakash present a session capture and replay paradigm for asynchronous collaboration. In this system users collaborate asynchronously by annotating, by modifying, and by exchanging recorded single-user sessions. Similar to this system, the history list could be extended to store snapshots of the session state. Then a join with replay would start with a stored snapshot and state changes prior to the snapshot could be discarded. This would reduce the size of the history and enable a faster join with a replay. Additionally, the history list could be extended to store physical timestamps which could be used for a real-time replay. Such a replay could give a latecomer an even better feeling of how the current state was reached.

References [1] Vinod Anupam and Chandrajit L. Bajaj. Shastra: Multimedia Collaborative Design Environment. IEEE Multimedia, 1(2):39–49, 1994. [2] Annie Chabert, Ed Grossman, Larry Jackson, Stephen Pietrovicz, and Chris Seguin. Java Object-Sharing in Habanero. Communications of the ACM, 41(6):69–76, June 1998. [3] Goopeel Chung, Prasun Dewan, and Sadgopan Rajaram. Generic and Composable Latecomer Accomodation Service for Centralized Shared Systems. In S. Chatty and P. Dewan, editors, IFIP Working Conference on Engineering for HCI, pages 129–145, Heraklion, Crete, Greece, 1998. Kluwer Academic Publisher. [4] W. Keith Edwards. Flexible Conﬂict Detection and Management In Collaborative Applications. In Proceedings of the 10th annual ACM symposium on User interface software and technology, pages 139–148, Banﬀ, Alberta, Canada, October 1997. [5] Saul Greenberg and Mark Roseman. Using a Room Metaphor to Ease Transitions in Groupware. Technical Report 98/611/02, Department of Computer Science, University of Calgary, Calgary, Alberta, Kanada, January 1998. [6] Saul Greenberg and Mark Roseman. Groupware Toolkits for Synchronous Work. In M. Beaudouin-Lafon, editor, Computer-Supported Cooperative Work (Trends in Software 7), chapter 6, pages 135–168. John Wiley & Sons Ltd., 1999. [7] Leslie Lamport. Time, Clocks, and the Ordering of Events in a Distributed System. Communications of the ACM, 21(7), July 1978. [8] J. C. Lauwers and K. A. Lantz. Collaboration awareness in support of collaboration transparency: requirements for the next generation of shared window systems. In CHI ’90 Conference on Human Factors in Computing Systems, Special Issue of the SIGCHI Bulletin, pages 303–311, Seattle, Washington, USA, April 1990.

Transparent Latecomer Support for Synchronous Groupware

41

[9] Stephan Lukosch. Adaptive and Transparent Data Distribution Support for Synchronous Groupware. In J¨ org M. Haake and Jos´e A. Pino, editors, Groupware: Design, Implementation, and Use, 8th International Workshop, CRIWG 2002, LNCS 2440, pages 255–274, La Serena, Chile, September 2002. Springer-Verlag Berlin Heidelberg. [10] Stephan Lukosch and J¨ org Roth. Reusing Single-user Applications to Create Multi-user Internet Applications. In Innovative Internet Computing Systems (I2 CS), LNCS 2060, pages 79–90, Ilmenau, Germany, June 2001. Springer-Verlag Berlin Heidelberg. [11] Stephan Lukosch, J¨ org Roth, and Claus Unger. Marrying On-Campus Teaching to Distance Teaching. In Proceedings of the 19th World Conference on Open Learning and Distance Education, Vienna, Austria, June 1999. [12] Stephan Lukosch and Claus Unger. Flexible Management of Shared Groupware Objects. In Proceedings of the Second International Network Conference (INC 2000), pages 209–219, University of Plymouth, United Kingdom, July 2000. [13] Nelson R. Manohar and Atul Prakash. The Session Capture and Replay Paradigm for Asynchronous Collaboration. In Proceedings of the Fourth European Conference on Computer Supported Cooperative Work, pages 149–164, Stockholm, Sweden, September 1995. [14] Martin Mauve. Distributed Interactive Media. PhD thesis, Universit¨ at Mannheim, 2000. [15] David L. Mills. Network Time Protocol (Version 3) Speciﬁcation, Implementation and Analysis. Request for Comments 1350, IETF, March 1992. [16] Atul Prakash, Hyong Sop Shim, and Jang Ho Lee. Data Management Issues and Trade-Oﬀs in CSCW Systems. IEEE Transactions on Knowledge and Data Engineering, 11(1):213–227, January 1999. [17] Mark Roseman and Saul Greenberg. Building Real-Time Groupware with GroupKit, A Groupware Toolkit. ACM Transactions on Computer-Human Interaction, 3(1):66–106, March 1996. [18] J¨ org Roth. ’DreamTeam’: A Platform for Synchronous Collaborative Applications. AI & Society, 14(1):98–119, March 2000. [19] J¨ org Roth and Claus Unger. Group Rendezvous in a Synchronous, Collaborative Environment. In 11. ITG/VDE Fachtagung, Kommunikation in Verteilten Systemen (KiVS’99), March 1999. [20] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobsen. RTP: A Transport Protocol for Real-Time Applications. Request for Comments 1889, IETF, January 1996. [21] Hyong Sop Shim, Robert W. Hall, Atul Prakash, and Farnam Jahanian. Providing Flexible Services for Managing Shared State in Collaborative Systems. In Proceedings of the Fifth European Conference on Computer Supported Cooperative Work, pages 237–252, Lancaster, United Kingdom, 1997. [22] J¨ urgen Vogel and Martin Mauve. Consistency Control for Distributed Interactive Media. In Proceedings of the 9th ACM Multimedia, Ottawa, Canada, 2001. [23] J¨ urgen Vogel, Martin Mauve, Werner Geyer, Volker Hilt, and Christoph Kuhm¨ unch. A Generic Late Join Service for Distributed Interactive Media. In Proceedings of the 8th ACM Multimedia, ACM MM 2000, pages 259–268, Los Angeles, CA,USA, 2000.

COVE: A Design and Implementation of Collaborative Object-Oriented Visualization Environment Hyung-Jun Kim, So-Hyun Ryu, Young-Je Woo, Yong-won Kwon, and Chang-Sung Jeong Department of Electronics Engineering, Korea University, Anamdong 5-ka Sungbuk-ku, Seoul 136-701, Korea FAX: +82-2-926-7620, Tel: +82-2-3290-3229 [email protected] [email protected]

Abstract. In this paper, we present a collaborative visualization environment(COVE).Our COVE provides not only collaborative but also paralleled computing environments based on distributed object model at once. It is built as a collection of concurrent objects which interact each other and consist of two types of objects : collaborative object and application object, which are used to construct collaborative and paralleled computing environments respectively. Collaborative objects enable COVE to execute various collaborative functions, while application objects enable it to execute various visualization modes in a parallel computing environment. COVE provides a ﬂexible and extensible framework by plugging the proper application objects into COVE, and making them interact with one another through collaboration objects. COVE is built on DOVE(Distributed Object-oriented Virtual computing Environment), a new parallel programming environment based on distributed object model. In DOVE, virtual environment is constructed as a collection of concurrent objects, each of which has its own computing power, interacts with one another by remote method invocation and those objects can be handled as the same way as local objects. Also, heterogeneity, object group, multiple method invocation to object group, object life management,and naming service of object manager are supported to provide a transparent programming environment for parallel and distributed application. We designed collaborative work manager, session manager and application manager for managing cooperative work and ray casting algorithm is adapted for visualization algorithm. Our implementation result shows that various DOVE functionalities make COVE more extensible, scalable and eﬃcient in distributed computing environment.

This work has been supported by KIPA-Information Technology Research Center, University research program by Ministry of Information & Communication, and Brain Korea 21 projects in 2003

J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 42–57, 2003. c Springer-Verlag Berlin Heidelberg 2003

COVE: A Design and Implementation

1

43

Introduction

During the last decade, increases in computing power of desktop computers and high-speed computer networks made it possible to build multimedia collaborative application for multi users. Such applications can solve the restriction of space for data storage, memory, and computing power, and support co-working and exchanging information between remote users. So the need of multimedia collaborative application is increasing in various ﬁeld. So far, some kinds of multimedia collaborative applications supporting multi users have been developed by using several diﬀerent programming paradigm, primarily socket programming model. But recently, object-oriented programming model which solves problem by interactions of objects is prevalent and distributed object models such as OMG CORBA [5], JAVA/RMI [6] and DCOM [7] have been spotlighted to tackle the problems inherent in distributed computing on a heterogeneous environment. Distributed object model provides an easy programming environment by supporting transparency of distributed objects, plug and play of software as well as the advantages of object oriented programming such as reusability, extensibility, and maintainability through abstraction, encapsulation and inheritance. However, it lacks some functionalities for distributed and parallel applications, since they are based on client-server model. It does not support group operations, and has some diﬃculties in implementing eﬃcient parallelism by using asynchronous communications. In this paper, we present a new collaborative visualization environment, COVE(Collaborative Object-oriented Visualization Environment) which enables multiple remote users participate in and discuss cooperative visualization work together. COVE is built based on our DOVE(Distributed Object-oriented Virtual computing Environment) [18], new parallel programming environments called based on distributed object model. DOVE build a virtual environment as a collection of concurrent and autonomous objects interacting with one another via method invocation. It appears to a user logically as a single virtual computer for a set of heterogeneous hosts connected by a network as if objects in remote sites reside in one virtual computer. We designed COVE as a collection of collaborative work manager, session manager, Front-End and Collaborative application on the basis of DOVE for managing cooperative work and ray casting algorithm is adapted for collaborative visualization application. The outline of our paper is as follows: In section 2, we describe previous works which are related to our work. In section 3, describe COVE architecture based on distributed object model. In section 4, we present our implementation result of COVE which use ray casting as a visualization algorithm. Finally, a conclusion will be given in section 5.

2

Related Work

In this section, we describe several existing distributed computing systems and heterogeneous collaborative environments based on them.

44

2.1

H.-J. Kim et al.

Distributed Computing Environment

Distributed programming model can be broadly classiﬁed into message passing model and distributed object model. In message passing model, a program is divided into components or tasks, which may run on diﬀerent nodes of machines. The tasks communicate with each other by explicitly sending and receiving messages. In distributed object model, often called method invocation model, a program consists of distributed objects which interact with one another by method invocation. PVM [9] and MPI [8] are distributed programming systems based on message passing model, while CORBA [5] and Legion [10] based on method invocation model. MPI is a single standard programming interface mainly designed for developing high performance parallel applications with emphasis on a variety of communication pattern and communication topology. However, MPI lacks in functionalities such as process control, resource management and fault-tolerance. PVM is one of the most widely used distributed computing systems based on the message passing model, and connects together separate physical machines into a virtual computer by providing process control, simple message passing and dynamic process group management. In PVM, a daemon process, which runs on each host of a virtual machine, is used not only as process controller but also message router, which may result in communication bottleneck as all tasks heavily depend on daemon processes. Legion is an architecture based on a distributed object model and designed to build system service which provides a virtual machine using shared object, shared name space, fault-tolerance. Legion uses data ﬂow model as parallel computation model, and parallelisms are implicitly supported by the underlying runtime system. However, management of data dependency graph for every invocation as well as scheduling nodes of the graph may incur additional computation overhead, and no support for object group may cause communication ineﬃciency. CORBA is a vender-independent standard which aims at interoperability and portability of distributed applications. CORBA deﬁnes a distributed object model for accessing distributed objects. It includes an Interface Description Language, and a speciﬁcation for the functionality of run-time systems that enable access to objects. But CORBA is based on client-server model rather than a parallel computing model, and hence it is not adequate to provide a virtual machine. Also, it is not well suited to distributed applications where performance requirements demand asynchronous communication and group operations. 2.2

Previous Collaborative Environments

In CVE system, multiple users can interact with each other in real-time, even though they may be physically located in diﬀerent places around the world. This virtual environment provides users a sense of realism by incorporating realistic 3D graphics and stereo sound into the computer-human interface to create an immersion experience. CVE system gives the users a shared sense of space, and shared sense of time. It also provides users with the natural ways of communications and interaction.They achieve their collaborative works with several their

COVE: A Design and Implementation

45

own unique characters and purposes. For example, In SmartCu3D [1] system, an Internet CVE system, distributed users communicate one another with Behavior Based Interaction Management. DISCOVER [2] is CVE project to train teams for emergencies on ships or rigs. SciCentr [3] CVE system is intended to become a meeting place, a workplace, and a showcase for the power of the Internet as a medium for informal science education aimed toward teens and young adults. Industrial tele-training CVE [4] is designed for training the operation of ATM switch equipment. These CVEs use speciﬁc 3D visualization and immersion eﬀect to help user’s collaborative work. However,it is not easy to extend them to other area of part because they have developed with speciﬁc their purpose. And they do not have accelerate operation for Problem Solving which need High Performance Computing power. Shastra [11,12] is a scientiﬁc groupware developed at Purdue University. It is composed of multi-layer architecture, where each layer has the responsibility of connection, communication and collaboration, and supports several tools for useful scientiﬁc collaboration. However since Shastra is based on DCE(Distributed Computing Environment), it is neither completely object-oriented nor suitable for applications that use distributed object. MAESTRO [13] is a distributed multimedia collaborative environment developed at Postech University. MAESTRO provides a rich multimedia collaborative service API which can be used to develop a variety of multimedia applications easily. MAESTRO API and its underlying service have been modeled and implemented using the distributed object-oriented approach. CORBA has been used to design MAESTRO multimedia collaborative services and Orbix has been used for its implementation. Sieve [14] is Java-based collaborative modular visualization environment (CMVE) for construction of interactive visualization. Sieve provides many beneﬁts to data-analysis through data-ﬂow network creation. It supports data analysis over the Web by multiple users’ collaborating in real-time. Furthermore, Sieve demonstrates several experimental techniques for using the JavaBeans component architecture to build collaborative interactive systems.(ex.Interaction, Module Conﬁguration, Collaboration and Persistence and Publication) Sieve presents the user with a large, scrollable workspace onto which data sources, processing modules, and visualization components may be dropped, linked, and edited. Modules representing data sources may be written for a wide range of raw data formats and sources. These may include objects which parse ﬁles retrieved over the Web, objects which access SQL or other databases, and objects which retrieve data from remote servers using CORBA, Java’s RMI library, or proprietary protocols. It has good portability for heterogeneous platforms and Object Oriented Model because it uses Java and CORBA. However it does not support High performance Parallel computing. So this system is not good for the task modules which need high computing power. CoVis [15] is Collaborative Visualization Learning system with remote high school students, teachers and scientists. It was developed at Northwestern University by funding of NSF. Participating students study atmospheric and environmental sciences through inquiry-bases activities. Using state of the art sci-

46

H.-J. Kim et al.

entiﬁc visualization software, specially modiﬁed to be appropriate to a learning environment, students have access to the same research tools and data sets used by leading-edge scientists in the ﬁeld. The CoVis Project provides students with a range of collaboration and communication tools. The merit of this system is to support various and helpful functionality for Science Studying. This provides: desktop video teleconferencing ; shared software environments for remote, real-time collaboration; access to the resources of the Internet; a multimedia scientist’s notebook; and scientiﬁc visualization software. However, this is too speciﬁed to only Science Learning. it is not easy to extend and apply to other goal and area. So, it is not suitable to generic collaborative framework that supports collaboration of ordinary application to multi-user. CSpray [16] stands for Collaborative Spray rendering and is an extension of Spray, a visualization application, into a collaborative environment. Spray rendering is a framework which has been developed for visualization using a spray can; cans are ﬁlled with smart paint particles(sparts) that are sprayed into the data to highlight interesting features. Features are displayed when sparts become activated and leave visualization objects in their path. In order to support collaboration, CSpray is obtained several features. In CSpray, several users in a visualization session may analyze a set of distributed data by creating spray cans loaded sparts. Spray cans may be made public or kept private. Public cans are visible and accessible by other participants. Participants can see the spraying action of other users in their local window. More than one participant may be spraying any given time. Once in a while, the attention of the entire group may be directed at what one of the participants is doing. Participants may also join and leave the session at any time. However, CSpray is based on a message passing paradigm, so it has no virtues of object oriented paradigm. Recently, WWW has become a popular word for application programmers. And there have been another approaches to develop collaborative applications on WWW environment. JETS(Java Enabled Telecollaboration System) which was developed at University of Ottawa is one of those approaches on WWW environment. JETS [17] is a collaboration system based on Java applet. Because Java applet is a mobile code, JETS has the advantages of no previous download or installation. What user in the client part should do is just browsing and navigating through web page. However JETS has the problems such as security restriction and performance problem of Java applet.

3 3.1

COVE Architecture Overall Architecture

COVE(Collaborative Object-oriented Visualization Environment) is a framework for collaborative visualization application which has three layered architecture. It consist of three layers such as Collaborative Application(CA) layer, Collaboration Environment(CE) layer and Parallel Computing Environment(PCE) layer.(see Figure 1.) CA layer provides visualization and computation application modules such as ray caster, ray tracer, image processing module and learning

COVE: A Design and Implementation

47

Collaborative Collaborative Application(CA) Application(CA) layer layer Ray Caster

Ray Tracer

Image processing module

Learning system module

Collaboration Collaboration Environment(CE) Environment(CE) layer layer FrontEnd FrontEnd

FrontEnd FrontEnd

FrontEnd FrontEnd

Session Session manager manager Collaboration Collaboration manager manager

FrontEnd FrontEnd Session Session manager manager

Parallel Parallel Computing Computing Environment(PCE) Environment(PCE) layer layer Cove Cove Runtime Runtime System System Method Method invocation invocation layer layer Message Message passing passing layer layer Communication Communication layer layer Host Host 11

Object manager

Host Host 22

Object manager

Host Host 33

Object manager

Host Host 44

Object manager

Fig. 1. Overall COVE architecture

system module. These modules can be easily plugged into a FrontEnd object which is provided by CE layer. Using this module plug-in feature, user can easily construct ﬂexible collaborative application. CE layer provides several useful collaborative components to construct more eﬃcient and easy-to-use collaborative visualization environment:FrontEnd, Session manager and Collaboration manger. PCE layer provides feature of distributed object model and consist of three sublayer such as method invocation layer, message passing layer and communication layer. method invocation layer supports functionality of remote method invocation and it uses function of message passing layer for sending and receiving an invocation request message and result reply. Communication layer provides various communication protocols to upper two layers. PCE layer also manages usable computation resources. For the purpose of managing computation resources, PCE layer uses special distributed object called Object Manager. Object Manager exists per Host, and provides crucial services such as object creation and naming service. PCE layer implementation is based on DOVE [18]. 3.2

Parallel Computing Environment(PCE)

Distributed Object Model. COVE is based on distributed object model which consists of several distributed objects interacting with each other using method invocation mechanism. Distributed object is divided into interface object and implementation object. (See ﬁgure 2.) The interface object is distributed to applications which are to use the distributed object, and it provides interaction point to its corresponding implementation object. Users can issue a method invocation to the distributed object by invoking the method of its interface object, a local representative of the distributed object. Method invocation to the interface object is converted to the invocation message by stub object, and sent to the corresponding implementation object by COVE run-time system. On the opposite side, the receiver’s run-time system unmarshals the invocation message, and invokes the appropriate method of the target implementation object

48

H.-J. Kim et al. COVE distributed object

COVE distributed object

Implementation object

Implementation object

execute

execute Interface objects

Stub objects

Skeleton object

COVE run-time system

COVE

Object Manager

Object Manager

Object Manager group

Fig. 2. Distributed object model

through skeleton object. A reply message is sent from the implementation object back to the interface object, and returned like a normal function call. This mechanism, which is called remote method invocation(RMI), allows transparent access to the object irrespective of whether it resides in local or remote site. In COVE, distributed object behaves either as client or server to interact with other distributed objects. In other words, it executes the implementation object for incoming RMI requests, while during the execution of the implementation object, it generates a remote invocation to the other distributed object using the interface object as a client. In COVE, object manager exists per host and it provides a set of indispensable services, such as object creation, deletion and naming services, to build a transparent and easy-to-use clustered computing environment. A set of object managers constitutes a single object group which determines the domain of the virtual parallel environment that might encompass a huge number of machines and networks. The main features of COVE object model are as follows. Concurrency Enhancement Scheme. COVE provides three kinds of RMI to support various synchronization modes during data exchange between remote objects: synchronous, deferred synchronous and asynchronous RMIs. In synchronous RMI, sender is blocked until the corresponding reply is arrived. In deferred synchronous call, the sender can do other work immediately without awaiting the reply of the RMI, but later at some point must wait for the reply in order to use the return values. In asynchronous RMI, the sender can proceed without awaiting the reply similarly as in deferred synchronous one, but the corresponding upcall method is invoked on the arrival of its reply. These synchronization schemes are fully supported by multilayered architecture in PCE layer. In distributed system, group communication pattern is often used, since it provides simple and powerful abstraction. In COVE, group communication mechanism is supported by introducing a new construct, object group, as means

COVE: A Design and Implementation Host1

49

Host2 Session manager

Collaboration manager

Raytracer

FrontEnd

White board

GUI Session manager

Host3

Host4

Computation module Visualization module

Raycaster

FrontEnd

FrontEnd

GUI

Data display

GUI

Fig. 3. Components of Collaborative Environment

of grouping objects and naming them as one unit for RMIs. An interface object can be bound to its corresponding object group, and a RMI issued on the interface object is transparently multicast to each implementation object in the group. Interface object to the object group has the same interfaces as the one to the single object, and provides an interaction point with multiple objects in the object group so that user treats it just like a single object. Therefore, the concept of object group allows users to do more simple programming, and to have chance to get better performance if the underlying communication layer supports multicasting facilities. 3.3

Collaborative Environment (CE)

COVE(Collaborative Object-oriented Visualization Environment) is a framework for collaborative visualization application. Users on remote site can participate in cooperative visualization work, exchange various information they have and discuss current visualization work in COVE. All those collaborative functionalities of COVE is implemented as several components in CE layer. Each component in CE is designed as distributed object which is supported by PCE layer and communicates with each other by remote method invocation. Each object has its own name provided by PCE layer and this makes it possible to distinguish all objects from each other guaranteeing its unique existence in COVE environment. To develop COVE, we need to deﬁne several collaborative components to construct more eﬃcient and easy-to-use collaborative visualization environment. The ﬁrst, we need a CollaborationManager managing and controlling entire collaborative environment. The second, we need a SessionManager managing a collaborative visualization session. And the third, we need a FrontEnd which can interact with user via GUI and manage visualization and computation module according to user interaction directly. FrontEnd has a standard interface for connections with various visualization and computation modules. So the user

50

H.-J. Kim et al.

can easily plug in FrontEnd with the modules which serve the purpose of collaborative work, such as ray caster, ray tracer, wire frame viewer and so on. The relationship between above three COVE components are shown in ﬁgure 3. Design and implementation details for COVE components are as follows. CollaborationManager. CollaborationManager is a COVE component, which manages and controls entire collaborative environment. It maintains information about all other components and provides object registration service, session creation service, and environment information service in COVE. Also, it maintains and updates all SessionManager alias and FrontEnd alias as a list. Therefore CollaborationManager has the responsibility for registering and deregistering FrontEnd, creating SessionManager, terminating SessionManager, and sending session list and user list to FrontEnd requesting them. Besides above functionalities, it provides mechanism to guarantee unique object alias for each component in COVE environment. SessionManager. SessionManager is a COVE component managing and maintaining all information concerning session as well as joining and leaving session service. All information about remote user joining the session is stored in SessionManager and data distribution service and access control service are achieved by contacting SessionManager. To distribute visualization data and result data to all other remote users more fast and eﬃciently, each SessionManager has a FrontEnd group consisting of FrontEnds contained in the same session. SessionManager registers FrontEnd alias to its FrontEnd list and also add it to FrontEnd group whenever joining-session request is received by a FrontEnd. When data distribution service is requested by a FrontEnd, SessionManager receives and sends requested data to all remote users in a FrontEnd group at once by multicasting which PCE layer support. When designing collaborative application supporting multi-users, we should add data access control to it. For access control service in COVE, we adopted ﬂoor control pattern. Floor control is a manner to determine the access order to shared data of each FrontEnd. We implemented several modes of ﬂoor control, such as round-robin mode, baton-passing mode and etc so that user can choose whatever ﬂoor control he wants. FrontEnd. FrontEnd is a COVE component which interacts with user via GUI and manage visualization and computation modules according to user interaction. It contains GUI for user interaction such as creating and joining a session, rendering image, exchanging visualization data, choosing ﬂow control and etc. When a user interaction is retrieved from GUI, FrontEnd processes it by calling predeﬁned callback function. FrontEnd supports eﬃcient way for data exchanging between remote users. When a FrontEnd joins a session, it is simultaneously added to FrontEnd group. By joining FrontEnd group, one FrontEnd can send and receive collaboration data via group method invocation. This increases communication performance in a collaborative application as the same data should be transferred repeatedly to all users unless there is group method invocation.

COVE: A Design and Implementation

51

Session Manager

Collaboration

data distribution FrontEnd1 FrontEnd4 FrontEnd2 FrontEnd3 FrontEnd Group

Fig. 4. Session manager: FrontEnd1 requests new session creation to CollaborationManager and CollaborationManager creates a new SessionManager and session. FE1 joins created session and it becomes a session leader. When a FrontEnd participates in one session, it is added to FrontEnd group of that session, and data distribution to all FrontEnds can be done at once by using FrontEnd group which support multicasting

Besides this, FrontEnd manages visualization and computation modules for cooperative work. In COVE, these modules are developed regardless of COVE environment. All collaboration-related processes such as data exchanging and task distribution are assigned to FrontEnd. Various modules are simply plugged-in to FrontEnd and this makes COVE more extensible and easy-to-use for various kinds of visualization applications. 3.4

Collaborative Application (CA)

CA layer provides various modules for collaborative application such as ray caster, ray tracer, image processing module, learning system module and so on. These modules can be easily plugged into a FrontEnd object which is provided by CE layer. Using this module plug-in feature, user can easily construct ﬂexible collaborative application. In this paper, Ray casting is chosen as an application visualization algorithm. We designed three collaborative visualization mode in Ray Caster of COVE application - parallel mode, rotated mode, multiple mode. Each mode uses extended space-leaping method [21] to accelerate rendering speed and is designed to have its own unique feature for fast and eﬃcient rendering in collaborative environment. In COVE, we currently provide only simple text chatting functionality for communications between remote users. Adding more complicated and enhanced communication system to COVE is left as future work.

4 4.1

Implementation and Experiment Ray Casting Application Implementation

For the experiments and evaluation, we developed a collaborative volume rendering application which uses ray casting algorithm on COVE(Its GUI is seen

52

H.-J. Kim et al.

(a) remote user1

(b) remote user2

Fig. 5. Interface of Collaborative Visualization Application on COVE: (a)shows windows of one remote user and (b) shows of another remote user

FE

Ray caster

FE

Ray caster

FE

Ray caster

FE

Ray caster

FE

Ray caster

FE

Ray caster

FE

Ray caster

FE

Ray caster

Volume Data Ray caster FE Master

All User

Multicast

All User

Fig. 6. Illustration of Parallel Visualization

at the Fig. 5). This application has three rendering modes such as parallel visualization mode, rotated visualization mode and multiple visualization mode. detail of each mode is as follow. Parallel Visualization Mode. As ray casting is a highly time consuming process, many ray casting acceleration techniques and parallel algorithms have been developed. Parallel visualization mode is designed to render one image as fast as possible by dividing task into small subtasks and then assigning them to all remote users participating collaborative work. For fast and eﬃcient ray casting, we used extended space-leaping technique and image based parallel algorithm. In parallel visualization mode, only rendering leader have right to render volume image. That is to say, when rendering mode is set to this mode, only

COVE: A Design and Implementation

FE

Ray caster

FE

Ray caster

FE

Ray caster

FE

Ray caster

53

Volume Data Ray caster FE Master

All User

Multicast

All Users

Fig. 7. Illustration of Rotated Visualization

leader can choose viewing direction and render image by pushing render button. Other remote users can do nothing but provide their computing resources to parallel collaborative work and examine the received result image. This is for high performance of parallel rendering process by preventing remote users’ individual usage of computing resources. Our parallel visualization consists of three phases as follows: In the ﬁrst phase we ﬁnd active pixels and active depths by using forward projection as follows: Initially, the volume data is partitioned among various processes. Each process ﬁnds non-empty voxel runs for its partitioned volume slice, and then executes forward projection using line drawing algorithm for each voxel run, ﬁnally returning active pixels to the master process. In the second phase, for job assignment, the active pixels obtained in the ﬁrst phase are distributed among participators on COVE from the leader of the session. The value of each active pixel on the screen is calculated as follows: Generate a ray through the active pixel into the data space. Starting at the nearest active depth where the ray intersects non-empty voxel, follow the ray while sampling the volume at constant interval. Accumulate the color and opacities of these sampled values. Stop following the ray when it is known that it cannot signiﬁcantly change its value, or when it intersects the farthest active depth. In the third phase, the resulting partial images obtained from the second phase are merged to yield the ﬁnal image in the master process.

Rotated Visualization Mode. Ray casting algorithm visualizes 3-dimensional feature of an object on the screen. When visualizing 3-dimensional object, it is necessary to display the same object from various viewing direction by incrementally rotating it. Animated visualization mode is designed to produce multiple images of one object from diﬀerent viewing direction at once. All remote users are assigned his own viewing direction from leader and render images corresponding to given viewing direction simultaneously and then result images are exchanged

54

H.-J. Kim et al. User 2

User 3

User 4

User 5

Raycaster

Raycaster

Raycaster

Raycaster

Raycaster

FE

FE

FE

FE

FE

User 1

multicasting

User 1

User 5

Fig. 8. Illustration of Multiple Visualization

to each other. This mode enables remote users see incrementally rotated images within constant time regardless of the number of images. In animated visualization mode, only rendering leader have right to render volume image as parallel visualization mode. This is for high performance of rotated rendering process by preventing remote users’ individual usage of computing resources.

Multiple Visualization Mode. Both parallel visualization mode and rotated visualization mode restrict remote users’ rendering right except rendering leader to use remote computing resources more eﬃciently. But in collaborative visualization environment, it is necessary to allow all remote users to render individual images. Individual image means diﬀerent data sets, diﬀerent viewing direction, diﬀerent shading eﬀect and so on. Also rendering processes on each remote site can be implemented independently in time by user interaction. Multiple visualization mode is designed to allow all remote user to have his own data set and choose his own viewing direction he is interested in. In this mode, whenever each remote user render an image, rendered result image is sent to all other users to share various kind of result images. More detailed rendering process for this mode is as follows: When rendering mode is set to multiple visualization mode, all collaborative participants can examine various images of diﬀerent data sets, shading eﬀects and from various viewing direction simultaneously. And this makes it possible that all users can share distributed information on remote sites.

COVE: A Design and Implementation

55

Table 1. Machine speciﬁcations Machine type M1 M2 M3 M4 Model Pentium IV PC USparc1 O2 Octane CPU P IV UltraSPARC MIPS R10000 Clock(MHz) 1740 143 150 250 Memory(MBytes) 1024 128 128 512 OS Linux 2.2 Solaris 2.5 IRIX 6.3 IRIX 6.5

Table 2. Measurement of relative performance with respect to M1 for ray casting machine i M1 M2 M3 M4 OS Linux Solaris2.5 IRIX6.3 IRIX6.5 (spec.) (PIV-1.7G) (USparc1) (O2 ) (Octane) running time 103.01 413.812 205.390 128.690 relative perf. 1.0 0.249 0.502 0.800

Table 3. Performance results of parallel ray casting on COVE number of machines 1(M1 ) 2(M1,4 ) 4(M1,2,3,4 ) 8(M1,1,1,1,2,2,3,4 ) 11(M1,1,1,1,1,1,1,1,2,2,3,4 ) expected speedup 1.0 1.8 2.551 6.351 9.551 time (sec) 103.01 70.01 50.012 20.844 13.912 COVE speedup 1.0 1.471 2.060 4.942 7.404 eﬃciency (%) 100.0 81.72 80.75 77.81 77.52

4.2

Experimental Results

We implemented the parallel rendering on COVE with participators which consists of 12 heterogeneous machines, two Ultrasparc1, one SGI O2, a SGI Octane, eight Pentium IV PCs running Linux connected by 100 Mbps Ethernet. Our test data set is a 256 x 256 x 225 human head, and image screen measures 1024 x 1024 pixels. The details of hardware and software information for each machine are shown in table 1. Since each machine has diﬀerent computing power, we have measured the relative performance with M1 as reference machine by comparing the execution time of the identical sequential ray casting program on each machine. Then, the expected speed up is computed as a sum of each relative performance of participating machines. The relative performance of the machines obtained by executing the identical sequential ray casting program is shown in table 2. Table 3 shows the execution time, speed up and eﬃciency of ray casting according to the number of machines. The eﬃciency represents the ratio of speedup with respect to expected speedup. As the number of machines increases, the parallel algorithm shows relatively good speed up with eﬃciency around 80% without degrading its performance due to the communication overhead. The image which is made through this parallel visualization is scattered to every participator. So, they can see the image much faster using COVE’s parallel visualization than using their own single machines.

56

5

H.-J. Kim et al.

Conclusion

In this paper, we have presented a COVE(Collaborative Object-Oriented Visualization Environment) which provides a ﬂexible and extensible framework for collaborative visualization by integrating collaborative and parallel computing environments based on distributed object model. It has been built as three layers : Parallel Computing Environment(PCE), Collaboration Environment(CE), Collaborative Application(CA). PCE has been designed to provide an easy-to-use transparent distributed and parallel programming environment for networked heterogeneous computers. Besides the traditional client-server model, it oﬀers a peer-to-peer parallel model of computation by considering a parallel application as a collection of distributed objects which interact with each other. Eﬃcient parallelism is supported by two concurrency enhancement schemes which support various types of synchronization methods and RMI for object group. CE has been designed to provide an eﬃcient collaborative environment by designing collaborative objects such as FrontEnd, Session Manager, and Collaboration Manager, while CA provides users for application objects implementing speciﬁc functions. The plug-in of diﬀerent application object into collaborative object, FrontEnd, allows application developers to easily construct a collaborative environment for diverse applications. Therefore, COVE can provide a ﬂexible and extensible collaborative environment for not only visualization but also other many applications such as image processing, distant learning, etc. Three visualization modes are designed and implemented to support a fast and ﬂexible analysis of visualization data. Parallel visualization mode has been designed for the fast generation of a volume image, rotated visualization mode for the generation of animated volume images, multiple visualization mode for the generation of diﬀerent volume images. We have shown the experimental result for parallel visualization mode on COVE by executing the parallel ray casting algorithm rotating the volume image on COVE.

References 1. Weihua Wang,Qingping Lin, Jim Mee NG, Chor Ping Low: “SmartCU3D: a Collaborative Virtual Environment System with Behavior Based Interaction Management”, VRST’01, ACM, Nov 2001. 2. Susan Turner, Phil Turner, Liisa Dawson and Alan Munro: “DISCOVERing the Impact of Reality”, CVE 2000, San Francisco, ACM, 2000. 3. Margaret Corbit, Bonnie De Varco: “SciCentr and BioLearn: Two 3D Implementations of CVE Science Museums”, CVE 2000, San Francisco,ACM,2000. 4. J.C. de Oliveira, S. Shirmohammadi, and N.D. Georganas: “Collaborative virtual environment for industrial training”, Virtual Reality 2000,IEEE, 2000 5. Object Management Group Inc., The Common Object Request Broker: Architecture and Speciﬁcation, OMG Document Revision 2.2, February 1998. 6. T. B. Downing, Java RMI: Remote Method Invocation, IDG Books worldwide, 1998.

COVE: A Design and Implementation

57

7. E. Frank and III. Redmond, DCOM: Microsoft Distributed Component Object Model, IDG Books worldwides, 1997. 8. MPI Forum, MPI: A Message-Passing Interface Standard, International Journal of Supercomputer Application 8, No. 3, 1994. 9. A. Geist, A. Beguelin and et al., PVM 3 User’s guide and Reference manual, ORNL/TM-12187, September 1994. 10. M. Lewis and A. Grimshaw, The Core Legion Object Model, University of Virginia Computer Science Technical Report CS-95-35, August 1995. 11. Anupam,V. “Shastra – An Architecture for Development of Collaborative Applications” Thesis for the degree of Doctor, Dept. of Computer Science Univ. of Purdue, 1995. 12. Anupam,V. and Bajaj,C., “Collaborative Multimedia Scientiﬁc Design in Shastra”, Proc. of the ACM Internation Conference on Multimedia, ACM Press, August 1993. 13. T.H.Yun, J.Y.Kong and J.W.Hong, “Maestro: a CORBA-based Distributed Multimedia System”, Proc. of 1997 Paciﬁc Workshop on Distributed Multimedia Systems, Vancouver, Canada, July, 1997, pp. 1–8. 14. Philip L. Isenhour,James Bo Gegole, Winﬁeld S. Heagy, Cliﬀord A. Shaﬀer, “Sieve: A Java-Based Collaborative Visualization Environment”, IEEE Visualization ’97 Late Breadking Hot Topics Proceedings, Oct 22–24, 1997, pp. 13–16. 15. CoVis Project URL: http://www.covis.nwu.edu/ 16. Alex Pang, Craig Wittenbrink “Collaborative 3D Visualization with CSpray”, IEEE Computer Graphics, Vol. 17, No. 2, 1997, pp. 32–41 17. Shirmohammadi, S. and Georganas, N., “JETS: a Java-Enabled Telecollaboration System”, Proc. IEEE ICMCS, IEEE Computer Society Press, Los Alamitos, Calif., 1997, pp. 541–547. 18. C. S. Jeong and H. D. Kim, “DOVE: A Virtual Programming Environment for High Performance Parallel Computing,” 19. J. Frey, S. Graham, C. Kesselman: “Grid Service Speciﬁcation. S. Tuecke, K. Czajkowski, I. Foster,” Open Grid Service Infrastructure WG, Global Grid Forum, Draft 2, 7/17/2002. Lecture Notes in Computer Science, May 2000, pp. 12–21. 20. I. Foster, A. Roy, V. Sander: “A Quality of Service Architecture that Combines Resource Reservation and Application Adaptation,” 8th International Workshop on Quality of Service, 2000. 21. S. U. Jo and C. S. Jeong, “A Parallel Volume Visualization Using Extended Space Leaping Method,” Para 2000, Norway, July 2000, pp. 398–403.

Designing Tailorable Groupware for the Healthcare Domain Robert Slagter and Margit Biemans Telematica Instituut, P.O. Box 589 7500 AN Enschede, The Netherlands {robert.slagter,margit.biemans}@telin.nl

Abstract. In this paper we present a theory-based approach to designing tailorable groupware for the healthcare domain. Both literature and empirical data show the need, and difficulty, of designing groupware that is adaptable to match the dynamic requirements of real-life co-operation in telemedicine. We apply an existing social theory, the Information Foraging Theory, to explain natural tailoring behaviour and state the implications for groupware design. To improve the usability of tailoring, we integrate this theoretical foundation with a groupware design approach to compose groupware behaviour out of individual building blocks and apply this to the healthcare domain. The results are a conceptual architecture and design guidelines that help groupware developers create tailorable groupware. An important contribution of our research is the concept of task-oriented groupware patches that help co-operating healthcare professionals in selecting, combining and fine-tuning those groupware services that fit their evolving needs and requirements. Keywords: groupware design, tailoring, social theory, architecture, healthcare

1

Introduction

As generally stated in literature on computer supported co-operative work (CSCW) fixed technology support fails to capture the dynamics of real-life co-operation. The support provided by a groupware application has to match the tasks of the cooperating people [14;31]. However, there seems to be a real and inherent gap between social requirements and what is technically feasible [1]. In this paper we present our contribution to reduce this gap, and apply it to the healthcare domain. In groupware, a mismatch between the task and corresponding technology support affects the co-operating people. Tailoring, i.e. adaptations to the technology support by the end-users themselves, is generally regarded as a suitable means to solve this problem [14]. However, empirical data from a longitudinal study in the healthcare domain reveals that tailorable options are currently not used to their full potential [13]. Interviews with healthcare professionals suggest that they perceive technology support in terms of activities (e.g., “transferring patient information” or “setting up a treatment plan”) [18]. Based upon these findings we conclude that there is a gap between the way people naturally perceive their co-operative tasks and the way tailorable options are currently presented. J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 58–73, 2003. © Springer-Verlag Berlin Heidelberg 2003

Designing Tailorable Groupware for the Healthcare Domain

59

In this paper, we improve groupware tailoring by aligning tailoring operations with natural human tailoring behaviour and stating the implications for groupware design. We first explore how natural human tailoring behaviour can be explained by an existing social theory, the Information Foraging Theory [21]. Based upon this theory we derive the concept of task-oriented groupware patches to support tailoring. This concept is combined with an approach to compose groupware behaviour out of individual building blocks and a detailed analysis of groupware services. This combination allows us to make well-informed design decisions for collaborative applications in the healthcare domain. The results of our research are expressed in a conceptual groupware architecture and corresponding design guidelines. The research described in this paper is based upon our empirical findings in the healthcare domain. Currently, we are applying the concept of task-oriented groupware patches to support co-operation between healthcare professionals in a stroke service. 1.1

Tailorable Groupware in Medical Settings

Tailoring is about modifying a groupware application to match changing task needs, group needs, personal preferences, changing work settings, different modes of collaboration et cetera. It is generally regarded as a key property of groupware [4;14;26;30]. Tailoring is also an important capacity of groupware systems, since many different users will have to use groupware before it reaches a critical mass [16], and because co-operative activities provide for very dynamic and diversified requirements [26]. However, tailoring is currently not used to its full potential in groupware settings (e.g., [14;20]). This also applies to the healthcare domain. Work pressure is so high that physicians strictly focus on their core task [28], and consequently do not reflect on their technology use, and thus do not tailor [13]. With these results in mind, we want to improve tailoring in the healthcare domain by designing groupware in such a way that tailoring is closely related to normal use, and does not require additional effort from the physicians. We base this design on a social theory, which guides both the description and prescription of tailoring. As in literature no single behavioural tailoring theory is available yet, we have selected an appropriate social theory from another domain and applied it to tailoring.

2

Theoretical Foundation

In order to select an appropriate theory for tailoring, the main characteristics of typical telemedicine tasks are identified. Hettinga concludes that since physicians focus on their main task and do not reflect on their technology use, they do not tailor [13]. By making tailoring part of normal system use, we expect to overcome this problem and promote tailoring. When taking a closer look at tailoring operations, two classes can be distinguished; the selection of appropriate means to support specific tasks, and the fine-tuning and shaping of those means. This is complementary to an evolutionary perspective on technology use; tailoring by selection and tailoring by variation [19]. Tailoring by selection means that for a specific task appropriate functionality and resources are integrated, tailoring by variation means that variability in (new) user behaviour is supported by for example allowing flexibility of component integration.

60

R. Slagter and M. Biemans

Based upon the characteristics of telemedicine (embedded task and selection & variation), the concept of patch-based behaviour, as part of the Information Foraging Theory [21] is selected to be an appropriate theory to both describe and prescribe tailoring behaviour. 2.1

Information Foraging Theory and Tailorable Groupware

The Information Foraging Theory (IFT) links to Rational Choice Theories (e.g., [29]) and is based upon an evolutionary ecological perspective. IFT assumes that people, when possible, will modify their strategies or the structure of the environment to increase their rate of gaining valuable information [21]. We focus upon the modification of the user environment (i.e., tailoring) to achieve task-goals. IFT draws heavily upon models and techniques developed in optimal foraging theory [25], which seeks to explain adaptations of organism structure and behaviour to the environmental problems and constraints of foraging for food. Although optimisation models are used in IFT, its starting point is that humans exhibit bounded rationality or make choices based on satisficing (cf. [23]). Patch models in optimal foraging theory concern situations in which the environment of some particular animal has a ‘patchy’ structure. The forager has two types of actions; between-patches and within-patches. IFT assumes that information foragers allocate their time to between-patch vs. within-patch activities to achieve their goals more efficiently, effectively, and satisfactory. They typically shape the environment to fit the available strategies, and perform tasks more efficiently and in a satisficing way. In IFT, two kinds of tailoring activities are distinguished; (1) to reduce the average costs of getting from one patch to another (between-patches), and (2) making more coherent patches of relevant information (within-patches). By analogy, between-patch behaviour provides opportunities for tailoring by selection, as the task-patch is composed of relevant media support. Within-patch behaviour is comparable to tailoring by variation as the patch can be shaped and fine-tuned to meet (evolving) behavioural requirements. 2.2

Tailoring Operations: Action and Impact

Our focus is on synchronous groupware settings in the healthcare domain. In such settings, when one person tailors, it may also affect the other user, both intentional and unintentional. For example adding an x-ray viewer during a peer review affects all participants in the session, while changing the background colour should not affect the other users. These examples show that only the relevant tailoring operations need to be communicated to the other participants. We consider tailoring as a system change, which leads to a change in user behaviour and of course the other way around; desired user behaviour can be achieved by system changes. Tailoring operations (actions) lead to system changes, and typically require changes in user behaviour (impact). In co-operative settings, the system changes sometimes also affect the other participants, and consequently require behavioural changes of them as well.

Designing Tailorable Groupware for the Healthcare Domain

61

Based on the distinction between action and impact, we consider three types of tailoring operations; adjustments, tunings and alterations. Adjustments are local changes (activity), which do not affect other people (impact). Changing the background colour of your PC is an example of such an adjustment. Tunings are local changes (activity), which require some form of tuning between people to understand the changed situation (impact), but require no action of the other user. As one physician in a videoconference turns his image viewer to black and white (due to bandwidth restrictions), the other participants should be aware of this, but do not have to act on this. Finally, alterations are global changes that create another situation (impact), and therefore require both an action and a corresponding behavioural change of the other users. An example of an alteration is a patient who wants to show the spots on his skin and therefore adds a web-cam to the audio conference, of course the physician also has to add a viewer to see the image. This categorisation of tailoring operations is summarised in Table 1. Table 1. Action and impact based tailoring categorisation: Adjustments, Tunings and Alterations. The plus sign indicates that the operation requires an action by that person, or has an impact on that person

Adjustments Tunings Alterations

3

Action Initiator Other(s) + + + +

Impact Initiator Other(s) + + + + +

Groupware Services and Tailoring

The following section states how groupware can be designed to match the dynamic requirements of co-operation. We identify the services a groupware application should be able to provide, and the dynamics in using these services. The identification of groupware services is required to create a groupware design, which is flexible enough to cluster tailorable options in terms of task-oriented groupware patches. 3.1

The Task-Technology Fit

The services provided by a groupware application have to match the tasks of the cooperating people [24;31]. To achieve a proper matching of co-operative tasks and technology support (typically called the task-technology fit) we distinguish two means: 1. A good initial selection of groupware services by external experts, based on the characteristics of the collaboration “as is” and “to be”. This includes the characteristics of the collaborating people, the tasks they perform together, and the context in which the collaboration takes place (e.g., in the office, on the road, or at home). 2. Allowing the collaborating people themselves to adjust the behaviour of their groupware applications. This refers to tailoring as discussed previously in this pa-

62

R. Slagter and M. Biemans

per. Whenever changes to the collaborative task occur, or people change the way they collaborate, they may require different groupware services. In both situations people need to be able to select, combine and adjust groupware services (i.e., the behaviour of a groupware application towards its end-users: the collaborating people). However, the people who have to perform these operations differ in the two situations described above. In the first one experts do the adjustments, while in the second one the end-users perform the adjustments themselves. In the latter situation there are typically no experts present to help the tailor. So, it is important to select a tailoring mechanism that is in line with natural tailoring behaviour. Our solution to this is to allow end-users to select the appropriate groupware services in terms of groupware patches that correspond to recognizable tasks. The following sections state how we identified groupware services and their dynamics in use. 3.2

Discovering Groupware Services

We selected essential groupware services from literature, based on our objective to discover groupware services that are meaningful and important to co-operating endusers. Ellis et al. distinguish three main categories of groupware services: communication, collaboration and co-ordination services [11]. As an alternative, the CoMeCo model by Ter Hofte [27] describes the services of a groupware application in terms of conference management (starting and stopping conferences, participation management, media management), media (corresponding to the communication and collaboration services distinguished by Ellis), and co-ordination services (floor control and access control services). Since the CoMeCo model lists groupware services that are meaningful and important for co-operating end-users, we have taken these services as a starting point. The services of the CoMeCo model that are outside our scope have been omitted, e.g., when they were aimed at groupware programmers or handled too specific situations, such as services to manipulate conference hierarchies. Similarly we have looked at the groupware services distinguished by Dewan [7] and Kausar and Crowcroft [15]. Specifically, the services related to permissible participants, available roles and associated permissions have been adopted from Kausar and Crowcroft [15], while the services related awareness, and to process (workflow) management have been adopted from Dewan [7]. The groupware services related to starting co-operation (the enabling services in our model of groupware) originate from Edwards [8]. He distinguishes explicit and implicit mechanisms to start interaction. An example of an explicit mechanism is a person who invites another person for a co-operative session. Implicit mechanisms can for instance be based on similarities in (virtual) location, activities or simultaneous use of an information object. 3.3

Discovering Dynamics in Groupware Services

The way people co-operate, i.e., the mode of collaboration, changes over time [14]. Over time, people may need different groupware services to support them. We identi-

Designing Tailorable Groupware for the Healthcare Domain

63

fied four aspects that have to be dynamic in a groupware application to suit the reality of co-operation. These four aspects are primarily based on literature: 1. Based on their goals, preferences, and context people should be able to select appropriate media to communicate [5]. The noisy environment of a factory may require text-based communication, while audio communication may be preferable for quick discussions in the office. Consequently, a groupware application should be able to support various forms of communication. 2. Similarly, different goals and domains may require sharing different types of information objects. While physicians need to share high-resolution x-ray images, architects have to work together on computer drawings of a house. A groupware application should be flexible enough to support such different types of shared information objects and associated services. 3. As commonly found in groupware literature (e.g., [9;15;27]), some types of cooperation require explicit user roles and associated access rights, e.g., in a workflow. Communication within large groups may be more efficient with a chairman who can grant the floor to specific people. On the other hand, explicit user roles and access rights may restrict communication in unwanted ways. So, a groupware application should optionally include services to enact a co-ordination policy and assign user roles to participants. Of course, the co-ordination policy itself should also be adaptable. 4. As described by Edwards [8] people apply different styles to join together into a collaborative session. Meeting styles range from explicit invitations to implicit chance encounters in a shared (virtual or physical) location. Related to this, people prefer to know who else is available for communication (presence awareness) and use this information to find appropriate occasions for communication [12]. So, groupware applications should be able to support various services to start communication, corresponding to different meeting styles. Summarising: the following four aspects of a groupware application have to be adaptable to suit the dynamics of real-life co-operation: 1) the use of communication media, 2) the use of shared information objects, 3) the enacted co-ordination policies, and 4) the applied meeting style. These four aspects form the basis for our taskoriented groupware patches. 3.4

Towards Informed Groupware Design Decisions

It is not trivial to design a tailorable groupware application that provides a dynamic set of services to the co-operating end-users. To make well-informed design decisions the groupware architect needs to know how the various groupware services are related, and the actions and interactions that take place when a specific groupware service is used. To obtain this information we have specified all identified groupware services using the formal modelling language AMBER [10]. The corresponding visual representation allowed us to specify the actions and interactions that take place when a groupware service is used, the information that is exchanged, and for instance the status information that is changed during the process. Moreover, the AMBER specification allowed us to define behavioural building blocks: groupware building blocks that provide coherent sets of groupware behaviour. These groupware building blocks

64

R. Slagter and M. Biemans

helped us to define the conceptual groupware architecture described in the remainder of this paper, and revealed the services that have to be provided by the groupware infrastructure that connects the various building blocks. An example of an AMBER groupware service description is given below.

Fig. 1. AMBER description of groupware service to add a tool to an online conference

3.5

Creating Patches in the Healthcare Domain

Interviews with 13 healthcare professionals associated with the Stroke Service Enschede reveal that these healthcare professionals distinguish different types of remote co-operative activities. Most importantly, they distinguish peer-reviews (i.e., multidisciplinary discussions), referring a patient, and requesting additional information regarding a patient [18]. Therefore, we created three groupware patches for these physicians, related to the three types of co-operative activities. Even when on a system level the patches related to different tasks are quite similar, it is important for recognizability to present them on the user level as different patches. The patch determines what groupware services will be activated by default (i.e., tailoring by selection) and what services can optionally be added during a conference (i.e., tailoring by variation) (table 2). Other adjustments to the groupware application can also be performed (e.g., changing fonts and colours), but are omitted in this paper for clarity. Advanced patches can also define default user roles (such as treating physician and consulted physician) and associated access rights. Table 2. Example groupware patches in healthcare Patch 1: Peer-review Default tools: Video conferencing Document sharing Optional Audio conferencing tools: X-ray sharing Remote microscope User roles: Treating doctor Consulted doctor

Patch 2: Refer a patient Default tools: Audio conferencing File transfer Optional tools: Video conferencing Shared scheduling User roles:

Designing Tailorable Groupware for the Healthcare Domain

4

65

Conceptual Architecture of Tailorable Groupware

This section describes a groupware design, in terms of a conceptual architecture that is flexible enough to present tailorable options in the form of groupware patches. A conceptual architecture is an organisation of computational elements and the description of their interactions [22]. To implement a groupware application according to a conceptual architecture, the described processes (i.e., groupware behaviour) have to be assigned to software components. This is not necessarily a one-on-one mapping: not every building block in the conceptual architecture will correspond to exactly one software component. However, based on the ideas presented in this paper we advocate choosing software components that provide sets of related groupware services. That way, the selection of a patch (and variations within a patch) can be directly mapped onto a composition of software components to provide the selected behaviour. 4.1

The Conceptual Architecture

Our conceptual architecture of tailorable groupware (as shown in figure 2) consists of four types of groupware building blocks, the services they provide, and the interfaces between them. The architecture reflects the identified groupware services and the dynamics in using these services. Given our overall focus on synchronous forms of co-operation, we use the term conference to denote a group of people who co-operate at the same time using a particular set of communication media and shared information objects while a set of rules may apply. The conference management building block in our model hosts all services related to the management of such conferences. This includes services to start and stop conferences, invite people, join a conference, change the set of communication media and shared information objects and services to change the set of rules that apply. In our conceptual architecture, every valid composition of building blocks to form a groupware application contains exactly one conference block. So, independent of the selected groupware patch, these services should always be provided. To enable communication and co-operation between participants our conceptual model contains tool building blocks. A tool building block provides all services related to a communication tool or shared information objects. Examples of communication tools are audio conferencing, video conferencing, and text-based chat. The services related to a communication tool allow for direct communication between the participants in a conference. Examples of tools that provide access to shared information objects are a shared x-ray viewer, application sharing and shared patient records. The services related to such tool components allow for indirect co-operation of the participants. Based on the identified dynamic aspects of groupware applications, we expect that changing the set of active tools in a conference is an important and frequently used tailoring operation. Every valid composition of groupware building blocks contains at least one tool building block. As described by Erickson & Kellogg, people prefer to know who else is present in a shared space, and they use this awareness to start communication at suitable times [12]. Such presence awareness is provided by the enabler building blocks in our conceptual model. These building blocks can also provide information about ongoing

66

R. Slagter and M. Biemans

conferences. A valid composition of groupware building blocks does not need to include enabler components: not every groupware application needs to provide these services. The fourth and last type of building block, the co-ordinator, provides all services needed to assign roles to participants and enact a co-ordination policy accordingly. This includes the services to specify a workflow, access control or floor control. Similar to the enabler building blocks, a valid composition of groupware building blocks does not need to include a co-ordinator building block. Groupware application

Enabler *

0..*

1

CO Coordinator CO

0..* 0..*

Conference

0..*

Conference

1

Coordinator Coordinator Coordinator 1..*

0..1

Enabler

executes role-based executes role-based coordination policy on tool(s) coordination policy on tool(s)

Tool

Tool

Fig. 2. Conceptual architecture of tailorable groupware

4.2

Information Exchange between Local Building Blocks

The building blocks in our conceptual architecture that form the groupware application of one participant interact to provide consistent behaviour. The conference building block for instance informs the other building blocks about the current set of participants in the conference, and the currently active tools. In a groupware implementation, this exchange of information occurs through specified component interfaces that act as contracts: by implementing a specific component interface a software component declares to be of a certain type (e.g., a tool component). Based on this information other groupware components know what to expect in terms of the services that component can offer and how to communicate with it. Such a mechanism is needed to allow for run-time changes to the groupware composition, for instance since the co-operating people decided to activate a new communication tool in a groupware patch. 4.3

Complementary Conceptual Architectures

Several other conceptual architectural models for groupware exist, such as the CoMeCo model [27], Dewan’s generic architecture [6] and Clover [17]. These conceptual architectures have primarily been created to facilitate the work of groupware designers, the services identified in our conceptual architecture are primarily selected based on their relevance to groupware users. Our conceptual architecture of groupware is an extension of the CoMeCo model by Ter Hofte. We have extended the CoMeCo model by adding services for enabling

Designing Tailorable Groupware for the Healthcare Domain

67

online co-operation, as identified by Edwards [8], and the presence awareness services identified by Erickson & Kellogg [12]. The generic collaborative architecture by Dewan [6] and the Clover architecture [17] are complementary to our approach. These architectures can be applied by groupware designers and programmers to design the individual groupware components in more detail when a design has been created according to our conceptual architecture.

5

An Integrated Approach: From Theory to Practice

The social-technical research presented in this paper is based on patch-based behaviour, as described in the Information Foraging Theory of Pirolli & Card [21] and our three types of tailoring operations in groupware (adjustments, tunings and alterations). These concepts are integrated with a design approach to create tailorable groupware out of behavioural building blocks and applied to the healthcare domain. As a result of this integration we derive practical guidelines for presenting tailorable options and dialog structures. This section elaborates on these results, and summarises our design guidelines. 5.1

Task-Oriented Patches and the Consequences for Groupware Design

The IFT describes individual tailoring behaviour, and states that people search for tailorable options in terms of patches, both for selecting the appropriate groupware support and fine-tuning them [21]. In groupware, a patch can be seen as a recognizable set of coherent groupware services. Two kinds of tailoring activities are distinguished; between-patch and within-patch activities. Simple heuristics guide both within- and between patch behaviour. We integrate this with the possibility to compose groupware behaviour out of building blocks that provide recognizable groupware services. As a result, we advocate creating groupware patches that correspond to concrete and recognizable tasks of co-operating people. Our interviews [18] reveal that physicians express the services they require in terms of tasks. Consequently, groupware patches are named after the task they are designed to support, and consist of a selection of groupware services that are typically needed for that task. The patch states which groupware services are to be activated by default and which ones are optional (i.e., tailoring by selection and tailoring by variation). Advanced patches can also state possible user roles. Consequently, groupware patches are domain-specific. It requires knowledge of the domain and the user tasks to create patches that are in line with natural tailoring behaviour. Obviously, tailors should be able to create new patches to cope with new collaborative tasks. Additionally, people who have specialized their groupware application by adding or fine-tuning groupware services should be able to store the new configuration as a patch. This allows users to create new patches for specialized tasks that require a specific set of groupware services (e.g., “review stroke treatment” instead of the generic “peer review”). To allow for such selection of groupware services a groupware application should be composable of independent building blocks that provide these services. At the

68

R. Slagter and M. Biemans

same time, this composition should also result in a coherent application. We have outlined a conceptual architecture that verifies these requirements. 5.2

Dialog Structures with Tailoring Impact

It is important to inform all participants of relevant tailoring operations. Dialog structures are an appropriate means to convey this information. As a conflicting force, the other participants should not be bothered with irrelevant information in dialog boxes. However, when designing groupware it is typically possible to identify whether a specific tailoring operation is an adjustment, tuning or alteration. If the operation for instance requires actions by (the application of) other participants, it is likely to be a alteration. If on the other hand, the operation only has a local impact, it is likely to be an adjustment. Table 1 shows when dialog structures are needed to convey the impact of a tailoring operation and any required actions. This table shows that adjustments do not need to be communicated to the other participants, since these operations do not impact the others. Tunings however, need to be communicated to the other participants, while no corresponding action is required. Alterations not only have an impact on other participants, they even require some action by (the application of) the other participants. So in that case, the dialog structure should communicate the required action, the impact of this action, and an option to let the system immediately perform the required action. Some alteration operations do not need additional dialog structures to clarify the impact: when an image viewer for x-rays pops up on your screen during a conference, it is obvious that one of the other participants included this tool, and no additional dialog box is needed for clarification. 5.3

Groupware Design Guidelines

Summarising our contributions, we derive the following guidelines to design tailorable groupware: Create domain-specific groupware patches that correspond to a recognizable set of co-operative tasks of the prospective users; Allow tailors to create their own domain-specific patches; Upon a tuning: communicate the impact of the operation to the other participants in the conference; Upon an alteration: communicate the impact of the operation and the required action to the other participants in the conference; When designing groupware, cluster groupware services that are related to one communication tool in a separate groupware building block; Cluster groupware services to access shared information objects in separate groupware building blocks; Cluster co-ordination services (e.g., to define roles and assign access rights) in a separate groupware building block; Cluster conference management services (e.g., starting, stopping, joining, and leaving conferences) in a separate groupware building block;

Designing Tailorable Groupware for the Healthcare Domain

69

Cluster conference enabling services (e.g., awareness services to discover other people or other ongoing meetings) in separate groupware building blocks. 5.4

A Mock-Up Tailoring Interface for the Healthcare Domain

To illustrate our concept of task-oriented groupware patches, we created mock-up screenshots of a patch selector (see figure 3). It provides single-click access to three groupware patches. These patches represent a combination of groupware services that correspond to specific co-operative tasks (tailoring by selection), in this case: peer review, refer a patient, and a request for additional information.

Fig. 3. Mock-ups of tailoring by selection and tailoring by variation

Once the peer review session has started, the physicians can still modify and finetune the selection of the active groupware services. This tailoring by variation is supported by the mock-up on the right. The third mock-up illustrates what the invitation may look like on the screen of the invited physician (see figure 4). Note that this invitation dialog also uses the name of the patch, as this provides the invited person awareness about the purpose of the meeting. By accepting the invitation (i.e., impact), the corresponding set of groupware services for the peer review session is automatically started (i.e., action). Details about the used groupware services can optionally be accessed.

Fig. 4. Mock-up of invitation dialog (at the invited participant)

70

6

R. Slagter and M. Biemans

Discussion

We applied the Information Foraging Theory and the related patch models [21] to describe natural human tailoring behaviour, as this is in line with the two most often applied tailoring operations: tailoring by selection and tailoring by variation. Moreover, we have applied this theory to prescribe the design of tailoring in groupware by forming patches of groupware services. Our concept of task-oriented groupware patches to adapt groupware behaviour is in line with the notion of meeting genres, described by Antunes et al. [2]. Based on literature we have derived a set of services that groupware applications have to provide to co-operating healthcare professionals. Given our purpose to design groupware applications that can be adapted by the co-operating physicians themselves, it is important that these physicians recognise the identified groupware services. Interviews in the medical domain [18] have led us to believe this is the case. Based on the analysed dynamics in real-life co-operation and a formal specification of groupware services we were able to make well-informed design decisions for a conceptual groupware architecture. This architecture helps developers create groupware applications that can be tailored by end-users, based on patches. Regarding the proposed conceptual architecture: there is no such thing as an inherently good or bad architecture. Architectures are either more or less suited for some stated purpose [3]. The Software Architecture Analysis Method (SAAM) is designed to articulate those purposes and then determine the degree to which an architecture meets them. Through SAAM we verified that the groupware application has the intended properties of modifiability, composability and extensibility by tailors. We have tested our concepts and the completeness of the specified component interfaces by creating a proof-of-concept demonstrator, the CoCoWare .NET platform. This platform consists of a groupware framework that provides generic services (e.g., security and basic services to transmit information to all participants in a conference) and a set of frequently needed groupware components. The prototype allows for runtime composition of groupware services, thus allowing us to test both tailoring by selection and tailoring by variation. For more information about this prototype, we refer to: http://www.cocoware.net A form of validating a conceptual architecture is to show that it corresponds to implicit practices in software engineering. To do so, we studied the Groove workspace (www.groove.net) and Microsoft Windows Messenger (messenger.microsoft.com). Both products revealed an internal structure that separates tools from conference management. Microsoft Messenger also provides extensive enabling services (for discovering other people to start a meeting). Additionally, the Groove workspace identified sets of groupware tools that can be regarded as implementations of groupware patches. The Groove workspace also allows for extensibility of groupware tools and patches. Based on this process of reverse engineering we conclude that these existing applications are organised according to our conceptual architecture.

Designing Tailorable Groupware for the Healthcare Domain

7

71

Conclusions

One of the fundamental challenges of CSCW is to bridge the gap between social requirements and the support offered by technology [1]. The research described in this paper aims to reduce this gap by aligning tailoring operations with natural human tailoring behaviour and designing groupware correspondingly. We have gathered requirements, and applied our findings in the healthcare domain. In this paper, we first described individual human tailoring behaviour based on the Information Foraging Theory and the related patch models. We have integrated this theoretical foundation with a groupware design approach to compose groupware behaviour out of individual building blocks. This building block approach allows for the selection, composition, and fine-tuning of those groupware services that fit the requirements of the co-operating end-users. To be able to make well-informed design decisions we have identified recognizable groupware services, and specified them individually using the AMBER modelling language. This formal notation helped us to precisely specify the actions and interactions associated with each service, and the relations between various groupware services. Given the obtained insights in the dynamics of real-life co-operation, we have allocated the various groupware services to behavioural building blocks. The types of building blocks, and their relations have been specified in a conceptual groupware architecture. The conceptual architecture and corresponding groupware design guidelines help groupware developers create tailorable groupware that is in line with natural human tailoring behaviour, thus improving the usability of tailoring. An important contribution of the research presented in this paper is the concept of domain-specific task-oriented groupware patches that help tailors in selecting, combining and finetuning appropriate groupware services. The component-based approach presented in this paper is needed to combine these selected groupware services into a coherent and consistent groupware application. We are currently in the process of validating our findings in various projects in the healthcare domain.

Acknowledgments. The authors like to thank Henri ter Hofte, Janine Swaak, JanGerrit Schuurman, Chris Vissers and Anton Nijholt for their valuable contributions. Part of the research presented in this paper was conducted within the Dutch Freeband TeleCare project.

References 1. 2.

3.

Ackerman, M., "The Intellectual Challenge of CSCW: The Gap Between Social Requirements and Technical Feasibility," Human-Computer Interaction, vol. 15, no. 2–3, pp. 181– 205, 2000. Antunes, P., Costa, C. J., and Dias, J. F., "Applying Genre Analysis to EMS Design: The example of a small accounting firm," in Borges, M. R. S., Haake, J. M., and Hoppe, H. U. (eds.) Proceedings of the 7th International Workshop on Groupware Los Alamitos,CA.: IEEE Computer Society, 2001, pp. 74–81. Bass, L., Clements, P., and Kazman, R., Software Architecture in Practice Reading,MA.: Addison-Wesley, 1999.

72 4.

5. 6. 7. 8. 9. 10.

11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.

R. Slagter and M. Biemans Bentley, R. and Dourish, P., "Medium versus Mechanism: Supporting Collaboration through Customisation," in Marmolin, H., Sundblad, Y., and Schmidt, K. (eds.) Proceedings of the Fourth European Conference on Computer Supported Cooperative Work ECSCW ’95 Dordrecht, The Netherlands: Kluwer, 1995, pp. 133–148. Cockburn, A. and Greenberg, S., "Making contact: Getting the group communicating with groupware," Proceedings of the ACM COCS’93 Conference on Organizational Computing Systems Milpitas, California: ACM Press, 1993, pp. 31–41. Dewan, P., "Architectures for Collaborative Applications," in Beaudouin-Lafon, M. (ed.) Computer Supported Cooperative Work (CSCW) 7 ed. John Wiley & Sons Ltd., 1998, pp. 169–194. Retrieved from: ftp://ftp.cs.unc.edu/pub/users/dewan/papers/arch2.ps.Z Dewan, P., "An Integrated Approach to Designing and Evaluating Collaborative Applications and Infrastructures," Computer Supported Cooperative Work: The Journal of Collaborative Computing, vol. 10, no. 1, pp. 75–111, 2001. Edwards, W. K., "Session management for collaborative applications," Proceedings of the 1994 ACM conference on Computer supported cooperative work Chapel Hill, NC, United States: ACM Press, 1994, pp. 323–330. Edwards, W. K., "Policies and Roles in Collaborative Applications," ACM Conference on Computer Supported Cooperative Work (CSCW’96) New York: ACM Press, 1996, pp. 11– 20. Eertink, H., Janssen, W. P. M., Oude Luttighuis, P. H. W. M., Teeuw, W. B., and Vissers, C. A., "A Business Process Design Language," in Wing, J. M., Woodcock, J., and Davies, J. (eds.) FM'99 – Formal methods: World congress on formal methods in the development of computer systems, Toulouse, France, September 1999; Proceedings, Vol. I. Lecture notes in computer science: 1708 Heidelberg: Springer, 1999, pp. 76–95. Ellis, C. A., Gibbs, S. J., and Rein, G. L., "Groupware: Some issues and experiences," Communications of the ACM, vol. 34, no. 1, pp. 38–58, 1991. Erickson, T. and Kellogg, W., "Social translucence: an approach to designing systems that support social presence," Transactions on Computer Human Interaction (TOCHI), vol. 7, no. 1, pp. 59–83, 2000. Hettinga, M., "Understanding evolutionary use of groupware." PhD thesis Telematica Instituut, 2002. Kahler, H., Mørch, A. I., Stiemerling, O., and Wulf, V., "Introduction to special issue "Tailorable Systems and Cooperative Work"," Computer Supported Cooperative Work: The Journal of Collaborative Computing, vol. 9, no. 1, pp. 1–4, 2000. Kausar, N. and Crowcroft, J., "An architecture of Conference Control Functions," Proceedings of Photonics East Boston, MA.: SPIE, 1999. Koch, M. and Teege, G., "Support for tailoring CSCW systems: Adaptation by composition," Proceedings of the 7th Euromicro Workshop on Parallel and Distributed Processing IEEE Press, 1999, pp. 146–152. Laurillau, Y. and Nigay, L., "Clover Architecture for Groupware," Proceedings of the 2002 ACM conference on Computer supported cooperative work New York, NY, USA: ACM Press, 2002, pp. 236–246. Michel-Verkerke, M. B., Schuring, R. W., and Van Harten, W. H. Needs, requirements, interests and impact of integrated wireless ICT in care: TeleCare/D2.2. 2003. Enschede, The Netherlands, Twente University. Mørch, A. I., "Evolutionary growth and control in user tailorable systems," in Patel, N. (ed.) Adaptive Evolutionary Information Systems Idea Group Publishing, 2002, pp. 30–58. Oppermann, R. and Simm, H., "Adaptability: User-initiated individualization," in Oppermann, R. (ed.) Adaptive user support. Ergonomic design of manually and automatically adaptable software. Hillsdale: Lawrence Erlbaum Ass. Publ., 1994. Pirolli, P. and Card, S., "Information Foraging," Psychological review, vol. 106, no. 4, pp. 643–675, 1999. Shaw, M. and Garlan, D., Software Architecture: Perspectives on an Emerging Discipline Prentice Hall, 1996.

Designing Tailorable Groupware for the Healthcare Domain

73

23. Simon, H. A., "Rational choice and the structure of the environment," Psychological review, vol. 63, no. 2, pp. 129–138, 1956. 24. Slagter, R. J., Biemans, M. C. M., and ter Hofte, G. H., "Evolution in Use of Groupware: Facilitating tailoring to the extreme," in Borges, M. R. S., Haake, J. M., and Hoppe, H. U. (eds.) Proceedings of the 7th International Workshop on Groupware (CRIWG2001) ed. Los Alamitos,CA.: IEEE Computer Society, 2001, pp. 68–73. 25. Stephens, D. W. and Krebs, J. R., Foraging theory Princeton, NJ: Princeton University Press, 1986. 26. Stiemerling, O., "Supporting tailorability of groupware through component architectures," ECSCW’97 Workshop on Object Oriented Groupware Platforms (OOGP) Lancaster: 1997, pp. 54–60. 27. ter Hofte, G. H., Working apart together: Foundations for component groupware, Enschede, the Netherlands: Telematica Instituut, 1998. Retrieved from: http://www.telin.nl/publicaties/1998/wat/wat.htm 28. Tucker, A. L., Edmondson, A. C., and Spear, S., "When problem solving prevents organizational learning," Journal of Organizational Change Management, vol. 15, no. 2, pp. 122–137, 2002. 29. Turner, J. H., The structure of sociological theory, 5 ed. Belmont, CA: Wadsworth, 1991. 30. Wulf, V. and Golombek, B., "Direct activation: A concept to encourage tailoring activities," Behaviour and Information Technology, vol. 20, no. 4, pp. 249–263, 2001. 31. Zigurs, I., Buckland, B. K., Connolly, J. R., and Wilson, E. V., "A test of task-technology fit theory for group support systems," ACM SIGMIS Database, vol. 30, no. 3–4, pp. 34–50, 1999.

Two-Level Tailoring Support for CSCL Jörg M. Haake, Till Schümmer, Anja Haake, Mohamed Bourimi, and Britta Landgraf FernUniversitaet in Hagen Computer Science VI Informatikzentrum, Universitaetsstr. 1 D-58084 Hagen, Germany [email protected]

Abstract. At the FernUniversität Hagen, we develop a collaborative learning platform, which supports a variety of collaborative distance learning scenarios through the provision of groups, tailorable adjacent rooms associated to groups, and networked content pages and group communication media contained within rooms. Learners can add and manipulate content within rooms and may add/remove rooms. Experts (teachers), in addition, can define and manipulate templates for the content allowed on pages in rooms, and may also add or change the group tools available in rooms. This supports tailoring of learning environments at two levels: at the structural and functional level and at the content level. The current system is presented, and an example of use is discussed. Keywords: collaborative learning, collaborative learning platform, shared workspaces, collaborative learning services, tailorability

1

Introduction

The FernUniversitaet in Hagen is the German distance learning university. Teaching at the FernUniversitaet includes different forms of learning: courses, seminars, and different forms of practical problem solving in lab courses. Course material and accompanying individual exercises are sent to distributed students via surface mail or the Internet. Course-specific newsgroups and direct e-mail communication with professors and teaching assistants support asynchronous discussions. Students might also use the telephone to contact staff directly. In addition, students can meet tutors and other students at one of the 60 learning centers, if one exist near their location. A survey of faculty and students did show a major interest in collaborative learning scenarios. As a result, the FernUniversitaet established a research project aiming at testing initially five different forms of collaborative learning in teaching practice. These five scenarios are: collaborative exercises, tutor-guided groups with collaborative exercises, virtual seminar, virtual lab, and collaborative exam preparation. During the requirements analysis, it became clear that a static learning environment would not be sufficient to meet the needs of all scenarios. J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 74–81, 2003. © Springer-Verlag Berlin Heidelberg 2003

Two-Level Tailoring Support for CSCL

75

Instead of providing a different learning environment to each scenario (and to make adaptations of these for different usages), it was decided that a single collaborative learning platform, which would support all five scenarios, and which would be tailored by the teachers and students to the needs of their actual course, would be beneficial. Since an analysis of existing approaches showed serious deficits, it was decided to develop a tailorable collaborative learning platform meeting our needs. The remainder of the paper is organized as follows: section 2 provides an analysis of the requirements on a tailorable collaborative learning platform. Section 3 reviews current approaches. Section 4 introduces our approach, while section 5 describes our tailoring support. Section 6 concludes the paper with a summary, comparison to related work, and plans for further work.

2

Requirements Analysis

An analysis of the five collaborative learning scenarios helped to identify the major requirements (in the sequel denoted by “(Rx)”) on a collaborative learning platform: A shared space for collaboration and learning material is needed (R1). The shared space needs to provide access to the shared learning material, and to the tools required to jointly perform the learning activities on the shared material (R2). In addition, communication and coordination of learning activities must be facilitated (R3). Finally, teachers and learners must be able to structure learning into smaller episodes (R4). Each scenario requires a different mix of learning episodes (each of different type, and of different synchronicity). Group building must be supported in a variety of ways, from informal gathering to automatic group composition for large courses with hundreds of students (R5). Each group needs a shared space (see above). The shared space of a course must support access to its groups and (sub)spaces. In addition, shared spaces must support access restrictions to guarantee privacy, if needed (R6). Once groups are formed, learning activities must be scheduled. Thus, students need support for arranging appointments for synchronous learning episodes as well as agreeing on dates for asynchronous deliverables (R7). When a learning episode is to be performed, students and teachers need access to the collaborative tools needed (R8). Since teachers usually prepare courses, teachers must be able to create and maintain above configurations themselves (R9). If a learning scenario requires groups to control their own space, students must be able to create and maintain sub groups and sub spaces themselves as well (R10). Thus, a simple way of tailoring the collaborative learning environment is needed. Finally, as learners are distributed and may use different types of computers and operating systems, the learning platform should be based on Internet standards and should minimize the installation of additional software on the learner’s side (R11).

76

3

J.M. Haake et al.

Current Approaches

Shared workspaces (R1) are provided by several collaborative learning platforms, suich as BSCW [1]. In BSCW, there are no easy means for structuring the content of managed shared documents (i.e. no templates are supported). Furthermore, group formation (R5) and access to collaborative tools (R8) are not supported. KOLUMBUS [7] is an asynchronous collaborative learning platform, which integrates the presentation of multimedia material partitioned into small items with communication contributions about the material. Students can add material and annotate the contributions of others. Collaboration is supported via (1) forming discussions through linking annotations, and (2) by voting. Teacher must predefine the structure of the learning environment, which is later filled by students (i.e. students can’t change the environment (R10)), and ignores synchronous communication (R4). WIKIs [8] support simple editing of a web site by a group. A Swiki [4] provides means to define a page’s appearance in both edit and view mode. But the system lacks in means for defining more structured content (R4) and for group building (R5). It only provides a small pre-defined set of text fields. SparrowWeb [2] provides means for creating editable web pages based on a table metaphor. Users can define the structure of the content (the columns of the table) and the rendering of the content on the page, but SparrowWebs don’t provide easy editing means (like the WIKI syntax). In summary, we can state that there is no collaborative learning platform available that meets all of our requirements. Thus, we developed the CURE (Collaborative Universal Remote Education) collaborative learning platform.

4 CURE in a Nutshell The key concept of CURE is the room concept [3], which provides a shared space for a group (R1). Figure 1 illustrates the conceptual design of CURE. To build up structured learning environments, a room may be connected to adjacent rooms, thus forming a virtual learning environment represented as an acyclic directed graph of rooms. Every cooperative learning environment is represented by a designated entry room and all rooms recursively connected to it. In fact, a whole virtual university can be constructed by aggregating all learning environments offered in a central room. Since in our current implementation a room is implemented as a web page, the central access point to all learning material is a collaborative web portal. A room provides a location where a group can meet to perform a certain learning task. A group may contain several users. To support group communication (R3), a room offers communication channels such as chat, a group-centered news group, threaded discussions, voice-over-IP or e-mail among group members. When users move into a new room, they are automatically provided with the communication channels to the current users of the new room. In addition, all group awareness features are tied to the room, e.g. the individual users may see who else is with them in the same room, and what they are currently doing. This facilitates coordination (R3).

Two-Level Tailoring Support for CSCL

77

To support the learning tasks, a room contains one or several pages that present and structure the material needed for the shared learning activities (R2). Two types of pages are supported: Content pages contain structured text content that is presented in a human readable form within the web page of the room. Binary pages are provided to upload external files into the room and thus make them accessible for the group members. The file may contain learning material such as Word or other documents as well as executable software tools that are needed to perform special learning steps (R2). Collaborative Learning Environment entry room used by

content

Room

Abstract Page has

ContentPage

Binary Page

Group adjacent rooms

has

Communication Channel

Awareness

has member

User

has

Template

M ail

Chat

....

Fig. 1. Conceptual design of CURE

A simple editor is provided that allows editing content pages using a simple syntax, comparable to a WIKI [8]. In particular, the syntax supports links to other content or binary pages, other rooms, external URLs or mail addresses. Using links to binary pages, external learning material or tools may be referenced and thus used wherever it is needed. For form-based input, pages may also be tied to templates. Teachers can tailor the structure of a room’s documents by defining special templates. A template contains two XHTML documents that are used to layout a page’s content in the edit mode and the view mode. Since templates are defined using XHTML, we assume that only expert users will create or modify templates. Whenever a user edits a page, CURE uses the edit XHTML document to generate a form that represents the page’s structure. During the course, the student can then fill out the form and store the results in a content page (by submitting the form). CURE then switches to the view mode, where the content of the content page is rendered for reading (using the XHTML document that was supplied for the view mode). In this step, the text answers are automatically formatted according to WIKI editing rules. Using rooms and pages, the learning environment can be structured to facilitate collaborative learning: Whenever the focus of the group should change or a group should be split up into sub groups, a new room should be used to arrange the necessary material. Whenever the same group is continuing to work on new material or on a new subtask, another page should be added to the current room. Figure 2 shows an example of how rooms and pages have been used to model the operating systems course at the FernUniversität Hagen. The Operating Systems Course Hall is the entry to point to the overall course material. All students signed up to the course have access to this room. The room contains an Introduction page explaining scope, goals and prerequisites for this course. The page How to learn explains

78

J.M. Haake et al.

how the room is organized and to be used. The hall offers communication channels to the group, such as a chat, so group members can talk to each other. Course notes, bibliography and cooperative exercises [5,6] are provided in separate rooms. Chat

Operating Systems Course - Hall Intro

Course Notes

How to learn

Group communication and awareness services within a room

News M ail Awareness

Chat

Cooperative Exercises - Room Intro

reachable sub rooms for sub group work

How to learn

Group Building

News

Sched uling

M ail Awareness

....

Chat

Exercise 1 - Room

Content pages for group work

Task

Background

Mail Awareness

coop. E-R modeller

Chat

Exercise 1 - Group 1 - Room Task

Step 1

Step 2

Exercise 7

....

News

.... coop. brainstorming application

Bibliography

Subm ission

News M ail Awareness

....

Group n submission gateway to correction

Fig. 2. Example structure of a collaborative learning environment of an operating systems course at the FernUniversität Hagen.

Next to an Introduction and How to learn-page, the Cooperative Exercises room offers pages for group building and scheduling of group meetings. From the Cooperative Exercise room, access to the seven cooperative exercises within the course is possible via the connected seven rooms (see, e.g., Exercise 1 room in figure 2). Prior to starting a collaborative exercise, users open the Group Building page to become a member of a group (R5). For this purpose, this page may offer group-building facilities ranging from a simple, table-based enrollment into groups to fully automatic group assignment based on personal preferences (such as times of availability, or preferred partners). As a result of the group building activity, users are assigned to a learning group. In figure 2, a total of n groups have been established, with one specific group room assigned to each group (R 5) and exercise (see, e.g., Exercise 1 – Group 1 - Room in figure 2). Each group room is only accessible to the respective group members (R6) - see below. After groups have been established, the group members need to determine a date and time for the joint exercise. By using the Scheduling page in the Group Exercises – Room users can negotiate the next meeting, e.g. by following the link to a meeting scheduling service comparable to Meet-O-Matic [10] (R7). Alternatively, they could

Two-Level Tailoring Support for CSCL

79

use the group’s newsgroup or mail service to arrange a date. At the appropriate time, all group members enter their group room (e.g., Exercise 1 – Group 1-Room in figure 2) and start working on the joint exercise. In the group room, they find pages with the task description and the subsequent steps the teacher proscribed for their problem solving process (R 4) (i.e. pages Step 1 and Step 2), followed by the submission page for their final solution. In our example, the teacher wants them to do a cooperative brainstorming first, followed by a cooperative E-R modeling of the relationships between the concepts identified. The pages support opening of the respective cooperative tools for all members of the group, and they also support forwarding results from one tool to the next tool (R8). Finally, the Submission page facilitates the submission of the solution to the correction phase via a submission gateway to the university’s assignment system. Collaborative learning can be organized within a room by informally describing the proscribed learning procedure on pages by using text, diagrams, and embedding links to appropriate services, pages or adjacent rooms (R4). This way, teachers and learners can receive information about possible learning episodes and services, and may follow or deviate from the proscribed pattern. Associating keys for rooms with groups and users define access permissions. A key provides access to a room. The distribution of keys restricts room access.

5 Tailoring in CURE In CURE, two levels of tailoring are supported: tailoring at the content level, and tailoring at the structural and functional (room) level. Tailoring at the content level refers to changes of the content and appearance of content pages. For this purpose, a simple WIKI like syntax is provided to students and teachers for editing the content of pages. In addition, teachers can use templates to define and adapt the structure and appearance of pages. As an example, assume a course, where students should design and discuss a software system. As a methodology, the teacher wants them to use CRC-Cards. He creates a new page template and adds an edit form (cf. section 4, edit XHTML document) that contains input fields for class, collaborations, and responsibilities. The part that defines an input area for the class would, e.g., look like this:

Class:

Note that the teacher did not have to change the underlying document model or the implementation of the learning environment to create any kinds of new content. As a next step, the teacher creates a view template (cf. section 4, view XHTML document) that renders the class card. This template includes mark-ups for formatting the content (like table- or colour-tags). Special tags can be used in the template to include stored texts (like to show the text that was entered in the input field named ‘class’) or collaboration information that is

80

J.M. Haake et al.

maintained by CURE (like <editInformation /> to show, who last edited the page). Templates also define which other templates can be created as next pages from the page. For CRC-Cards, the teacher could, e.g., define that the text in the collaborations field can only link to new CRC-cards, but not to pages using other templates. From an end-user’s point of view, templates guide him in creating a consistent structure within his documents. We assume that especially in a pedagogical context, this can provide guidance and ease the process of creating content. It also relieves the students from thinking about formatting of pages. Tailoring at the structure level refers to changing the rooms, their content including tools (via binary pages) and their connections within a collaborative learning environment. For this purpose, teachers and students can add rooms and change the pages contained in a room. In addition, teachers can use a learning environment as a master copy for a new learning environment. In summary, tailoring at the content and structural and functional level enables teachers (R9) and students (R10) to adapt the learning environment to their needs.

6 Conclusions and Future Work In this paper, we presented CURE, a collaborative learning platform that supports teachers and students in constructing and tailoring of collaborative learning environments. In CURE, a collaborative learning environment for a course, seminar or lab is composed of interconnected rooms containing learning material, tools, group communication channels, and awareness information. When entering a room, a user sees the room's content and is automatically connected to the room's group via its communication channels. Through using collaborative tools embedded in the room, users can also collaboratively learn and edit material. Group members can tailor the learning environment on the structural level by modifying the room structure and the functionality and content of individual rooms. Privileged users (i.e. teachers) can tailor the content level by changing the structure and presentation of content pages through templates. With respect to the editing functionality, CURE is comparable to many other systems that provide editable web pages, such as WIKIs [8] and SparrowWeb [2]. In addition, CURE combines simple editing facilities with more advanced layout options. Compared to KOLUMBUS [7], CURE enables teachers and students to change the structure of rooms and pages. While KOLUMBUS targets asynchronous communication, CURE supports also synchronous collaboration through embedded collaborative tools and via the communication channels attached to rooms. Compared to all solutions mentioned above, CURE provides means for group formation, group maintenance and group awareness. Using the room metaphor provides the learners with a learning space that is very comparable to a real university building (and thus hopefully intuitive to most users). The room metaphor has proven to be successful in many CSCW and CSCL settings [3, 9], but we are not aware of any approaches that combine room metaphors with WIKI technology.

Two-Level Tailoring Support for CSCL

81

BSCW [1] provides workspaces, which can (to some extent) be mapped to CURE’s rooms. The workspaces provide means for communication and sharing documents. Anyhow, there are no easy means for structuring the content of managed shared documents, as it is provided with CURE’s page templates. By allowing users to place links to other rooms in a room, CURE provides an easy means for supporting the navigation and transition between different collaborative learning spaces. The room provides access to all shared resources and communication facilities such as e-mail, chat etc., which is often not supported in traditional WIKIs. These issues are crucial for facilitating collaborative learning. The room-metaphor combined with the extended template concept provides an organizational mechanism for content management and tailoring. This combination is the key to support 2-level tailoring. Allowing teachers to clone any part of the content or any room facilitates reuse. WIKIs often allow cloning of content, but not replicating structure that exceeds a single WIKI (as it is possible with CURE’s rooms). Currently, we have a working prototype that was successfully used with teachers to create first versions of collaborative learning environments to be used in pilot courses in fall 2003. Until next spring, the experiences from the pilots will be used to define good practice examples, and to inform the design of an improved version.

References 1. Bentley, R., Horstmann, T., Sikkel, K., and Trevor J. Supporting Collaborative Information Sharing with the World Wide Web: The BSCW Shared Workspace System. In Proceedings of the 4th International WWW Conference, Issue 1, O'Reilly, Dec. 1995, pp. 63–74. 2. Bier, E. A. and Pier, K.: Sparrow Web: Group-Writable Information on Structured Web Pages. In: Proceedings of CHI2003, ACM Press: Fort Lauderdale, 2003, 634–635. 3. Greenberg, S. and Roseman, M.: Using a Room Metaphor to Ease Transitions in Groupware. In Ackermann, M., Pipek, V. and Wulf, V. (Ed.): Beyond Knowledge Management: Sharing Expertise, MIT Press: Cambridge, MA, 2003. 4. Guzdial, M., Rick, J. and Kerimbaew, B.: Recognizing and Supporting Roles in CSCW. In: Proceedings of the ACM 2000 Conference on Computer supported cooperative work (CSCW2000), ACM-Press: New York, 2000, 261–268. Haake, J., Schümmer, T., and Haake, A. Supporting Collaborative Exercises for Distance Education. Proc. of HICSS 36 (HICSS 2003), Hawaii, January 5–9, 2003. IEEE Press. 6. Haake, J. M. and Schümmer, T. Some Experiences with Collaborative Exercises. To appear in: Proceedings of CSCL’03, (Bergen, Norway, June 14–18), Kluwer Academic Publishers. 7. Kienle, A., Hermann, T. Integration of Communication, Coordination and Learning Material – A Guide for the Functionality of Collaborative Learning Environments. Proc. of HICSS 36 (HICSS 2003), Hawaii, January 5–9, 2003. IEEE Press. 8. Leuf, B. and Cunningham, W.: The Wiki Way. Addison Wessley, Longman, 2001. Pfister, H., Schuckmann, C., Beck-Wilson, J. and Wessner, M.: The Metaphor of Virtual Rooms in the Cooperative Learning Environment CLear. In Streitz, N., Konomi, S. and Burkhardt, H. (Ed.): Cooperative Buildings – Proceedings of CoBuild'98, LNCS1370, Springer: Heidelberg, 1998, 107–113. 10. Watt, S. and Eisenstadt, M. meet-o-matic. http://www.meetomatic.com, (May 2003).

The Reciprocity Project. A P2P Meta-groupware Supporting Co-evolution and Reciprocity 1

2

2

2

Frédéric Hoogstoel , Ludovic Collet , Alain Derycke , and Xavier Le Pallec TRIGONE Laboratory 2 Polytech’Lille, CUEEP Institute University of Lille 1 F-59655 Villeneuve d'Ascq Cedex France {Frederic.Hoogstoel,Ludovic.Collet,Alain.Derycke, Xavier.Le-Pallec}@univ-lille1.fr 1

Abstract. Despite our efforts for ten years to identify and to take into account the issues of CSCW, the tailorable collaboration environments we have designed are not yet fully appropriated by final users. Among the issues we have identified, the lack of user implication in centralized systems seems the main obstacle today. Moreover, the inter-organisational context in which CSCW systems will be more and more used has serious impact on this issue and other ones, especially resource sharing, organisation and cohesion. The goals of the Reciprocity project are to develop a peer-to-peer metagroupware supporting co-evolution and to evaluate its adequacy to address better the implication issue and the inter-organizational context impact. On top of the JXTA peer to peer middleware, we are building an XML middleware distributed on a network of web servers to manage distributed co-operative activities and resources.

1

Introduction

Despite our efforts for ten years to identify and to take into account the issues of CSCW when designing collaboration environments, our systems are still hardly appropriated by final users. Among the six issues we have identified - Communication, Coordination, Resource Sharing, Organisation, Implication (Motivation and Involvement), and Group Cohesion - the users motivation seems the main obstacle today. Moreover, the inter-organisation context in which CSCW systems are being more and more used has serious impact on this issue and other ones, especially resource sharing, organisation and cohesion. The goal of the Reciprocity project is to evaluate the adequacy of Peer to Peer to build a CSCW environment and to better address the Implication issue and support the inter-organizational context.

J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 82–89, 2003. © Springer-Verlag Berlin Heidelberg 2003

The Reciprocity Project. A P2P Meta-groupware

2

2.1

83

Lessons from Our Previous Experiences of CSCW Environment Design A Meta-groupware to Support Co-evolution

The key issue of a CSCW environment we have addressed is tailorability. That’s why the first system we developed named Co-Learn [1] offered radically tailorable collaborative activity spaces represented by the Virtual Room metaphor, and tailorable collaborative tools. The core of this first system was a meta-groupware named ODESCA: a Smalltalk framework allowed to develop and integrate new collaboration tools. A method and a model named MACAO described in [2] allowed users to describe computer mediated collaborative activities. The resulting specification would have allowed software engineers to easily develop and integrate new support tools. But this approach has not really worked [3] and an analysis of the Cultural Historical Activity Theory [4] helps to understand why. Users are not able to fully specify their activities before work because theirs needs and the activity itself are evolving while they are carrying out the activity. This has leaded us to found our new design on a more solid foundation, based on the adoption of the Cultural Historical Activity Theory [4], and its variants, as a general conceptual framework of collaborative interactions. That’s why we have designed DARE (Distributed Activities in a Reflexive Environment) [5,6], a proof of concept of expansive systems [7,8] supporting co-evolution. This expansive system allows users to specify and change by themselves their collaborative activity settings in terms of roles and tools while they are carrying out the activity. 2.2

Distribute Resources and Power to Users to Enhance Members Involvement

An expansive system [7,8] like DARE should help users to appropriate the CSCW environment by giving them the power to tailor their activities in place. DARE provides facilities to model the collective activity and allows dynamic change at run time and crystallisation of the experience of the users. However this appropriation may be hampered by a lack of users implication: DARE’s architecture is still relatively centralised from the user viewpoint and appropriated for uses inside a same organisation. Now we have observed that users don’t like to put resources in a centralised shared workspace. With the new Internet generation, all users may be consumers and producers of data and probably soon of services. Everyone can have its own personal publication space: on his own personal computer, or on a server of his personal Internet service provider. We observe that users prefer publishing documents and services on their private pages to publishing them on a shared workspace. We see many reasons: difficulty to make and manage several copies of the resources they publish, difficulty to respect third party publication rules, the loss of control on their resources and the loss of ownership. We derived, from an analysis about the sharing of resources that the need for an acknowledgement from her/his peers is central in collaboration. It is the same for the possibilities to maintain full

84

F. Hoogstoel et al.

control on the given resources, without the filter of some system administrators as in most centralised systems. It appears clearly that some technical features such as the naming of the resources through an URL (www.univ-lille1/~alain/contribution/mydocuments) have also a social value, not only because it mentions explicitly the name of the author or owner, but also because the path description, its semantic, is a kind of language act. This also has been pointed for the economy and power of the linking in the Web [9]. In other words: linking (a form of delegation) is often better than uploading. 2.3

Implication Needs Enhanced Openness Too

DARE openness is realised by the ability to integrate external tools in collaborative activities. Of course, to be fully integrated, these tools must themselves satisfy some constraints of openness. They must be components with a published programming interface and an event interception mechanism allowing the activity management system to fully control the tool behaviour. The recent evolution of Internet technologies like Web Services ones (WSDL, SOAP) lets us hope such characteristics will be easily available soon. But in DARE the activity specifications describing resources (tool uses), roles and rights are coded in the Smalltalk centralized server and are not exportable. They have no external representation. Only specialised DARE tools can access, manipulate and interpret these specifications. If we want to really distribute power to users and respect Activity Theory, activity specifications must be managed also as resources distributed among users.

3 3.1

The “Reciprocity” Project Choices Peer to Peer Mechanisms for Symmetrical Cooperation

In the Internet world new protocols or mechanisms have emerged especially for the sharing of resources (for example music samples as in Gnutella network) outside the control of centralised organisations. It has been recognised [10] that this “political” aspect explains the success of Peer-to-Peer technologies (P2P) even if the technologists sometime disavow it. These Peer-to-Peer mechanisms and architectures have been interesting also for the technology of collaboration [11], or for inter-organisation relationships in the framework of e-Commerce [12]. P2P implies symmetry between the entities, which communicate and co-operate: each one is simultaneously a client and a server. The protocols for managing the exchanges (negotiation, providing services, etc.) are also reciprocal and distributed, and the connectivity is large because all the entities can be connected directly to all the other ones.

The Reciprocity Project. A P2P Meta-groupware

3.2

85

All Peers Are Web Servers

We decided that all communicating entities would use a minimal Web server, giving them the potential to act, not only as a client with a traditional browser, but also as a local document server. Present technology makes it possible for even mobile device platforms (PDA) to participate. Integrating a web server for each entity allows using HTTP protocol transport, which can easily cross organizational boundaries and firewalls. This choice also permits the potential of the XML suite of technologies to be harnessed, particularly that of the XSL-T processor, which allows documents to be transformed and shared by participants in the activity, and the X-link support, which allows documents to be included when activities are delegated to a remote entity. In this type of organization, an entity can range from a single person using a personal Web-server at his/her workstation to a group of people sharing a group Web-server within an organization, all of whom can communicate through the Internet. In addition, this organization can support mobility and wireless connections (see figure 1).

3.3

XML Eases Interoperability and Malleability

The realization support to Reciprocity framework has to address/satisfy the following points: 1.

The inter-organizational exchanges require interoperability mechanisms.

2.

Each participant/entity has a particular (personalized) view of the activity due to his role. This involves need of several activity description transformations.

3.

In a next time we want to integrate mobile entities in our framework. This means that interface will be adapted depending on the media.

These needs lead us to choose XML as our data format. XML is a standard, its advantages are many, tools for manipulation and transformation of data, as XSLT (for 2.) (http://www.w3.org/TR/xslt) and XIML (for 3.) (http://www.ximl.org), it is readable by most kind of user, from activity supervisor/owner to end-user. An interesting part in XML is the easy development of manipulating tool. Moreover, XML is largely used in Web services. XML will assure loosely entity coupling1 (very useful for 1.).

1

The XML easy-to-use feature and the free/open source tools imply few investment for a system to become XML-compliant.

86

F. Hoogstoel et al.

A

B

XSLT engine Web server

3

View/edit model Resources access

access 2 rights

Personalization

1 View/edit B activity

’generic’ XSL files

Tasks manager

the 2 activity

Roles manager

Current status A Activities manager

servlets

Events for external activities manager

JXTA presence

HTTP

services ‘activities’

network JXTA

…

Resources : usual files system

… MyDocs

Courses

Tasks

Activities XML files

Fig. 1. Reciprocity Deployment Architecture

The Reciprocity Project. A P2P Meta-groupware

3.4

87

An Event-Based XML Middleware to Manage Distributed Co-operative Activities and Resources

To the JxTA (http://www.jxta.org) P2P and Web architecture, we have added a specific layer of services for CSCW using XML technology extensively (figure 1). This construction comes close to an XML middleware, which can support document sharing through dedicated, distributed shared workspaces allowing co-operation awareness feedback and the co-ordination and evolution of both collective and individual activities. These activities are encoded according to a conceptual model derived from the DARE project [5] that has been captured into some XML Schemas. Since DARE is not yet implemented in a fully operational system, we have chosen to integrate DARE concepts into the operational Kakani & Tripathi role-based collaboration model [13]. Kakani’s model and DARE emphasise the Role concept, a way to personalize the access to a resource (a document or a tool) according to user roles in the activity, the state of this activity, and the interaction context (user profiles, technological platforms, mobility). The following figure 2 gives a simplified view of our interpretation of Kakani & Tripathi’s metamodel for co-operative activities and the relationships between main concepts. Task, RessourceType and RoleType are DARE translations of Kakani’s ActivityTemplate, ObjectType and Role model concepts. Most of the actions, through the user interface on the active activity space, generate events (XML messages also) that are delivered asynchronously to all entities currently involved in the same collective activities. Our scheme is closed to those using an XML and Event-Based middleware for coordination and distributed Workflows [12] [13]. According to the observations of Kortuem et al. [14], these technological choices are suitable for the support of mobility.

OwnerRole Admission Constraint Admission Rules

Owner Role

CreatorRole Creator Role RoleType

Composition

Task

Implies Roles

Behaviour

ResourceType atomic manipulations

Operation ProtectedObject

Protection

Permission

ACL

ACL_Entry

Fig. 2. The Tripathi & Kakani’s role-based collaboration model adapted in “Reciprocity” project

88

4

F. Hoogstoel et al.

Related Work and Future Developments

Our project shares some common ground with others who have tried to redefine the role of collaborative technology within an L3 context. For example, like us, Fischer et al. [15] have pointed out that the development both of social capital and of the role of social recognition has a globally reciprocal nature. Other recent works also share some of our views. For instance, there have been attempts to exploit the potential of P2P technologies in digital learning. Among them, Edutella [16] works to extend file sharing in P2P in order to share learning objects. The program seeks to pool the educational resources distributed among different institutions. For that purpose, it has derived powerful metadata, built on the RDF metadata standard of the W3C. Our approach is complementary both because we also focus on supporting co-operative activity, and because we share the same technological environment: JxTA. Kreijns and Kirschner [17] share some of our ideas about the power of an event-based approach to architecture. In this work, the events are processed by a dedicated event-server like SIENA. This choice is interesting because of the potential for widespread adoption of the Publish/ Subscribe mechanism for the loose coupling of distributed entities and also because of the system’s potential scalability. However, Kreijns and Kirschner proposals don’t conform to our distribution requirements. Existing P2P groupware platforms like Groove (http://www.groove.com) are tailorable insofar as they allow some end-users to configure shared workspaces by adding predefined tools and members, assigning predefined roles and changing permissions associated to roles. They also allow developers to create and integrate new tools. But these platforms are not expansive and don’t support co-evolution because end users can not fully and cooperatively define the group activity and integrate external tools. In order to continue the development of our project, several tasks must be accomplished. Some are short-term tasks, such as completing the implementation of our XML middleware for collective activity and providing a set of collaborative activity patterns as a bootstrap for new users. Other short-term tasks include the improvement of our distributed shared workspaces to insure compatibility with the new office suites for direct management of XML documents, and the introduction of new Role-Based, Access Control security services that are compatible with our role-centered model of the human activity (see figure 2). Other tasks are more long-term ones, such as designing an activity modeler that allows users to design and modify the activity specifications themselves, both graphically and collectively, at run-time (a reflexive characteristic). We are planning future experimentation with learners distributed in a network of communication and information technology consultants, working alone or as part of several different small companies. These experiments will emphasize:

the capacity of actors to assist the evolution of their environments, and to go beyond the co-operative activities provided as a bootstrap by designing new ones; the social and psychological behavior of users facing a non-governed system based on a P2P approach..

The Reciprocity Project. A P2P Meta-groupware

89

References 1.

2.

3. 4. 5. 6.

7.

8.

9. 10. 11. 12. 13.

14.

15.

16.

17.

Hoogstoel Frédéric, Une Approche Organisationnelle du Travail Coopératif Assisté par Ordinateur – Application au Projet Co-Learn, PhD Thesis n°1487, Computer Science, University of Lille 1, France (1995) Hoogstoel F., Tarby J.-C: Integrating a User Interface Design Method in a CSCW Framerd work, Proceedings of 3 International Workshop on Groupware CRIWG'97, Madrid, Spain (1997) D’Halluin C. (Coord.): Usages d’un environnement médiatisé pour l’apprentissage coopératif, Les cahiers du CUEEP, numéro 43 (janvier 2001) Nardi B.A. (dir.), Context and Consciousness: Activity Theory and Human Computer Interaction, Cambridge, MIT Press (1996) Bourguin, G.: Un support informatique à l’activité coopérative fondé sur la Théorie de l’Activité : le projet DARE. Ph.D. Thesis, Computer Science (2000) Bourguin; G. Derycke, A. Tarby, J.C.: Beyond the Interface: Co-Evolution inside Interactive Systems – A proposal founded on Activity Theory. People and computer XV – Interactions without Frontiers, Blandford, Vanderdonckt, Gray (eds.), Springer Verlag, pp 297– 310 (2001) Kuutti K., The concept of Activity as a Basic Unit for CSCW Research, in L.J. Bannon, M. Robienson, K. Schmidt (Eds), Proceedings of the second ECSCW, Kluwer Academical, Amsterdam, p. 249–264 (1991). Hoogstoel F.: Chapitre 4 Les répercussions du travail coopératif assisté par ordinateur sur les systèmes d’information, in Kolski: Environnements évolués et évaluation de l’IHM. Interaction homme-machine pour les SI 2, Hermès (Eds) (mai 2001) Walker, J. Links and Power: the Political Economy of Linking on the Web. Proceedings of Hypertext’02, June 11–15, 2002, College Park, Maryland, USA, ACM press, pp 72–73. Agre, Ph. P2P and the Promise of Internet equality. In Communications of the ACM, February 2003, vol. 46, n°2, pp 39–42. Barkai, D. Technologies for Sharing and Collaborating on the Net. In proceedings of the first International Conference on Peer-to-Peer computing (P2P’01), IEEE Press. Busler, Ch. P2P in B2BI. Proceedings of the 35th Hawaii International Conference on System Sciences, IEEE press, 2002. Tripathi, A. Ahmed, T. Kumar, R. Jaman, S. Design of a Policy-Driven Middleware for Secure Distributed Collaboration. In proceedings of the IEEE International Conference on Distributed Computing Systems, Vienna, Austria, July 2–5 2002. Kortuem, G. Schneider, J. Preuitt, D. Thompson, T. Fickas, S. Segall, Z. When Peer-toPeer comes to Face-to-Face: Collaborative in Mobile Ad hoc Networks. Proceedings of the first International Conference on Peer-to-Peer Computing (P2P’01), 2002, IEEE Press. Fischer, G. Scharff, E. Yunwen, Y. Fostering Social Creativity by Increasing Social Capital. In Social Capital, Huysman, M. Wulf, V (eds). (http://www.cs.colorado.edu/~yunwen/papers/social-capital-2002.pdf ) Nejdl, W. Wolf, B. Qu, C. Decker, S. Sintek, M. Naeve, A. Nilsson, M. Palmer, M. Risch, T. EDUTELLA: A P2P Networking Infrastructure Based on RDF. Proceedings of the WWW’02 conference, ACM press, May 7–11, 2002, Hawaii, USA. Kreijns, K. Kirschner, P. Group awareness widgets for enhancing social interaction in computer-supported collaborative learning environments: design and implementation. In nd Proceedings of 32 ASEE/ IEEE Frontiers in Education Conference, November 6–9, 2002, Boston, MA, pp T3E-14 – T3E-20.

Symba: A Tailorable Framework to Support Collective Activities in a Learning Context Marie-Laure Betbeder and Pierre Tchounikine LIUM, Université du Maine Avenue Laënnec, 72085 Le Mans cedex 9, France {Betbeder,Tchounikine}@lium.univ-lemans.fr

Abstract. We present an approach that aims at introducing tailoring capacities in a framework designed to support collective activities in a learning context: students state their organization (using a task conceptual notion modelled following Engeström’s triangle) and are then proposed with a reification of the adopted organization, and, in particular, the set of tools they have asked for. This approach has a double advantage, making students achieve a reflective analysis of their activity and enabling them to tailor the activity-level environment without having to cope with a programming-like tailoring language.

1 Introduction The general context of this work is the design of Web-based frameworks that support Collective Activities in a Learning Context (CALC). We study, through iterative experiments, what features can be introduced in a framework in order to support students’ activities and make them practice (and learn how to manage) collective work. The literature and are own previous experiments highlights that when facing collective activities (1) students experience great difficulties in structuring their organization and (2) it is not possible to predict how students will organize themselves and, consequently, the tools (e.g., Chat, Mail or file exchange tools) that they will use (and how) to achieve their activity. Therefore, a framework designed to support such CALC must support the students in organizing themselves, but it must also permit students to decide the tools that should be accessible in order to achieve the tasks they define: it must be tailorable. In this paper we propose an approach based on the principle of delegation of tasks. The task notion is proposed to the students as a conceptual tool that enables them to describe their organization (plans as list of tasks, delegation of tasks to individuals or subgroups) and the tools they want to be accessible when achieving these tasks. Tailorability is provided by (1) the fact that students can define the tools and resources that will be accessible to them when achieving the tasks they have planned and defined and (2) the fact they can delegate some specific tasks to some software agents.

J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 90–98, 2003. © Springer-Verlag Berlin Heidelberg 2003

Symba: A Tailorable Framework to Support Collective Activities in a Learning Context

91

Section 2 presents the interest of tailorability in a CALC context and the general principles that we propose. Section 3 presents how we have put these principles into practice in Symba, the framework we have currently developed and experimented. The paper is illustrated with examples from our experimental field, a computer scith ence curriculum (5 year of University) that mixes face-to-face and distance students. Within this curriculum we consider activities1 such as proposing to subgroups of 6-7 students to collect some information about a given subject and then to collectively construct a synthesis by confronting their points of view2 through Symba. Such an activity mixes individual and collective phases, that can be performed synchronously or asynchronously and correspond to collaboration or cooperation (this is why we use the “collective” term).

2 Interest of Tailorability and General Principles 2.1 Tailoring the Support Proposed by a Framework within a CALC Many works from the CSCW and CSCL communities have emphasized that groupwares rigidity is a core problem. The support required by a particular group at a particular moment depends on different context-dependent features and, in particular, the organization it has adopted. This organization, as pointed out in our experiments [3] and in the literature [14][4][5], cannot be anticipated (given an identical situation, groups adopt different organizations and, in any case, this organization generally evolves during the activity). Designing a framework that is supposed to support students must face this central challenge. A computer system is said tailorable if it proposes its users with some means to modify itself in the context of its use, as one of its functionalities [10][11]. Tailorability, if it focuses on making the appropriate support arise and meet the students’ needs [2], appears a promising approach. 2.2 Tailorability as a Means to Make Students Work Out Organization Features In the context of CALCs, providing tailorability features has a double advantage. First, it allows students to achieve the work within a framework that proposes a support adapted to their wills. Second, in order to define this support, students have to practice a reflective activity on their organization. This is of a particular interest for us as it 1

2

The “activity” term will used in this paper to denote both what students are asked to do (the “pedagogical activity”) and in the broader sense of “students’ activity”. Additional precision will be made when the context is not clear enough to distinguish these meanings. As an example, in the last experiment students had to identify how conceptual maps can be used to describe a curriculum (step 1), propose different individual points of view (step 2) and then construct collectively, from their individual productions, a conceptual map describing their curriculum (step 3). Such activities are designed with a double pedagogical objective, making students work on some feature of the curriculum domain and making them practice collective work.

92

M.-L. Betbeder and P. Tchounikine

corresponds to our core pedagogical objective, and we believe it is interesting for most CALCs situations. We distinguish three natures of support to be provided to students, each of them associated with a kind of tool (in the sense intended by the activity theory [7]): (1) conceptual support such as the one provided by the task notion, a “conceptual tool” that allows students to conceptualize the work to be achieved, (2) support to achieve a task such as the one provided by “general-purpose tools” (e.g. a Mail tool or a file exchange tool, that can be used as means to achieve different tasks) and (3) task handling support provided by “task oriented tools”, i.e., tools that achieve specific tasks (e.g., collect different students’ productions and make them available to the group or organize a vote). The form of tailorability we propose addresses issues (2) and (3) and is based on the following two-step principle. First, in accordance with the pedagogical objective of making them aware of the need for organization, students state their organization explicitly (the objective is not that the framework should adapt itself automatically to the students needs): they identify and describe the tasks to be achieved (e.g., objectives, actors, tools to be used, dates or input and output) and structure them as plans. They are then proposed with an activity-level that reifies the adopted organization (list of tasks descriptions) and provides the general-purpose and task-oriented tools they have asked for. As an example, within the type of activities we consider, students can state that they want to be proposed with an interface that embeds a frame to browse their individual productions, a Chat to confront their ideas synchronously and a voting tool (this last being, in our framework, a task-oriented tool). Tailorability could be further introduced at the conceptual tools level, i.e. by proposing different possible modelling primitives or parametrizable primitives. We however consider that this level of tailoring appears too confusing in a learning context and propose (for the moment) a single primitive, the task notion, that can be linked both to Newell’s rational principle [12] and the activity theory notions [7]. 2.3 Discussion Making students explicit their organization addresses both the general objective of supporting them in their collective task and our core pedagogical objective of making them work out organizational features. This must not be understood as a desire to make students bury their organization in intangible plans. We believe it is pedagogically unsuitable (and in fact unrealistic if one adheres to Suchman’s situated action ideas [14]) to constrain students to follow exactly a priori plans. Plans are used here as proposed in [1], i.e., means to organize the work and reflect the responsibility of the involved actors. When achieving their work, students can follow or not the adopted organization. However, a minima, making students explicit their plans makes them address organizational issues and, as the organization is reified in the tool, it can serve as a basis (an intermediation role) for debriefing activities with the tutor during and after the activity. Within our approach students have however an additional reason

Symba: A Tailorable Framework to Support Collective Activities in a Learning Context

93

(that they perceive directly) to work out and explicit their organization: it allows them to define what tools will be accessible to achieve their work.

3 Principles of the Approach Adopted in Symba 3.1 General Theoretical Background: The Activity Theory We consider the overall pedagogical activity that the students are proposed with as a set of n “situations” in which actors have to achieve a task whilst respecting a set of rules and by the means of a set of tools. Each task is viewed as an instance of the model issued from the activity theory [7] known as the Engeström’s triangle [6] (the production aimed systemic model constituted of the subject, the object, tools, community, rules and division of labour). This model and the mediation relationships it highlights [8] are the conceptual notions that the students are proposed with in order to conceptualize their organization (this prescriptive use of the Engeström’s triangle is a working hypothesis). 3.2 The Task Definition / Delegation Principle A classical problem when designing a tailorable system lies in the tailoring language. Users cannot be expected to be skilled programmers. Moreover, as the tailoring will occur while using the system, the way users can tailor their system must be related to their current task so that they don’t have to leave the application domain to work on the underlying domain of programming, a shift that would cause a breakdown in the activity flow [9]. Within our context, the tailoring occurs while organizing the collective work. It must therefore be expressed in an organizational semantic. The approach we propose is to define the tailoring through a “task definition / delegation” semantic. Instead of presenting students with a predefined framework whose functionalities can be tailored, we ask them to declare their organization by specifying a plan as a succession of activity-level tasks (e.g., “discussion” or “vote”) and delegating each of these tasks to an individual or a subgroup of students3. This is achieved through dedicated interfaces. Symba’s task description interface (Fig. 1, right part) denotes Engeström’s triangle notions. For every task, the students have to define the objective (in natural language), the nature (individual or collective), the subject (an individual, a sub-group, all the group), the beginning and ending dates (rules), the tools (the general-purpose tools that will be accessible at the activity-level to achieve this task), the resources and production (files names). The system dynamically generates a natural language explicitation

3

From another point of view: organization is a meta-level task that consists in defining and delegating activity-level tasks. For this meta-level task the subject is the group and the tools are (1) the conceptual notion of task (students must conceptualize their activity as tasks) and (2) editors that enable students to define the plan and its tasks. As stated before, these features are not tailorable.

94

M.-L. Betbeder and P. Tchounikine

of the description in order to avoid possible misunderstandings of the interface. The description (and, therefore, the support provided by the framework) can be changed at any time (including while the task is achieved). The students can design the overall organization as a plan (Fig. 1, left part). A plan defines how the students intend to decompose the general task they have been proposed with into subtasks and how these subtasks will be scheduled (each of these subtasks being further described with the task editor). In order to help students, the plan editor proposes a set of predefined abstract tasks types. As an example, given the type of activities we propose the students with, we propose tasks types such “search for information”, “analyze production” or “discussion”, that the students then customize through the task editor. The list of tasks types is to be defined according to the pedagogic context. Students can also define new types of tasks if required. Let us recall that the plans we are concerned with here are (1) means to make students work out organization features (before, while and after achieving the work) and (2) resources to carry out the work [1]. A plan does not intangibly determine the students’ activity, it reifies how they perceive their organization. Both task and plan editors interfaces are shared, students can connect themselves synchronously and browse the plan / tasks while they define it (all of the students see the interface, one of them can modify it, using a turn taking system). The editors are associated with a Chat (not visualized in Fig.1) that enables students to discuss synchronously about the tasks and plan descriptions. Actors

Objective

Nature Dates Production

Predefined tasks

Tools A plan (sequence of tasks)

Software agents tasks Definition of new types of tasks

Re-

Generated description

A plan is described through the plan editor (left snapshot) by defining or selecting tasks from the list of predefined tasks and scheduling them. The right snapshot presents one of the tasks’ definition through the task editor. Its description in natural language generated by the system is: every actor (of the group) must elaborate a criticism from the file “Concept_Relation.doc” and put the result in the file “Critique_FOAD.doc”; the tool that is asked for is a file exchange service.

Fig. 1. Plan and task editors (snapshots from the experiment)

We use this task definition / delegation principle as an unifying way to introduce the two different forms of support presented in §2.2., general-purpose tools and taskoriented tools.

Symba: A Tailorable Framework to Support Collective Activities in a Learning Context

3.3

95

Task Definition / Delegation as a Means to Specify the Activity-Level General-Purpose Tools

When constructing a plan by instantiating and scheduling tasks types such “search for information” or “analyze production”, students describe what they intend to do and how they intend to do it, i.e., what tools they want to be proposed with at the activity level. From each task description is generated a Web page that proposes an integrated access to the different general-purpose tools and resources that have been asked for (cf. Fig. 2, an activity-level generated for a task which tools are a browser and a chat). This Web page is the frame within which the students will achieve the task. Symba does not embed specific tools, it allows an access from the framework to external tools (“integration” approach) 4. The framework is therefore evolutive: adding a tool to Symba (i.e., enabling the students to use it) requires describing the tool in order to allow the students to understand its possible uses and programming a piece of software that generates an access to this tool when the students select it.

Access to the plan and task editors

Frame to browse the resources (a conceptual map)

Access to the activity-level environment

Activitylevel

Chat

Fig. 2. Snapshot of a generated activity-level environment

3.4 Task Definition / Delegation as a Means to Integrate Task-Oriented Tools We have introduced in §2 a distinction between “general-purpose tools” (e.g., a Mail tool) and “task oriented tools”, i.e., tools that are identified as achieving a specific task (e.g., collect different students’ productions and make them available to the group or organize a vote). Within this distinction lies a large part of CALC frameworks flexibility problem. Groupwares that only propose general-purpose tools do not constrain 4

Three levels of tailoring can be distinguished [10]: customization (modifying the system by choosing its attributes’ values from a predefined set), integration (adding new functionalities to the system by linking predefined components together with an integration language) and extension (adding new code to the application). Components integration is a research domain in itself, and how heterogeneous software components can be integrated is the object of a large amount of studies [4]. Tools integration in Symba is of course a very light approach, but, given our objectives, sufficient.

96

M.-L. Betbeder and P. Tchounikine

the students but offer them a limited support. At the other side of the spectrum, groupwares that implement complex processes support students if they adhere to the underlying organization, but constrain them if not. Within Symba, services such as “collecting documents from the different actors” or “organizing a vote” (i.e. task-oriented tools), that are traditionally implemented as functionalities embedded in the framework, are defined as predefined tasks that can be delegated to software agents. These tasks are proposed with the others in the set of predefined abstract tasks proposed by the plan editor (Fig. 1). In other words, we provide a service to the students’ community by integrating in this community a software agent that proposes the required competence to the community rather than by a blackbox tool. Within this approach, students do not use tools, they define a task to be handled by a software agent, in a similar way that they define some other tasks to be handled by human agents. The emphasis thus remains on organisational features (defining and delegating tasks), i.e., the point we want them to work out. We have defined and implemented three software agents in the current Symba version: Nicolas can find a date for a meeting when (for example) a group prepares a synchronous meeting. Chick can organize a vote when the group must decide something collectively. Colin can handle document flow produced or to be used by the group. These agents communicate with the students by Chat, Email and file transfer directly (Email) or within the activity level (e.g., resources handling). Their precise definition (e.g., dates and ballots for a vote) are defined through the task editor, similarly as the tasks delegated to human agents. Due to limitation place these agents issues are not emphasized here, see [15] for details.

4 Conclusions We have presented an approach to the tailoring of CALC frameworks where students state their organization and are then proposed with a reification of the adopted organization, and, in particular, the set of tools they have asked for. This approach has a double advantage. First, when defining the plan and its tasks, students achieve a reflective activity on the process, the objectives, the resources and products, their method for working collectively or the best fitted tools. Second, through this process, they can tailor the activity-level environment of each task. The task definition / delegation principle is used as a unifying way to tailor the support that is provided by the framework: students define what has to be done and how for all of the tasks, the environment generates an activity-level that embeds the tools that have been asked for (for general tasks) and/or provides software agents that can achieve some particular given tasks (task-oriented tools). From the tailorability point of view, the approach we propose is general, Symba is one of different ways to put it into practice. It opens different challenging questions to be studied such as how students react to such tailoring capacities or what type of services (task-oriented tools) can be proposed as software agents (including proposing agents that perform a given task following different protocols or means). It will be

Symba: A Tailorable Framework to Support Collective Activities in a Learning Context

97

interesting to propose different approaches to the description of a plan in order to analyze what types of representations are used by students and how they use them and to study (through successive experiments) the crystallization that could denote the definition and reuse of new types of tasks and/or of plan patterns. From a pedagogical point of view, we believe that Symba can be used as an integrative framework for collective activities when supporting organization and/or providing tailorability features can be of additional value. For instance, Symba is a possible way to operationalize collective activities designed from the Tecfa seed catalog [13], that proposes a paper-based set of pedagogical tasks/scenarios and associated tools. A first experiment (a two months activity performed by two groups of 7 students) allowed us to validate the overall approach and the way we put it in practice. From a pedagogical point of view, the experiment demonstrated the very positive impact of the organizational features proposed by the framework on the students’ activity, who used extensively the framework to work out their organization. As expected, we noticed a few occurrences of students not following exactly the a priori plan. In most cases they however explicited the new plan through the editor. A posteriori interviews allowed us to confirm the intermediation role that the plans and tasks description play. The students did not encounter any difficulty with the plans and tasks notions (let us however recall that they are computer science students, this must be further analyzed with other publics). The general-purpose tools were used coherently with the tasks’ descriptions (although students punctually used other means)5, the software agents raised interesting issues (in particular, it appears that software agents must be fault-tolerant [15], much more than “real” students). The objective of this first experience was limited to studying if and how students used Symba, now that this is validated we plan to proceed to different experiments.

References 1. Bardram, J. E.: Plans as situated action: an activity theory approach to workflow systems. In: proceedings of ECSCW’97, Lancaster, UK (1997) 17–32 2. Bentley, R., Dourish, P.: Medium versus mechanism: Supporting collaboration through customisation. In: proceedings of ECSCW'95, Stockholm, Sweden (1995) 133–148 3. Betbeder, M-L., Tchounikine, P.: Une expérience d'activité collective médiatisée via le Web dans une FOAD, In: proceedings of TICE, Lyon, France (2002) 263–271 4. Bourguin, G., Derycke, A.: Integrating the CSCL activities into virtual campuses: Foundation of a new infrastructure for distributed collective activities. In: proceedings of EuroCSCL, Maastricht, Netherlands (2001) 123–130 5. Dourish, P., Edwards, K.: A Tale of Two Toolkits: Relating Infrastructure and Use in Flexible CSCW Toolkits. Computer-Supported Cooperative Work, Vol.9(1) (2000) 33–51

5

To what extent expliciting the organization and using the tools provided by the framework is presented as mandatory is a pedagogical issue, that concerns the human teachers that define and/or tutor the activity. For instance, in our 5th year of University context, the framework is a proposition: if the students are not satisfied with any aspect of the framework, they just skip to other means.

98

M.-L. Betbeder and P. Tchounikine

6. Engeström, Y.: Learning by Expanding. An activity-theoretical approach to development research. Orienta-konsultit, Helsinki (1987) 7. Kuutti, K.: Activity Theory as a Potential Framework for Human-Computer Interaction Research. In Nardi B.A. (eds.), Context and Consciousness (1996) 17–44 8. Lewis, R.: Human Activities in Learning Societies.In: Proceedings of ICCE/ICCAI. Vol. 1, Tapei, Taiwan (2000) 36–45 9. Malone, T. W., Lai, K.-Y., Fry, C.: Experiments with Oval: A Radically Tailorable Tool for Cooperative Work. ACM Transactions on Information System, Vol. 13 (1994) 177–205 10. Morsh, A.: Three Levels of End-User Tailoring: Customization, Integration, and extansion. Third Decennial Aarhus Conference, Aarhus, Denmark (1995) 41–51 11. Morsh, A., Mehandjiev, N. D.: Tailoring as Collaboration: The Mediating Role of Multiple Representation and Application Units. In: proceedings of CSCW'2000, Kluwer Academic Publisher (2000) 75–100 12. Newell, A.: The Knowledge Level, Artificial Intelligence, Vol. 18 (1982) 87–127 13. Schneider, D., Dillenbourg, P., Frete, C., Morand, S., Synteta, P. : Le TecfaSEED Catalogue, manuel des enseignants (2002) 14. Suchman, L. A.: Plans and situated action: the problem of human-machine interaction. Camridge University Press (1987) 15. Taurisson, N., Tchounikine, P.: Mixing Human and Software Agents: a Case Study. In: proceedings of ICALT, Athens, Greece (to appear) (2003)

The Impacts of Awareness Tools on Mutual Modelling in a Collaborative Video-Game Nicolas Nova1 , Pierre Dillenbourg1 , Thomas Wehrle2 , Jeremy Goslin2 , and Yvan Bourquin2 1

2

CRAFT EPFL CH-1015 Lausanne Switzerland {nicolas.nova,pierre.dillenbourg}@epfl.ch http://craft.epfl.ch TECFA Route des Acacias, 54 CH-1227 Carouge Switzerland [email protected],[email protected] [email protected]

Abstract. This paper describes the ﬁndings of an experimental research concentrating on collaboration in a multi-player video game. The overall goal is to study the cognitive impacts of the awareness tools. The focus is in ﬁnding an eﬀect on performance as well as on the representation an individual build of what his partner knows, plans and intends to do (i.e. Mutual Modelling). Using an awareness tools has a signiﬁcant eﬀect by improving task performance. However, the players who were provided with this tool did not show any improvement of their mutual modelling. Further analysis on contrasted groups revealed that there was an eﬀect of the awareness tool on mutual modelling for players who spent a large amount of time using the tool.

1

Introduction

The challenge of today’s collaborative systems is to overcome the computer limits so as to make participants and their activities visible to one another. This is called awareness: the understanding of the teammates’ activities and interactions in the workspace. For nearly ten years, awareness has become a new research ﬁeld particularly for CSCW (Computer Supported Collaborative Work) and CSCL (Computer Supported Collaborative Learning). Being (and also remaining) aware of others is as important in everyday life as in groupware systems. The lack of information about the others in multi-user environment is addressed by providing users with tools that try to ”recreate the information landscape of a real-world landscape” [1]: the awareness tools (from now on called AT in this paper). Consequently, the AT are in general supposed to enable users to oﬀset the lack of social interactions. They also provide a more eﬃcient team collaboration by showing information about presence (is anyone in the workspace?), identity (who is that?), location (where is an individual?), action (what is somebody doing?), etc. In the ﬁeld of Human-Computer Interaction, there have been relatively few occurrences of research concerning the empirical evaluation of awareness tools. J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 99–108, 2003. c Springer-Verlag Berlin Heidelberg 2003

100

N. Nova et al.

Few studies provide data about the use of AT [2] and the usability issues of AT [3] [4]. The objective of our is to examine the impact of AT on what is called mutual modelling. Mutual modelling is the representation and the expectations that an individual constructs and maintains of what his/her partner knows, does, believes and intends to do. We have investigated whether providing peers with AT can help building more accurate mutual models and being more eﬀective. It is important to investigate the cognitive beneﬁts of mutual modelling as it can be postulated that maintaining a representation of the other’s viewpoint explains some of the results of collaborative learning. As a matter of fact, collaboration eﬀects seem produced by diﬀerent kind of collaborative interactions (explanation, argumentation,...) that require to develop a shared understanding of the task. In order to detect misunderstandings and disagreement during the interactions, the subjects must maintain some representation of what their partner understands. It can be postulated that the eﬀort for maintaining a model of the partner contributes itself to the learning process as it forces the learner to reason more deeply on the domain and to perceive the task from a second viewpoint. Now, this raises an old educational issue: if we support mutual modeling with awareness tools, do we facilitate learning and hence expect higher learning gains or, conversely, do reduce the cognitive eﬀort and hence decrease the learning gains to be expected ? This research, by augmenting mutual modeling with awareness tools, is a ﬁrst step to grasp the cognitive eﬀects of awareness tools and mutual modeling.

2

Methodology

In order to reach that goal, a computer game was employed to conduct experiments. In this game, two players located in diﬀerent rooms are involved in a space mission where they were required to collaborate. 2.1

Spaceminers: A Collaborative Video-Game

SpaceMiners is an experimental platform in the form of a video game for running psychological experiments. It has been developed at the Geneva Interaction Lab (University of Geneva) by Yvan Bourquin, Jeremy Goslin and Thomas Wehrle. As can be seen on ﬁgure 1 the space is represented by a grid with planets, asteroids, the spacestation (the circles on the left) and the spaceship explorer. The line shows the trajectory of a launched drone. Here, the direction is modiﬁed by the planet’s gravity. The purpose of the mission represented here is to collect the largest amount of minerals located in asteroids and to bring them to the space station on the left. The score represents the number of collected minerals docked to the space stations launched by the two players. The score is inﬂuenced by several factors such as: the drone trajectory, the launch speed, the tools positions (that inﬂuence the drone trajectory), the number of asteroids in the environment, the planet positions (that modify the gravity).

The Impacts of Awareness Tools on Mutual Modelling

101

Fig. 1. The game environment made up of a planet, asteroids, two spaceships and a space station. This kind of view can be seen in the camera mode. This screenshot hence depicts the camera view (since we see the spaceship) as indicated in the upper left-hand corner. David (the player who controls the ship) manages to collect asteroids and to dock his drone to the space station. Thus he wins 7 points

Users can play in two modes that corresponds to two viewpoints: the explorer mode and the camera mode. They can switch from one mode to another by pressing a key on the joystick. In the explorer mode, the position of the spaceship is ﬁxed and players launch drones that pass through as many asteroids as possible on their way to the space station. Once the drones are launched players have no control over them. Their trajectory depends on the direction of the explorer and the launch speed of the drone controlled by the player and on the gravity of planets. Additionaly, diﬀerent tools dragged into space by players could modify the drone’s trajectory. In the camera mode, players can move their camera around in space by moving the joystick. The camera is very useful to see space from another viewpoint and to place tools in space. To distinguish this mode from the other, there is no crosshair and no green border around the screen. Fig. 1 shows the space and the ship seen by the camera. Fig. 2 shows the camera as it can be seen in the explorer mode. In our experiment, we focused on one kind of awareness tool: the view of the partner’s camera and his laser pointer as presented in Fig. 2. By seeing the camera of his partner the player can obtain awareness information about his team-mate location and gaze. Thus he could help him to drop tools into space or

102

N. Nova et al.

Fig. 2. View of the camera. This view can only be seen in the explorer mode (from the spaceship)

to adjust the trajectory of the drone the partner intends to launch. The presence or absence of this awareness tool constitutes the experimental condition of the study. There are two tools that can be dropped in space or dragged behind the player’s camera: the blackhole and the gate. The blackhole has a very high gravitational pull: it pull drones towards it. Gates are stabilised entrances to wormholes in spacetime. If two are placed in space then a gate will transfer a drone from one position in space to another instantaneously. Players sees the tools available represented in a toolbox. When someone drops a tool in space, the tool’s icon is removed from the toolbox and the object stands in space just behind the player’s explorer. If he wants to see it, he has to make a rotation. The tools available depends on the level of the game. In level one, players are given no tools. In level two and three, each player has diﬀerent tools in order to foster collaboration between them. In level 2, each player has only one gate. In level 3, one player has blackhole and a gate and the other has only one gate. The procedure of collaborative problem solving consists in the fact that the two players need to negotiate about the position of those tools in space. It is not possible to ﬁnish the three levels without talking to each other or deciding where to put a tool. Another collaborative behavior is to help the partner to navigate, to drop a tool, to adjust his/her shoot as well as role distribution. SpaceMiners is a video game designed to elicit collaborative behaviour. The use of a game metaphor has the advantage that it allows the presentation of complex problem solving tasks in an enjoyable environment, thus maintaining a

The Impacts of Awareness Tools on Mutual Modelling

103

high level of motivation amongst subjects. However, these statements only hold for subjects that ﬁnd such games enjoyable, those with little interest in games can fail to engage with the game, ﬁnding both the task and the interface diﬃcult and confusing. 2.2

Variables

The presence or absence of the awareness tool constitutes the experimental condition of the study: it is our independent variable. We used two dependent variables in order to test our hypotheses: task performance and mutual modelling. Concerning task performance, we used the pairs’ score: player A’s score added to player B’s score. Concerning Mutual Modelling (MM), two diﬀerent questionnaires (presented in Table 1 and Table 2) allowed us to calculate an evaluation the value of MM for a pair. First, during the game and for each of the three levels, players had to answer to two multiple choice questionnaires. Those questionnaires asked them about what they are intending to do at the moment (guiding his partner, trying to understand his strategy, trying to establish a common strategy, adjusting a shoot, etc.). Then, the questionnaires asked each player about what he thinks his partner is currently doing (same propositions as the previous questionnaire). We compared the ﬁrst answer of a player (about what A is intending to do) to the answer of his partner to the second question (about what B believes A is doing). Consequently, our evaluation of the MM accuracy is the number of common answers to those two questions. We compared whether A’s prediction of B’s answer matches with B’s actual answer. Thanks to those MM evaluation, we could deﬁne diﬀerent variables presented in Table 3. In game level 1, questionnaires are displayed 5 minutes after the beginning. In levels 2 and 3, questionnaires are displayed after the ﬁrst time a player dropped a tool in the environment.

Table 1. Questions asked in the ﬁrst mutual modelling questionnaire in each of the three levels What do you intend to do now ? Adjusting a shoot Tune my drone launch speed Guide my partner Understand what my partner wants to do Establishing a common strategy with my partner Understanding my drones’ trajectory Understanding the trajectory of my partner’s drones Drop a tool to deviate my drones Drop a tool to deviate his drones’ trajectory Other

104

N. Nova et al.

Table 2. Questions asked in the second mutual modelling questionnaire (displayed after the ﬁrst one) in each of the three levels What do you think your partner intend to do know ? Adjusting a shoot Tune my drone launch speed Guide me Understand what I want to do Establishing a common strategy with my partner Understanding his drones’ trajectory Understanding my drones’ trajectory Other Table 3. Description of the dependent variables concerning Mutual Modelling Evaluation

Description

MM1

Mutual Modelling evaluation for the pair measured in the ﬁrst level MM2 Mutual Modelling evaluation for the pair measured in the second level MM3 Mutual Modelling evaluation for the pair measured in the third level MMg = MM1+MM2+MM3 Global Mutual Modelling evaluation for the pair

2.3

Hypotheses

We postulate three hypotheses: Hypothesis H1: Pairs with the awareness tool are more eﬀective than pairs without it. As a matter of fact, the information brought by the AT can enable players to complete the task more eﬃciently. In order to evaluate the performance, we use the team score, sum of the two players’ scores. Then we expect that the team score is higher when players have an awareness tool. Hypothesis H2: Pairs with the awareness tools build more accurate model than pairs without it. The global mutual modelling evaluation (MMg) should be higher when the players have an awareness tool. The MMg is the sum of the objective evaluations of the mutual modelling of a team during the whole game, measured by the in-game questionnaires. Hypothesis H3: the mutual modelling accuracy improves with time: when partners learn to know each other, the representation of each others’ strategies is more accurate. As a consequence, we expect MM3 to be higher than MM1. 2.4

Participants, Settings, and Procedure

Participants were recruited in Geneva. We chose only men familiar in order to avoid gender bias. Experimental subjects consisted of 18 pairs (N=18). Those

The Impacts of Awareness Tools on Mutual Modelling

105

pairs were assigned to one of the experimental conditions forming two groups of 9 pairs. Participants were assigned a partner they were not familiar with. The game was played on two computers over the local network. Each player sit in front of a distinct computer located in diﬀerent rooms and could communicate by voice thanks to a headset. Experiments lasted approximately 2 hours and were conducted in French. After a tutorial, players had to complete three levels. Mutual modelling questionnaires were displayed during missions 1, 2 and 3.

3

Results

Most of the pairs (15) played the game during two hours. Only three pairs managed to ﬁnish the three levels of the game in less than two hours. Overall, it seems that most of the players liked the game Spaceminers and showed diﬀerent signs of presence, immersion and enjoyment. On the whole, they were all motivated; this could be due to the fact that we selected participants who like to play computer games and were used to play with joysticks.They did not ﬁnd the questionnaires to be disruptive since it took just few minutes to answer. According to hypothesis H1, the awareness tool enables pairs to increase their performance. We want to test the eﬀectiveness of using an AT. Table 4 shows the descriptive statistics. Table 4. Descriptive statistics for hypothesis 1 N

Mean

Std Dev Min Max

Score With AT 9 258.67 90.80 Without AT 9 175.67 67.48 Total 18

127 51 51

360 235 360

The descriptive statistics shows that pairs with AT reached higher score than the others. Besides, no pairs without AT reached the mean score of the pairs with AT. the ANOVA test conﬁrms that there is a signiﬁcant diﬀerences between the two conditions (F = 4.84, p = 0.043). Therefore, our ﬁrst hypothesis is validated: there is a signiﬁcant eﬀect of the awareness tool on performance. Our second hypothesis H2 is that the use of an awareness tool improves the mutual modelling accuracy of a pair. We assume that players with awareness tool have more accurate mutual modelling, that is to say: MMg (With AT) > MMg (Without AT). Table 5 shows the descriptive statistics. Table 5 shows that the MMg means are very close. It goes against our hypothesis and the ANOVA test shows that H2 is invalidated (F = 0.02, p = .889). The use of the AT does not improve the accuracy of the mutual modelling. The representation of one’s partner strategy is not facilitated by the information conveyed by the awareness tool. Our third hypothesis assumes that there is an eﬀect of time and collaboration on mutual modelling. At the beginning of the

106

N. Nova et al. Table 5. Descriptive statistics for hypothesis 2 N

Mean Std Dev Min Max

MMg With AT 9 1.63 Without AT 9 1.58 Total 18

0.48 0.87

1 2.67 0.83 3.17 0.83 3.17

game, the players are not familiar with each other. We hence postulated that playing together during two hours enables them to improve the accuracy of their mutual modelling. We assume that MM3 which is the evaluation of the accuracy of the mutual modelling measured in level 3 is higher than MM1 which is the evaluations of the accuracy of the mutual modelling measured in level 1. Table 6 shows the descriptive statistics. Table 6. Descriptive statistics for hypothesis 3 N

Mean Std Dev Min Max

MM MM1 18 1.33 MM3 18 1.94 Total 36

0.84 1.14

0 0.5 0

3 4 4

The descriptive statistics shows a slight diﬀerence between the means of MM1 and MM3. According to the test presented in table 4, concerning the eﬀect of time on the accuracy of mutual modelling, it is only a trend (F = 3.189, p = 0.084). We reject H3 with p = 0.084. Additionally, there is no eﬀect of the presence of the awareness tool (F = 0.105, p = 0.748). This result is consistent with the invalidation of our second hypothesis. There is also no interaction between time and the presence of the awareness tool (F = 0.105, p= 0.748). As a consequence, this supports the argument that the increase of the accuracy of the mutual modelling is not due to the presence of the awareness tool.

4

Discussion and Further Analysis

The fact that teams in the awareness tool condition reach higher score than the others is consistent with the ﬁndings of [3] and [5]. They also found that awareness can be beneﬁcial to team performance. In fact, this tool provide a continuous feedback to the partner who can see where is his team-mate. This could be extremely useful in tasks like object positioning. In such tasks, player A guided player B’s movement by giving him instructions about where dropping the object. Additionally, the AT provided visual evidences about the player’s location. The team is thus more eﬀective because player A had not to verbally describe where he is and player B had not to interpret this description. As

The Impacts of Awareness Tools on Mutual Modelling

107

suggested by [3], the use of the awareness tool leads to transform a task from a verbal to a visual activity. Our second hypothesis was invalidated, the representation of one’s partner strategy is not facilitated by the information conveyed by the awareness tool. Presumably, those results lead us to three possible conclusions. First, the awareness tool, by showing information about the partner’s locations and gaze does not improve the accuracy of the mutual modelling. Second, it is possible that the game does not require participants to maintain accurate mutual models, perhaps they do not have to build a very accurate representation of the partner’s intentions. And ﬁnally, perhaps, our evaluation of mutual modelling is not very precise. We also focused on behavioral data which were stored in the logﬁles. We looked speciﬁcally at the percentage of time spent in each view (camera or spaceship) by the pairs, we could notice an interesting diﬀerence. A two-way analysis of variance conducted on contrasted groups showed that pairs in the awareness condition who spent more time in the camera mode reached higher levels of mutual modelling (F = 8.02, p = 0.015) than the others. It implies that there is an eﬀect of the awareness tool on mutual modelling only for the teams who spent a long time in the camera mode. Awareness information could help players in order to estimate their partner’s strategies if the participants understand that they have to make an eﬀort: spending an accurate time in the camera view. The team who did not spend enough time in the camera view had no beneﬁt of the awareness tool. Our ﬁnding raises a new question: do players really used the awareness tool ? Indeed, if there is an eﬀect of the tool on mutual modelling only for the players who used it frequently, it may be possible that only a few players in the tool condition noticed the advantage of using it. Hypothesis 3 postulated an eﬀect of time on the accuracy of mutual modelling. There seems to be an eﬀect but it is not statistically signiﬁcant. Our hypothesis is invalidated but the ﬁndings call for certain restrictions because of the questionnaire. Using a simple questionnaire to measure the accuracy in predicting partners answers is way too subjective. We should use a more objective method to evaluate this variable. A solution would be to analyze the redundancy (i.e. the number of times player A performs an action that player B’s previously performed).

5

Conclusion

We explored the ﬁeld of research concerning the cognitive impacts of the awareness tools used in collaborative multi-user environments. The studies we have presented in this document address two issues: the eﬀect of the awareness tool on performance and the impact on the mutual modelling,. So far, only some ﬁndings conﬁrmed our hypotheses and intuitions. Some results, though seem to be contrary to expectations. Nonetheless, those results call for certain restrictions. On the one hand, the number of participants is quite low: eighteen pairs (nine in each conditions). On

108

N. Nova et al.

the other hand, we can also have reservations about the experimental design. Furthermore, the method used to measure the accuracy of the mutual modelling may be unsuitable. We could criticize the tool we used as well. Actually, we considered here the awareness as a simple tool that convey speciﬁc information about the participants’ behavior. In fact, awareness is not only this kind of ”widget”, the situation is more intricate. We should reconsider the deﬁnition of awareness as a diﬀuse ﬂow of information [6]: lots of diﬀerent cues, signs, evidences which are combined. This ﬂow makes sense and it is very diﬃcult to create a tool to enable this combination. There are several impacts for practitioners as well, for instance for CSCL. The ﬁndings provide evidence that location and gaze awareness can be useful in certain situations. Our ﬁndings could help produce recommendations for designers. As we mentioned above, the use of the awareness tool in Spaceminers leads to transform a task from a verbal to a visual activity and hence induce a quicker completion of the task. This a clear lesson for designers: instead of letting participants describing their locations or the artifacts they are talking about, an awareness tool could usefully show those kind of indications. Another interesting lesson is that designers should keep in mind that using an AT is not systematic. As we have seen in our experiment, several players did not really notice the potential of this tool. Thus, designers should provide users with usable AT and teach them their real value.

References 1. Gutwin, C. Greenberg, S. A framework of awareness for small groups in sharedworkspace groupware. (Technical Report 99-1), Department of Computer Science, University of Saskatchewan, Canada (1999) 2. Jang, C.Y., Steinﬁeld, C., Pfaﬀ, B. Virtual team awareness and groupware support: an evaluation of the TeamSCOPE system. International Journal of HumanComputer Studies, 56, 109–126 (2002) 3. Gutwin, C., Roseman, M., Greenberg, S. A usability study of awareness widgets in a shared workspace groupware system. In Proceedings of the ACM Conference on Computer Supported Cooperative Work, 258–267 Boston: ACM Press (1996). 4. Gutwin, C., Greenberg, S. Eﬀects of Awareness Support on Groupware Usability In Proceedings of the Conference oh Human Factors in Computing Systems (CHI 98), 511–518. Los Angeles: ACM Press (1998) 5. Espinosa, A., Cadiz, J., Rico-Guttierez, L., Kraut, R., Scherlis, W. Lautanbacher, G. Why Awareness Tools Must be Matched with Appropriate Tasks. In Proceedings of the Conference on Human Factors in COmputing Systems (CHI2000), 392–399. The Hague, Amsterdam ACM Press (2000) 6. Mastrogiacomo, S. Utilisation des zones de travail partag´ees asynchrones pour am´eliorer la compr´ehension mutuelle dans les groupes de projet distribu´es. Th`ese de doctorat en informatique de gestion non publi´ee, Ecole des Hautes Etudes Commerciales, Universit´e de Lausanne, Lausanne (2002).

Perceived Value: A Low-Cost Approach to Evaluate Meetingware 1

Pedro Antunes and Carlos J. Costa 1

2

Department of Informatics, Faculty of Sciences of the University of Lisboa, Bloco C5 Piso 1, Campo Grande, 1700 Lisboa, Portugal [email protected], www.di.fc.ul.pt/~paa 2 Departamento de Ciências e Tecnologias de Informação, ISCTE, Lisboa, Portugal [email protected]

Abstract. Meetingware supports, manages, guides and stimulates participation in meetings. The evaluation of meetingware has not yet produced concluding results due to many reasons, one of them concerning the high cost (in time, money and logistics) of the evaluation process. This paper proposes a low-cost approach to evaluate meetingware. The approach is centered on a variable – Perceived Value – measuring several external product attributes of meetingware that can be negotiated between developers and users. The proposed approach was used by an organization with the purpose of evaluating a meetingware prototype developed by the authors.

1 Introduction Meetings are essential to structure and coordinate work in organizations. Planning meetings, project meetings, briefings, brainstorms, welcome meetings, and workshops are just few examples of meeting genres common in organizations. Studies show that senior, middle and junior personnel spend a significant amount of their time in meetings (mean time per week is 8.4 hours [33]). Furthermore, the meeting frequency has grown in the past and is expected to grow in the future [33]. One possible explanation for this trend is that we are now moving towards a global knowledge-based economy demanding for worker adaptation and flexibility, continuous learning and innovation, and diversity in the selection of sources of information [37]. This means that the success of the organization will be strongly tied to the successful use of meetings. Unfortunately, meetings also have a negative impact on the organization. The cost of meetings, considering time, money and logistics, is very high and the satisfaction is very low [33]. There is a strong feeling, constructed from many personal experiences, that too many meetings fail or are simply a waste of time [35]. Technology has been viewed as the Holy Grail to improve the meeting process and outcomes [17]. This perspective has lead to the development of meetingware, defined as a combination of

J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 109–125, 2003. © Springer-Verlag Berlin Heidelberg 2003

110

P. Antunes and C.J. Costa

hardware, software and roomware with the purpose of supporting, managing, guiding and stimulating participation in meetings1. Meetingware brings many gains to meetings but some losses as well [33]. Overall, there is not a clear conclusion about the success or failure of meetingware [9; 23; 28]. We can ascribe this situation to three different orders of reasons: The problem that meetingware is trying to address is inherently complex. Because of the particular combination of people, organizations and technology, it falls in the “mess” category, defined by [29], where there is extreme ambiguity and disagreement about the problem. The technology and the way people use it are both complex [3; 18]: sometimes distributed (in time and space), supporting multiple roomware configurations, supporting many different tasks and functionality, linking many users with distinct roles, forcing people to plan in advance the system use, and sometimes requiring experts to manage the technology. The research setting is complex [2]. There are too many intervening and contextual factors in meetings that must be controlled, and there are too many variables that can be measured [17; 24; 31; 36]. Some of these variables can be controlled in the laboratory, such as the ones related to task and group performance, while others require working in the field, e.g. to measure technology transition [8]. Furthermore, extensive use of this kind of technology in organizations also highlights different results from lab and field experiments [7; 15; 17]. One challenging aspect of meetingware evaluation concerns measuring the Perceived Value (PV) attributed by the users to the technology. By PV we mean an assessment of the possible contributions of meetingware to the individual, group and organizational performance. Usually, this means that the functionality of meetingware has to be scrutinized and measured by the stakeholders, according to the organizational context and their expectations about the technology. In this paper we will propose an approach to measure PV and will describe the application of the approach in a real-world organization. The measurement of PV brings two contributions to the arena of meetingware evaluation. The first one is that it provides a low-cost indirect measure of the organizational impact of meetingware. The organizational impact is costly to measure directly, because it requires working in the field, committing many users to the process, and a long period of research (to allow the organization to assimilate the technology). An overview of the literature [28] corroborates this argument, showing that few experiments have evaluated the organizational impact of meetingware. The second contribution concerns the design and development of meetingware. It has been argued that developers and users sometimes take different frames of reference when analyzing meetingware [26]. For instance, developers may have great expectations and invest on a set of features that are perceived by users as not having the 1

Group Support Systems and Electronic Meeting Systems are designations applied by different communities to describe this technology. We prefer using the meetingware designation in order to situate the concept in the groupware field.

Perceived Value: A Low-Cost Approach to Evaluate Meetingware

111

same importance. As a consequence, many difficulties and conflicts arise in the implementation and use of meetingware, and the whole development may be compromised because of misaligned expectations [16; 26]. We believe that PV can provide a metric about the alignment of the developers’ and users’ expectations. This metric can then be used to make preliminary decisions about the feasibility of a meetingware project, as well as intermediate assessments of the development process. From now on, this paper is organized in the following sections. In section 2 we review the literature on different approaches to evaluate meetingware. In section 3 we define and propose a formula to measure PV. Finally, in section 4, we report a case study where PV was used to evaluate a meetingware prototype developed by the authors.

2 Literature Review Along with the maturing of the field, several researchers started to develop integrated frameworks for evaluating meetingware. [25] proposes one of the pioneering frameworks. It regards meetings as production systems, with inputs, processes and outcomes. Regarding evaluative data, the authors considered three key variables: effectiveness, efficiency and user satisfaction. Effectiveness comprises the effectiveness of the group process (obtained from post-session questionnaires and logs of the participants’ interventions) as well as effectiveness of the outcomes (obtained using interviews). Efficiency measures the relative expectations of the participants and experts against the baseline, i.e. no use of meetingware. User satisfaction is measured in different ways: measuring the system utilization rates, questioning users about their degree of satisfaction and discussing the issue in interviews. [31] proposes a similar framework, expanding the number of outcome variables and organizing them in a different way, defining two broad categories: task related and group related. The task related category comprises variables related to the characteristics of the outcomes, implementation of the outcomes and member attitudes towards the outcomes; while the group related variables address member attitudes toward the group. [19] has an integrated framework that is methodologically more complex from the previous ones. In this framework, meetings are regarded as production systems but with a sequence of four panels of variables instead of three: input, operating, process and outcome. In this framework, meetingware can be evaluated using not only the outcome variables but the process variables as well. While the outcome variables reflect the subsequent conditions to the meetingware use, the process variables afford evaluating ongoing group activities (e.g. learning; [11]). According to [39], the gains from analyzing process variables reside in the opportunity to open the black box of meetingware usage to find out detailed explanations. [17] has a very comprehensive meta-analysis of approximately 200 controlled experiments with meetingware and provides a long list of process and outcome variables tested by empirical research. Limiting our discussion to the outcome variables, [17] propose five categories: efficiency, effectiveness, satisfaction, consensus and usability.

112

P. Antunes and C.J. Costa

[28] has also an extensive overview of the published results from empirical research. The author proposes a new category for evaluating meetingware success, concerning the organizational impact of the technology, i.e. to what extent technology matches corporate strategies and organizational processes. Examples include cost reductions, revenue and productivity gains to the organization. [28] concludes that the proposed organizational impact variables are not used by empirical research, a situation that may be linked to the difficulties of performing longitudinal studies with meetingware. [30], which studies a significant number of empirical evaluations of groupware systems, also finds out that only 25% of them considered the organizational impact. The time spent by these evaluations ranged from 4.5 to 36 months, thus confirming that evaluating the organizational impact is very time consuming. The lack of importance given to the organizational impact variables has recently changed however. [7; 8] analyze the problem of organizational self-sustained use of meetingware and propose a theory (TTM, Technology Transition Model) to explain why meetingware may be successful or unsuccessful in organizations. The model contributes with two new variables for evaluating meetingware success (the discussion of TTM and its other contributions are out of our scope): the perceived magnitude of net value and the perceived frequency of net value. The first variable corresponds to a subjective assessment of the consequences resulting from using the technology and measures different attributes of organizational value, such as usefulness, cognitive load, economic impact or political value. The second variable considers how frequently users expect to obtain the benefit from the technology. Considering the project described by the authors, it took three years to evaluate the organizational success of meetingware [8]. Table 1. Variables for evaluating meetingware success Task

Group Organization Technology design

Process/Implementation Outcomes/Characteristics Attitudes toward the outcomes Attitudes toward the group Organizational impact

Interface Functionality Attributes

Efficiency, effectiveness, satisfaction Efficiency, effectiveness, satisfaction Satisfaction Satisfaction, consensus Perceived magnitude of net value, usefulness, economic impact, political value, productivity gains, cost reductions, revenue Usability, efficiency, effectiveness, satisfaction Present/absent features Positive/negative effects

[16] also addresses meetingware evaluation but from a very different perspective. The authors differentiate preliminary meetingware evaluation from the other forms of evaluation discussed above. Preliminary evaluation seeks to match the designers’ and users’ expectations over the technical features of meetingware, rather than explaining their impact on the user, group and organization. This matching is important for two reasons. One is that preliminary evaluation informs the development process about

Perceived Value: A Low-Cost Approach to Evaluate Meetingware

113

usability problems, perceived satisfaction with the technology and possible focal points for innovation. The other reason is that the obtained measurements are unequivocal, in the sense that both designers and users negotiate what is being measured. [16] proposes the evaluation of three collections of variables: interface, functionality and holistic attributes. The interface dimension addresses the user experience with the system, like usability, efficiency or ergonomics. The functionality dimension contrasts the different components and features proposed by designers with the users’ expectations about the task support offered by the system. Finally, the holistic attributes measure the potential positive/negative effects of the technology. In Table 1 we summarize and integrate the different perspectives over meetingware evaluation discussed above. Another important issue to ponder concerns the different approaches to the evaluation task. [30] identifies four different evaluation types: laboratory experiments, field experiments, field studies, and exploratory studies. According to [39], different evaluation types cannot be contrasted, since they produce conflicting results. For instance, field studies with meetingware have produced results different from laboratory experiments. Both quantitative and qualitative methods have been used to collect users’ experience with meetingware. However, the use of qualitative methods has been much advocated in this field, as necessary to increase the depth of explanation [39]. [30] presents a list of evaluation techniques that can be used to evaluate meetingware, including observation, interview, questionnaire, quantitative work measures, qualitative work measures, collecting archival materials and discussion. According to the authors, observation is the most frequently used technique. Combining our outlook of variables used to evaluate meetingware with so many evaluation types, methods and techniques clearly demonstrates the inherent difficulties of meetingware evaluation. It is therefore reasonable to discuss in more detail an important factor in meetingware evaluation: its cost, in terms of time, money and logistics. This factor must be pondered when selecting an evaluation type. For instance, going into the meeting place and watching real users is very time consuming or may be logistically impossible. The study of some variables is also more costly than others. In particular, evaluating variables related with the organization requires a long period or research, considering that work patterns evolve over time [30]. Several authors have proposed expedite techniques to reduce the evaluation cost. E.g. [20] uses “quick and dirty ethnography” and [5] uses contextual inquiries, combining observation with directed interviews; both are intended to make data acquisition less time consuming. Another approach to reduce the cost of meetingware evaluation consists in relaxing the purpose of evaluation. According to [21], the purpose of evaluation can be decomposed in three goals: generalizability, precision and realism. Of course, ideally we would like to maximize these three goals, thus creating high confidence in the results. But this approach is obviously very costly, since many variables, evaluation types, methods and techniques may have to be combined (triangulation). In some circumstances less costly trade-offs can be considered. One that has been frequently considered is to maximize precision, e.g. relying on laboratory experiments. At the limit, we can consider relaxing simultaneously the three goals. An example of this approach is given by the preliminary evaluation proposed by [16]. [16] is mostly interested in

114

P. Antunes and C.J. Costa

obtaining preliminary indications about design solutions. The approach had to be low cost because the developers knew that several iterations were needed to arrive to an acceptable design solution, and thus it would not make sense to maximize goals at the initial iterations. Table 2. Approaches to meetingware evaluation Purpose Cost

Goals Trade-offs Evaluation types Methods Techniques

Generalizability, precision, realism Relax all goals, maximize one goal, maximize all goals Laboratory experiments, field experiments, field studies, exploratory studies Quantitative, qualitative Observation, interview, questionnaire, quantitative work measures, qualitative work measures, collecting archival materials, discussion

In table 2 we summarize the different approaches to the evaluation task that were discussed above. Next we will define PV as a low-cost approach to measure the organizational impact of meetingware. The approach uses laboratory experiments, qualitative methods, discussion techniques, and relaxes all evaluation goals: generalizability, precision and realism.

3 Defining Perceived Value First we have to attribute a concrete meaning to perceived value. The word “perceived,” as found in several papers addressing meetingware evaluation, is mentioned in a context where users have the opportunity to form an opinion about the technology. For instance, [10] evaluates the perceived characteristics of innovation and [27] evaluates the perceived usefulness of the technology. According to [7], perception is more of an overall sense than a rational evaluation. “Value” corresponds to a measure of costs and benefits, which may consider different types of attributes. The following alternatives can be considered to further characterize these types of attributes:

Evaluate internal attributes related to quality. In this context, PV could be compared to Quality Function Deployment (QFD), where the system components are translated into several quality attributes defined by customers (ease of use, reliability, etc; e.g. [34]). Evaluate external product attributes. This approach is similar to QFD, but the system components are more generally defined and translated into product attributes (regarding the system from a business perspective), rather than quality attributes. [14] uses this approach. Measure generic influences like affective, economic, physical, political and social dimensions [7; 22].

Perceived Value: A Low-Cost Approach to Evaluate Meetingware

115

Inspect conformance with a list of heuristics specified according to some theoretical framework. This approach works if the inspectors have sufficient knowledge to judge conformance to the list of heuristics. For instance, [4] uses this approach to evaluate shared workspaces.

Note that the internal and theoretical alternatives require having either developers or expert evaluators. These alternatives are inadequate for end-user evaluation because they do not deal with objects meaningful to end-users. On the contrary, the generic approach places too much weight on end-users’ perceptions, neglecting the role of developers and making it difficult to inform the development process. Thus, considering that we are trying to align the developers’ and users’ expectations, we decided to measure PV using external attributes. In accordance with this decision, we now have to compile a list of relevant meetingware components and external product attributes necessary for measuring PV. This compilation takes the form of the evaluation map.

Individual

Group

Organization

Table 3. The attributes grid

3.1

Roles 1. Org. roles 1.1 accomplish roles 1.2 motivations/strategies 1.3 time management 1.4 learning 1.5 guiding 1.6 planning 2. Group roles 2.1 accomplish roles 2.2 motivations/strategies 2.3 time management 2.4 learning 2.5 guiding 2.6 planning 3. Individual roles 3.1 accomplish roles 3.2 motivations/strategies 3.3 time management 3.4 learning 3.5 guiding 3.6 planning

Processes 4. Org. processes 4.1 process structure 4.2 process support 4.3 process automation 4.4 task support 4.5 task automation

Resources 7. Org. memory 7.1 share data 7.2 save/retrieve data 7.3 structure/index data 7.4 user identification

5. Group processes 5.1 process structure 5.2 process support 5.3 process automation 5.4 task support 5.5 task automation

8. Group memory 8.1 share data 8.2 save/retrieve data 8.3 structure/index data 8.4 user identification

6. Individual processes 6.1 process structure 6.2 process support 6.3 process automation 6.4 task support 6.5 task automation

9. Individual memory 9.1 share data 9.2 save/retrieve data 9.3 structure/index data 9.4 user identification

The Evaluation Map

The construction of the evaluation map follows an approach similar to the one used for constructing a QFD map (e.g. [32]). First, we have to deploy a catalogue of external product attributes. Then, we have to deploy a catalogue of relevant meetingware com-

116

P. Antunes and C.J. Costa

ponents. Both catalogues are generically arranged in the attributes grid discussed below. Finally, the evaluators will have to examine the behavior of the meetingware system and determine the contributions of the referenced components to the product attributes. We organize the external meetingware attributes in two dimensions. In one dimension we classify attributes as roles, processes and resources, while in the other dimension we define three levels of detail: individual, group and organization. The first collection of attributes concerns roles. Roles correspond to categories of recognizable user behaviors, objectives and motivations linked to the execution of an organizational, group or individual function. The level of detail considered is the necessary one to clarify who interacts with the meetingware and what functionality the meetingware is expected to deliver to users. The meetingware components that are relevant in this context are: (1) mechanisms to support accomplishing goals; (2) mechanisms to support identifying motivations and defining strategies; (3) time management mechanisms; (4) mechanisms that support the learning process; (5) mechanisms that help or guide the user performing an assigned role, (e.g., expert systems; [6]); (6) mechanisms that help planning goals, identifying responsibilities and allocating resources. Table 4. The evaluation map Components .1 .2 .3 .4 .5 .6

Attributes 1. Organizational roles 2. Group Roles 3. Individual roles 4. Organizational processes 5. Group processes 6. Individual processes 7. Organizational memory 8. Group memory 9. Individual memory

The second collection of attributes addresses the meeting process. The meeting process organizes interrelated activities in a way that allows groups reaching complex goals. In the perspective of meetingware support, the following components will be appreciated [24]: (1) process structure; (2) process support; (3) process automation; (4) task support; and (5) task automation.

Perceived Value: A Low-Cost Approach to Evaluate Meetingware

117

Finally, the third collection of attributes is dedicated to characterize meeting resources. Resources are artifacts used, shared or produced by users while participating in meetings. From an information processing perspective, the following meetingware components have to be considered: (1) share data; (2) save/retrieve data; (3) structure/index data; and (4) associate data with user(s). Why do we need to further categorize these product attributes in the individual, group and organizational dimensions? Basically, because success or failure depends on the combined impact of these three factors. We give some concrete examples. (1) CSCW success depends on who benefits and who has to do additional work. The users that do not get benefits from the technology undermine its use to the point of failure [18]. (2) Meetingware requires good agendas, defined before meetings and, in fact, one of the most significant advantages of meetingware has been attributed to this strong requirement. However, 1/3 of traditional meetings do not have any kind of agenda [33] and, thus, meetingware may be perceived by teams as awkward. (3) Meetingware has proved to decrease significantly organizational costs but, nevertheless, failed because this technology needs champions and they are very scarce in organizations [7]. Examples 1, 2 and 3 highlight respectively the individual group and organizational impacts on meetingware technology. Our purpose, then, is to determine the contributions of meetingware components simultaneously at the individual, group and organizational levels. At the individual level, we propose to evaluate the technology support to individual users, executing individual tasks and managing individual resources while cooperating with other users in the scope of the meeting process. The other level is the group level. In fact, meetingware supports group roles, executing collaborative tasks, and producing and using shared information. Finally, at the organizational level, we evaluate the meetingware aptitude to support organizational roles, processes and resources. By crossing the role-process-resource dimension with the organization-groupindividual dimension, we finally define the attributes grid shown in Table 3. The grid consists of nine cells, each one representing a relevant category of meetingware attributes. Within each cell we show the meetingware components that should be translated into external product attributes. Of course, the attributes grid is instrumental but still not sufficient to evaluate PV. What is still necessary to accomplish that objective is to tailor the generic attributes grid to the situation at hand: the specific organizational context as well as the specific meetingware system under evaluation. This means that developers and evaluators must negotiate the list of concrete external product attributes, removing from the equation the attributes and components that are not considered relevant. Thus, for each cell of the grid, the following concrete attributes should be deployed: Organizational roles – Identify the organizational roles that users play when using meetingware (e.g. general manager, project leader). Group roles – Identify the roles that users play in meetings, e.g. facilitator, sponsor and secretary [1].

118

P. Antunes and C.J. Costa

Individual roles – Besides organizational and group roles, users also act upon individual aspirations. Organizational processes – At the organizational level, several processes may be identified, e.g. strategy formation, relationship development and conflict management. Group processes – Identify the group processes according to the issues that need to be dealt with, e.g. create an agenda or brainstorm. Individual processes – Identify processes that have meaning at the individual level, such as prioritizing data or voting. Organizational memory – Identify relevant organizational databases, considering the extent of the link with the meetingware being evaluated [12]. Group memory – Identify the information produced during meeting sessions or in previous meeting sessions and used in actual meetings [24]. Individual memory – The personal calendar is one example of individual memory supported by meetingware, but other forms of individual memory may be identified.

Table 4 presents the final evaluation map where the deployed concrete items are placed. Using this evaluation map the evaluators can rate the contributions of the referenced components to the selected external product attributes. Currently, the ratings are limited to 0 for “no support” and 1 for “support.” From this evaluation map, we can finally calculate PV using the following formula: 0 if (ci = 0 ∨ ai = 0 )   Vi =  ri   10 × otherwise  c × a   i   i 

9

PV = ∑ Vi i =1

ci is the number of components relevant to the specific meetingware being evaluated and considered in each cell of the attributes grid (see Table 3). ai is the number of concrete attributes that are selected to the evaluation process. These concrete attributes may be classified as roles, processes or resources and are selected after an analysis at the organizational, group and individual levels. ri corresponds to the sum of the rates given by the evaluators, considering the contribution of the components to the respective attributes. Currently, the ratings are 0 for “no support” and 1 for “support.” Vi is the partial score of a category of attributes in the evaluation map. PV is the total measure of Perceived Value. Since the maximum value that can be measured in each cell is 10, PV has a maximum of 90 and a minimum of 0.

3.2

The Evaluation Process

Now, we should briefly discuss how to use the evaluation map in order to measure PV. We propose an approach composed by the following steps:

Perceived Value: A Low-Cost Approach to Evaluate Meetingware

1.

2.

3.

4.

119

The first step consists in identifying the components that are relevant to evaluate the meetingware system. The developers execute this task before the first contact with the users, based on their appreciation of the deployed functionality. The second step consists in identifying the concrete external attributes that will be evaluated by users. The selected list of attributes should be negotiated between the developers and users. In our work we have accomplished this task with a pre-evaluation meeting. The third step consists in having users experimenting the system. This can be done in several ways. We have done it with “hands on” meetings. Sometimes a prototype is not yet available, e.g. during the feasibility study. In that case, the overall functionality of the meetingware system is presented by the developers, with the help of mock-ups, and discussed with the users in a “future system” workshop. In the fourth and final step we request users to analyze the contribution of the meetingware components to the selected list of attributes and fill out the evaluation map. This task may be accomplished either individually or as a group, in a meeting discussion.

The above process is set up to be low cost. In the simplest approach it can be accomplished with two meetings and a questionnaire filled out at the end of the second meeting.

4

Case Study

We will demonstrate the proposed approach using the case study method [38]. Study Questions. A real-world organization was interested in evaluating a meetingware prototype developed by the authors. The prototype can be briefly characterized as dedicated to create and manage meeting agendas and project activities, using Personal Computers and Personal Digital Assistants (PDA) in a meeting environment. More details can be found in [13]. We needed a low-cost approach to this evaluation, because the prototype was not yet completed and the organization was not committed to the project. The PV approach was developed with that purpose. The case study questions are “how to implement the evaluation process” and “what is the cost of the evaluation process.” Site Selection. The case regards a real-estate project launched by a Portuguese corporation operating in the real-estate market since 1979. The purpose of the project was to develop a condominium in Lisbon. The total amount of investment in the whole project was around 20 Million Euros. Unit of Analysis. In Figure 1 we show the major organizations involved in the project. These organizations structure their work according to several types of meetings: project inception meetings (A); construction and implementation meetings (B);

120

P. Antunes and C.J. Costa

marketing and selling meetings (C); and product development meetings (D). Note that the real estate investor is the project’s owner and coordinator. The product development meetings are restricted to members of the real-estate investor. Considering that it was not feasible to address all types of meetings, and that it would be difficult to commit several organizations to the study, we selected the product development meetings as the unit of analysis.

Real Estate Investor

A

B

Architects

General contractor

Engineers

Sub-contractors

D C Real Estate Agency

Fig. 1. Organizations involved in the project

The purpose of product development meetings is developing the overall concept and creating a generic marketing plan for the condominium. This is an initial but important step of the whole project, since it is necessary to guide the following architectural, engineering, construction and marketing projects. These meetings involved a designer, engineer, marketing specialist and financial executive. The team has to come up with a general strategy for the investment, identifying market needs, defining the apartments’ typologies and the quality of materials to be used. Data Collection. Our involvement with the team was strictly intended to evaluate the value of the meetingware prototype perceived by the team, according to their objectives, tasks and organizational context. After clarifying the situation with the team, we started collecting data about the roles, processes and resources. The data was collected in one week using document analysis, questionnaires and e-mail discussions. We could identify and validate with the team the following main organizational roles: designer, engineer, market specialist and financial executive. In what concerns group roles, we identified the participant, the sponsor and also the facilitator (imposed by the meetingware). No individual roles were discriminated. In what concerns organizational processes, the main processes identified were: (1) defining a general strategy for the investment; (2) identification of market needs; (3) identification of building typologies; and (4) definition of the quality of materials to be used in the construction. Among the group processes suggested by the authors, the team found that the production of meeting agendas, the support to meeting decisions and the production of meeting reports were the most important to their organizational context. Considering resources, at the organizational level, the most important ones concerned the project repository, allowing the creation of complex hypertext documents, including CAD files, which users called “general project specification;” as well as “memos” necessary to deal with architects, engineers and contractors.

Perceived Value: A Low-Cost Approach to Evaluate Meetingware

121

In what concerns group memory, the most significant resource is the actual meeting outcomes, as well as outcomes from previous meetings. Finally, in what concerns individual memory, the personal calendar is the most important resource used. After collecting the above information we started to tailor the meetingware prototype to the particular context and needs of the team. This step is necessary because the prototype supports generic meeting functionality – enact, distribute and display agendas and reports; relate these artifacts with documents referred or discussed during meetings; integrate contributions from several users; create a log of information managed across multiple meetings – but it does not support functionality that varies according to the context. In this case we had to develop digital templates reproducing the paper-based agendas and reports that the team was accustomed with. Then we set up two meetings with the team. During the first meeting we had the opportunity to describe the overall functionality of the prototype and show the specific agenda and report templates that were developed for them. The prototype was briefly demonstrated and discussed. The team members had the opportunity to create meeting agendas on their PDA, display them to the group and produce reports. In the second meeting we had a more detailed discussion about the characteristics of the system, analyzing in detail the support to roles, processes and resources. Basically, this meeting served to clarify how the team would fill out the evaluation map. The duration of the meetings was about one hour. There was a lag of 15 days between the two meetings. This lag was used to resolve several issues about the roles, processes and resources that were raised in the first meeting. Finally, we started to prepare the evaluation meeting. The evaluation map was arranged with the relevant meetingware components and attributes identified above. The prototype does not support learning at any level, neither the automation of organizational processes and tasks. Therefore, the respective components were removed from the evaluation map (1.4, 2.4, 3.4, 4.3, 4.5). One final meeting was set up to evaluate the prototype. After presenting the evaluation map, the team was requested to go through the list of attributes and give a consensual score. One of the authors participated actively in this meeting to facilitate the process. Whenever consensus could not be reached we requested individual votes and averaged the scores. The obtained results are presented in Table 5. After this evaluation, the organization decided to abandon the meetingware prototype and focus its interest in the project repository and integration of web services. Case Study Analysis. Table 5 identifies what attributes the prototype supplies perceived value (the partial Vi scores). The prototype does not supply value in three attributes: organizational and individual roles, and organizational processes. The prototype offers maximum value in two attributes: individual processes and individual memory. These results show that the perceived value of the prototype mostly resides in the integration of PDA and their ability to manage personal information. This information was mostly important to us developers, considering that the meetingware system was not completed and indications from users where necessary to focus the development effort and commit the target organization to the project.

122

P. Antunes and C.J. Costa Table 5. The evaluation map

Attributes 1. Organizational roles (a=4, c=5)

2. Group Roles (a=3, c=5)

3. Individual roles (a=0, c=5) 4. Organizational processes (a=4, c=3)

5. Group processes (a=3, c=5)

6. Individual processes (a=1, c=5) 7. Organizational memory (a=2, c=5) 8. Group memory (a=2, c=5) 9. Individual memory (a=1, c=5)

Designer Engineer Marketing specialist Financial executive Participant Sponsor Facilitator

.1 0 0 0 0 0 0 0

Components .2 .3 .4 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Define general strategy Identify market needs Identify typologies Define quality Meeting agenda Meeting decision Meeting reporting Schedule process

0 0 0 0 1 1 0 1

0 0 0 0 1 1 1 1

General proj. specification Memos Actual meeting outcomes Previous meeting outcomes Personal calendar

0 1 1 0 1

0 1 1 0 1

Vi .5 0 0 0 0 1 0 0

.6 0 0 0 0 0 0 0

0

1 0

0 1 1 1

0 0 0 0 1 1 1 1

0 0 1 1

0 1 1 0 1

0 0 1 1 1

0 1 1 0 1

0

7 10 4 6 10 PV

38

The obtained PV was 38. This overall value is meaningless if not compared to the PV obtained from other systems, other teams, or along time as the project evolves. We suggest that PV can be used to establish a baseline for quality assessment and monitoring of a complex endeavor such as developing meetingware. Nevertheless, PV was below average (PV = 45). Considering the later decision to abandon the project, we suggest that there may be a correlation between low PV and meetingware failure. Focusing only on meetings, since they are the most relevant cost components, the whole evaluation process required three meetings: (1) discuss overall functionality; (2) detailed discussion; and (3) evaluation. Extrapolating the lag time of 15 days between meetings, an evaluation can be obtained in 1 month. This is significantly less than the 4.5 to 36 months mentioned by [30]. Furthermore, the effort required by the evaluation corresponds to 3 working sessions with 5 people (including one of the authors), which is significantly less than, for instance, using observation or contextual inquiry techniques. This supports our claim about the low-cost approach.

Perceived Value: A Low-Cost Approach to Evaluate Meetingware

123

5 Conclusions Meetingware evaluation is a costly process. In this paper we address this issue and propose a low-cost approach based on a variable designated Perceived Value. PV measures the opinions of users about the organizational impact of meetingware technology. Measuring PV requires a negotiation step between developers and users, in order to identify the meetingware components and external product attributes that are relevant to the system under scrutiny and target organization. PV in then obtained by translating the meetingware components into external product attributes. As demonstrated by the case study, PV gives an indication of the attributes that are most relevant to users. This indication is important for the development project, focusing the developers on the most valued attributes and supplying a baseline for quality assessment and monitoring. PV also supplies an early indication of possible success or failure, which may instrumental in feasibility studies with meetingware technology.

References 1. Aiken M, Vanjani M (1998) An automated GDSS facilitator. 28th Annual Conference of the Southwest Decision Sciences Institute. Dallas, Texas. 2. Araujo R, Santoro F, Borges M (2002) The CSCW lab for groupware evaluation. In: Groupware: Design, Implementation and Use. 8th International Workshop on Groupware. LNCS, Springer-Verlag, La Serena, Chile. 3. Baeza-Yates R, Pino J (1997) A first step to formally evaluate collaborative work. In: Proceedings of the International ACM SIGGROUP Conference on Supporting Group Work. Phoenix, Arizona. 4. Baker K, Greenberg S, Gutwin C (2002) Empirical development of a heuristic evaluation methodology for shared workspace groupware. In: Proceedings of the 2002 ACM conference on Computer Supported Cooperative Work. New Orleans. 5. Beyer H, Holtzblatt K (1998) Contextual Design: Defining Customer-Centered Systems. Morgan Kaufmann. 6. Bostrom R, Aiken M, Motiwalla L, Sheng O, Nunamaker J (1990) ESP: An expert system for pre-session group decision support systems planning. In: Proceedings of the TwentyThird Hawaii International Conference on Systems Sciences. Kailua-Kona, Hawaii, pp 279–286. 7. Briggs B, Nunamaker J, Tobey D (2001) The technology transition model: A key to selfsustaining and growing communities of GSS users. In: Proceedings of the 34th Hawaii International Conference on System Sciences. Hawaii. 8. Briggs R, Adkins M, Mittleman D, Kruse J, Miller S, Nunamaker J (1999) A technology transition model derived from field investigation of GSS use aboard the USS Coronado. Journal of Management Information Systems 15 (3). 9. Briggs R, Vreede G (2001) ThinkLets: Achieving predictable, repeatable, patterns of group interaction with group support systems (GSS). Proceedings of the 34th Hawaii International Conference on System Sciences.

124

P. Antunes and C.J. Costa

10. Chiasson M, Lovato C (2001) Factors influencing the formation of a user’s perceptions and use of a DSS software innovation. The DATA BASE for Advances in Information Systems 32 (3), Summer: 16–35. 11. Collazos C, Guerrero L, Pino J, Ochoa S (2002) Evaluating collaborative learning processes. In: Groupware: Design, Implementation and Use. 8th International Workshop on Groupware. LNCS, Springer-Verlag, La Serena, Chile. 12. Conklin E (1992) Capturing organizational memory. In: Proceedings of GroupWare '92. California, pp 133–137. 13. Costa C, Antunes P (2002) Handheld CSCW in the Meeting Environment. In: J Haake, J Pino (eds.) Groupware: Design, Implementation, and Use. 8th International Workshop on Groupware, CRIWG 2002, vol. 2440. LNCS, Springer-Verlag, La Serena, Chile, pp 47–60. ISBN: 3-540-44112-3. 14. DeBaud J, Schmid K (1999) A systematic approach to derive the scope of software product lines. In: Proceedings of the 21st international conference on Software engineering. Los Angeles. 15. Dennis A, Nunamaker J, Vogel D (1991) A comparison of laboratory and field research in the study of electronic meeting systems. Journal of Management Information Systems 7 (3): 107–135. 16. DeSanctis G, Snyder J, Poole M (1994) The meaning of the interface: A functional and holistic evaluation of a meeting software system. Decision Support Systems 11: 319–335. 17. Fjermestad J, Hiltz S (1999) An assessment of group support systems experimental research: Methodology and results. Journal of Management Information Systems 15 (3): 7–149. 18. Grudin J (1994) Groupware and social dynamics: Eight challenges for developers. Communications of the ACM 37 (1), January: 92–105. 19. Hollingshead A, McGrath J (1995) Computer-assisted groups: A critical review of the empirical research. In: R Guzzo, E Salas (eds.) Team Effectiveness and Decision Making in Organizations. Jossey-Bass Publishers. 20. Hughes J, King V, Rodden T, Andersen H (1994) Moving out from the control room: ethnography in system design. In: Proceedings of CSCW '94, pp 429–439. 21. McGrath J (1984) Groups: Interaction and performance. Prentice-Hall. 22. Millen D, Fontaine M, Muller M (2002) Understanding the benefits and costs of communities of practice. Communications of the ACM 45 (4), April: 69–73. 23. Munkvold B, Anson R (2001) Organizational Adoption and Diffusion of Electronic Meeting Systems: A Case Study. Proceedings of the 2001 International ACM SIGGROUP Conference on Supporting Group Work. Boulder, Colorado, pp 279–287. 24. Nunamaker J, Dennis A, Valacich J, Vogel D, George J (1991) Electronic meeting systems to support group work: Theory and practice at Arizona. Communications of the ACM 34 (7): 40–61. 25. Nunamaker J, Vogel D, Heminger A, Martz B (1989) Experiences at IBM with group support systems: A field study. Decision Support Systems 5: 183–196. 26. Orlikowski W, Gash D (1994) Technological frames: making sense of information technology in organizations. ACM Transactions on Information Systems 12 (2): 174–207. 27. Ovaska S (1999) Lots of data, lots of evaluation – lots of findings? SIGGROUP Bulletin 20 (2), August: 33–35. 28. Pervan G (1994) The measurement of GSS effectiveness: A meta-analysis of the literature and recommendations for future GSS research. In: Proceedings of the Twenty-Seventh Hawaii International Conference on Systems Sciences. Hawaii. 29. Pidd M (1996) Tools for Thinking. Wiley.

Perceived Value: A Low-Cost Approach to Evaluate Meetingware

125

30. Pinelle D, Gutwin C (2000) A review of groupware evaluations. In: Proceedings of 9th IEEE WETICE Infrastructure for Collaborative Enterprises. 31. Pinsonneault A, Kraemer K (1989) The impact of technological support on groups: An assessment of the empirical research. Decision Support Systems 5 (3): 197–216. 32. Pressman R (2000) Software Engineering a Practitioner's Approach, 5th Edition. Trans. European Adaptation. McGraw-Hill, Inc. 33. Romano N, Nunamaker J (2001) Meeting analysis: Findings from research and practice. Proceeding of the 34th Hawaii International Conference on Systems Science. Hawaii. 34. Stylianou A, Kumar R, Khouja M (1997) A total quality management-based systems development process. The DATA BASE for Advances in Information Systems 28 (3), Summer: 59–71. 35. The 3M Meeting Management Team (1994) Mastering Meetings. McGraw-Hill, Inc., New York. 36. Tung L, Turban E (1998) A proposed framework for distributed group support systems. Decision Support Systems 23: 175–188. 37. Vicente K (2002) HCI in the global knowledge-based economy: Designing to support worker adaptation. In: J Carrol (ed.) Human Computer Interaction in the New Millennium. Addison-Wesley. 38. Yin R (1994) Case Study Research: Design and Methods. SAGE. 39. Zigurs I (1993) Methodological and measurement issues in group support systems research. In: L Jessup, J Valacich (eds.) Group Support Systems: New Perspectives. Macmillan, pp 112–122.

Exploring Interaction Behaviour and Performance of Online Collaborative Learning Teams Thanasis Daradoumis1 , Fatos Xhafa2 , and Joan Manel Marqu`es1 1

Open University of Catalonia, Department of Information Sciences Av. Tibidabo 39-43, 08035 Barcelona, Spain {adaradoumis,jmarquesp}@uoc.edu 2 Polytechnic University of Catalonia, Campus Nord C6 Jordi Girona 1-3, 08034 Barcelona, Spain [email protected]

Abstract. Studying and analysing the collaborative behaviour of online learning teams and how this behaviour is related and aﬀects task performance is a complex process. This paper presents an integrated approach that analyzes the participatory attitudes of group members in collaborative learning activities (group functioning) in relation to the individual and group learning outcomes (task performance). To that end, we ﬁrst provide principled criteria and methods for evaluating collaborative problem-solving situations and then we identify diﬀerent group types in terms of their degree of success at group functioning and task levels. Our objective is two-fold: assessing the eﬀectiveness and adequacy of the evaluation criteria and methods, and exploring the interaction behaviour of diﬀerent collaborative group types with respect to their performance.

1

Introduction

Research in Computer-Supported Collaborative Learning (CSCL) explored the types of problems that may result from insuﬃcient group interaction and support (see e.g. [1]). Several research approaches have been developed for observing, analysing and assessing collaborative learning interactions as well as for developing methods and tools that provide guidance and support to on-line learning teams (see [2,3,4]). Common to the most of these approaches is their development and testing on a rather small sample of on-line learning groups on an experimental basis, focusing on the analysis of the participatory and social aspects of collaborative learning processes. Our research proceeds one step further by explicitly distinguishing two evaluation levels: the group functioning and the task performance. The former examines the way a group of students functions as a cohesive collaborative learning team. The latter assesses students’ individual and group problem-solving capabilities and performance as concerns task accomplishment. Our work also relies on real, on-line collaborative problem-solving situations that form part of three distance learning undergraduate courses ([5]). J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 126–134, 2003. c Springer-Verlag Berlin Heidelberg 2003

Exploring Interaction Behaviour and Performance

127

The aim of this work is to study the relationship between the interaction behaviour (group functioning) and the learning outcomes (task performance) of a group and its individual members. The ﬁrst step toward the analysis of collaborative practices is the establishment of evaluation criteria to assess group functioning and task performance. This leads to the classiﬁcation of learning groups into speciﬁc categories. Finally, the results of the evaluation process are further analysed with the students’ learning contributing actions in order to determine the relation of the students’ collaborative behaviour to their learning success and, to assess the eﬀectiveness and accuracy of the evaluation approach itself.

2

Research Method

Over 300 students and 6 tutors participated in three collaborative learning experiences during four months in Winter 2002 semester. All practices were carried out mostly asynchronously; synchronous interaction occurred in few speciﬁc cases of decision-making. All asynchronous collaborative interactions took place on the Basic Support for Cooperative Work (BSCW), a groupware tool that enables asynchronous/synchronous collaboration over the web [6]. This research derives its theoretical basis from existing collaborative learning theories and models such as Distributed Problem-based Learning [7], Learning-by-Design and on fundamental aspects that have been identiﬁed in collaborative learning studies. One of these, the Time, Interaction and Performance theory (TIP) presents a useful theoretical framework [8]. Thus, the TIP theory states that successful groups always undertake three functions at the same time: (i) production function; (ii) group well-being; (iii) member support. Sfard [9] talks about the two main metaphors of learning: (i) the acquisition and (ii) the participation metaphor. The ﬁrst interprets learning in terms of the acquisition of something whereby the latter deals with learning as becoming a participant. Further, for eﬀective collaborative interaction, it is essential to ensure that each member receives the help he needs from his peers [10]. Finally, the Collaborative Learning Model of [3] classiﬁes eﬀective collaborative learning teams into ﬁve categories: (i) participation, (ii) social grounding, (iii) active learning conversation skills, (iv) performance analysis and group processing, and (v) promotive interaction. Our research takes all previous work a step further by: (a) integrating and exemplifying the above fundamental notions into principled evaluation criteria; (b) establishing speciﬁc evaluation methods for assessing individual and group performance at task and group functioning levels; (c) identifying categories of learning groups, based on group performance; and (d) setting the basis for the development of a framework for analysing and assessing group interaction.

3

The Evaluation Approach

The ﬁrst step of our approach is to deﬁne adequate evaluation criteria and show how they are related to the above collaborative learning theories and models.

128

T. Daradoumis, F. Xhafa, and J.M. Marqu`es

In this way, we obtain sound, eﬀective and principled criteria at two distinct evaluation levels. This is an important step to build a systematic and eﬃcient evaluation approach. 3.1

Deﬁning Principled Evaluation Criteria

The evaluation is performed at two levels: problem solving (PS) and group functioning (GF). As for the ﬁrst, we tracked groups and members’ problem-solving achievement by assessing the following aspects that constitute our evaluation criteria for this level. For each criterion we annotate the exact study that is derived from and is described above (for instance, - [9](i) refers to Sfard’s acquisition metaphor): PS1: The students’ individual and group learning outcomes (acquisition metaphor) - [9](i); PS2: The students’ contributing behaviour during task realisation (production function - [8](i), and use of active learning skills) - [3](iii); PS3: The students’ individual and group ongoing/ﬁnal performance in terms of self-evaluation - [3](iv). As for the latter, we evaluated the way group members functioned as a cohesive learning team, and whether they achieved to learn how to work together. Group functioning is measured through: interaction - [8](ii), which is also associated to the participation metaphor - [9](ii), and support - [8](iii). In order to deﬁne speciﬁc evaluation criteria related to the collaborative interaction we take into account the aspects identiﬁed in [3] and adapt them to our purposes. Speciﬁcally, interaction can be characterised and measured by the following parameters: GF1: Active participation behaviour - [3](i); GF2: Social grounding skills (well-balanced contributions and role playing) - [3](ii); GF3: Active learning interaction skills that facilitate the group’s well-being function - [3](iii); GF4: Group processing (groups perform a self-evaluation on their progress and performance as to whether each member learnt how to interact and collaborate more eﬀectively with his teammates) - [3](iv). Additionally, social support is determined by exploring Webb’s 5 criteria that ensure promotive interaction in a group ([10], [3](v)). Due to the courses goals and the complexity of the whole evaluation process, the assessment of the students’ problem-solving capabilities and learning outcomes represents the 80% of the ﬁnal grade, while group functioning gets the 20%. 3.2

Evaluation Methods for Individual and Group Performance

A collaborative problem-solving situation comprises of at least four sub-problems (phases), each of which has to be completed over a period of 3 or 4 weeks, and is completely evaluated. We present each evaluation method in turn and discuss the evaluation criteria it satisﬁes. First evaluation method: tracking new collaborative activities. The tutor uses a speciﬁc BSCW functionality (the awareness information) to perform a continuous tracking of the new collaborative activities in a group’s shared workspace (criteria PS2 and GF1). The BSCW distinguishes and generates four generic types of events (actions) related to an object: (a) Create events; (b) Change

Exploring Interaction Behaviour and Performance

129

events; (c) Read events; (d) Move events. The create and change events basically indicate active involvement to problem-solving and we call them active learning contributions. The read and move actions indicate a receptive and organisational behaviour, resp. We call the latter information processing contributions. Second evaluation method: tracking of individual (vs. collaborative) contributions. This method uses a speciﬁc software tool, called “BSCW Event Extractor” that extracts BSCW daily log ﬁles and ﬁlters this data according to desired parameters deﬁned by the tutor’s needs for tracking and assessment. The tutor is able to measure group functioning and problem-solving performance by determining the learning activities of group members, quantifying the amount of events per member, and examining whether a balanced contribution of action types exists (criteria PS2, GF1 and GF2). Moreover, a group coordinator supplies the tutor with important information about the members motivation and possible conﬂicts requiring the tutor’s support (criterion GF3). Third evaluation method: summative assessment of learning outcomes. The tutor assesses groups’ learning outcomes at the end of each phase (criterion PS1), when each group delivers the tutor the solution of the current sub-problem. Fourth evaluation method: group self-evaluation. At the end of each problemsolving phase, each group elaborates and delivers a self-evaluation report in which students assess their participation and performance (criterion PS3). This report also tells how well the group worked as a collaborative team, and whether they learnt how to collaborate eﬀectively (criterion GF4). Moreover, members have the chance to state whether they received the desired help and encouragement by their teammates when needed (group social support). Fifth evaluation method: ﬁnal individual self-evaluation. At the end of the whole process, each student elaborates a self-evaluation report (criterion PS3). 3.3

Categorisation of Collaborative Learning Groups

Our evaluation approach also makes a ﬁrst step towards identifying categories of learning groups according to their performance at problem solving and group functioning levels. The tutor assigns each group a mark on a 5-point scale at both levels: A (excellent), B (fairly good), C+ (good or passable), C- (not passable), and D (fail). The combination of the two marks determines the diﬀerent group types. Not all mark combinations were considered since they did not occur in our experiences. We propose the following initial categorisation (the marks in parenthesis correspond to problem-solving and group functioning resp.): Ineﬀective: The group fails at all levels of collaborative learning (C- or D/C- or D). Suﬃcient: The group’s overall performance is just admissible (C+/C+). Non-rewarded: Good performance at functioning level but it was not paid back with proportionally good learning outcomes (C+/B) or (B/A). Successful but imprecise: Fairly good learning outcomes but its interaction behaviour and support was rather weak and imprecise (B/C+). Well-considered: Fairly good task learning results by a group conforms to its good outcomes as regards collaboration skills and eﬀectiveness (B/B).

130

T. Daradoumis, F. Xhafa, and J.M. Marqu`es

Fairly successful but somewhat deﬁcient: Very good learning outcomes but it does not achieve an equally eﬀective collaborative interaction and support (A/B). Eﬀective: Very good performance at problem-solving and group functioning (A/A).

4

Data Analysis from a Collaborative Problem-Solving

In order to assess the eﬀectiveness and adequacy of the evaluation approach and to explore the groups’ interaction behaviour with respect to their performance, we carry out an empirical analysis of real interaction data from a collaborative problem-solving situation. Since the analysis concerns groups’ interaction behaviour, the results found are connected to evaluation criteria deﬁned at the group functioning level (GF) in the previous section and thus to the collaborative learning studies of Sect. 2. Data analysis comes from an undergraduate distance course that involved 186 students and 3 tutors, forming 31 groups of 6 members. Groups collaborated on-line to carry out a real case study. The results presented here describe trends in a small data sample, and do not imply statistical signiﬁcance. 4.1

Interaction Attitudes and Performance of Individual Members

Due to its particular interest, we chose a non-rewarded group type evaluated with a C+ and B marks at problem solving and group functioning, with the aim of examining whether the participation and contribution behaviour of its members is consistent with their learning outcomes. Based on the tutor’s assessment, apparently the group functioned fairly well as a collaborative team. However, the performance of its members at task level was not equally eﬀective, since they were not rewarded with equally good learning outcomes. As shown in Fig. 1, the learning achievement of some members (fca, rsa, mmo) was just suﬃcient (C+), where others achieved better outcomes (imo: A;

Fig. 1. Active participatory attitudes of group members vs. learning achievement.

Exploring Interaction Behaviour and Performance

131

pse, ebu: B). It is interesting to ﬁnd out reasons for this “contradiction”: quite eﬀective collaboration vs.heterogeneous learning. Fig. 1 shows the assessment mark obtained by each member with respect to their percentage of active learning contributions (create + change) - criterion GF1. It could be normal to expect that the more active a learner is the better learning outcomes achieves. However, as shown in Fig. 1, this is not the case for the members of this group. For instance, student “ebu” is attributed the highest percentage of active learning contributions (more than 30%); however, he obtained a ﬁnal B mark, the same as student “pse” who realised just the 14% of active learning contributions. In contrast, student “imo”, whose active contributions rose to 24,6%, achieved an A mark. The ﬁgure also shows that the active learning contributions of group members were not well balanced - criterion GF2. There are clearly two members, “ebu” and “imo” that stand out among the others. We provide a more detailed analysis of all action types performed by each member in Fig. 2 (in the table, the ﬁrst line and column represent the actions types and students resp. The entries (e.g., 9.52) indicate the percentage of an action type performed by a student).

fca rsa mmo pse ebu imo

Change 9.52 4.76 14.28 9.52 38.09 23.8

Create 7.64 14.65 10.19 18.47 23.57 25.48

Move 0 0 2.24 10.11 85.39 2.24

Read 19.78 15.11 9.51 13.25 24.81 17.54

Fig. 2. Percentage of action types performed by a student.

Fig. 2 clearly shows that group behaviour is not homogeneous - criterion GF2. Among all actions, only the read one seems to be well balanced for all members. In contrast, the members’ contributions regarding the rest of the actions are quite heterogeneous. We observe that student “ebu” stands out among all other members as concerns all actions except the create one. In fact, “imo” contributed the most (25,48%) of the create actions, though “ebu” is also quite close to this score. However, “ebu’s” very high score of move actions (85,4%) shows that he spent much of his time in duties related to management and maintenance, probably at the expense of quality contributions. Clearly, a group member (“ebu”) presents active interaction skills by dedicating a lot of eﬀort to the group’s well-

132

T. Daradoumis, F. Xhafa, and J.M. Marqu`es

being function in contrast to the other members who either contribute a little (“mmo” and “imo”) or nothing (“fca” and “rsa”) to this aspect (criterion GF3). In order to comprehend and decode the participation and contribution behaviour of each student better, we need a more reﬁned analysis, given in Table 1. Table 1. Percentage of objects created, modiﬁed or read by each student. obj. type document Create note/s folder others document Change note/s folder document Read note/s

fca 8.33 11.11 0 0 10.53 0 0 17.06 23.11

rsa 20.83 5.56 0 5.26 5.26 0 0 17.06 12.60

mmo 11.46 11.11 0 0 15.79 0 0 9.36 9.66

pse 13.54 27.78 0 31.58 10.53 0 0 15.05 10.92

ebu 18.75 22.22 80 36.84 31.58 0 100 22.07 28.57

imo 27.08 22.22 20 26.31 26.31 0 0 19.40 15.13

Interpretation of all the above data reveals that the distinguished performance of “ebu” regarding both active learning and information processing contributions begins to fade at a closer look of his real actions. In fact, much of his create and change contributions clearly focused on process management rather than on learning tasks. In this sense, “imo” (who got the best mark) seems to be more interested in his own learning mission and achievement, quite selective regarding reading, and rather indiﬀerent and unsupportive to procedural matters (he contributed only the 2% of the group’s move actions). The latter is also true for the rest of members, except “pse” who contributed to management tasks (10% of move actions; 31,6% of create “others” that include planning and preparation of virtual meetings, group agenda, etc.). This member was also quite active in creating though he focused more on message creation, while his reading others’ contributions was not very positive (13,2%). His good mark (B) was mostly due to his quality rather than quantity of task contributions. Yet, contrary to the fairly good percentage of create and read actions of “rsa” (around 15% each) and the creation of more than 20% of the group’s documents, “rsa” was not recompensed by good learning outcomes (got a C+). A qualitative analysis is clearly needed to examine the quality of “rsa” contributions. This is a typical case of an implicated personality, that is, a person who intervenes in group work but does not interact: his involvement in interacting with others was very low – around 5%. Finally, as regards the other two members with a C+ mark, we observe that “fca” was actually a passive reader, whereby “mmo” was more active in editing documents and not very interested in reading. Assessing the Evaluation Approach. This analysis shows that the real participation and contribution behaviour of the members of this group was quite irregular. On the one hand, this means that the tutor’s assessment of group functioning (B

Exploring Interaction Behaviour and Performance

133

mark) was not quite right; the group members were far from achieving a fairly eﬀective and supportive collaboration. That is, the group did not deserve a B mark at functioning level. We certainly need to develop better and more intuitive support means to help both the members to ﬁgure out their deﬁciencies and decide what behaviours to change (or maintain) and the tutor’s assessment. This is an eminent goal of our research. On the other hand, the evaluation approach proved to be fair regarding each member’s mark; our criteria and methods managed to take into account the diﬀerences/similarities detected in the contribution behaviour of each member regarding task realisation. Since problem-solving evaluation represented the 80% of the ﬁnal grade, the inconsistency detected at group functioning assessment did not aﬀect the individual ﬁnal mark. A detailed analysis will enable us to better predict the group behaviour and individual attitudes of its members as far as task achievement and good functioning concerns.

5

Conclusions and Ongoing Work

The evaluation of a learning group and its members who participate in longterm collaborative problem-solving activities at a distance is a complex process. In order to assure the success of the learning process, it is crucial to determine evaluation criteria and methods that allow to correctly assess the individual and group performance. In this work we provided several evaluation methods associated to principled evaluation criteria and contrasted with real analysis data gathered from diﬀerent groups’ workspaces so that to assess their eﬀectiveness. Our analysis can serve as a starting point to identify the weaknesses (types of problems and needs that may arise in a collaborative learning situation), and the strengths (the speciﬁc characteristics or patterns of eﬀective collaboration) shown in each group type. The next steps involve gathering and analysing more data to strengthen the claims made and probably generalising these claims to a methodological framework for eﬀective collaborative learning. Acknowledgments. This work has been partially supported by the UOC-IN3 grant TACEV2, and the Spanish MCYT project TIC2002-04258-C03-03.

References 1. Dobson, M., and McCracken, J.: Problem based learning: A means to evaluate multimedia courseware in science and technology in society. In T. Muldner and T. C. Reeves (Eds.), Educational Multimedia and Hypermedia (1997). Calgary: AACE. 2. Barros, M. and Verdejo, M.: Analysing student interaction processes in order to improve collaboration. Int. J. of AI in Education, (2000) 11, 221–241. 3. Soller, A.: Supporting Social Interaction in an Intelligent Collaborative Learning System. Int. J. of AI in Education. 12 (2001) 40–62

134

T. Daradoumis, F. Xhafa, and J.M. Marqu`es

4. Mart´ınez, A., Dimitriadis, Y., Rubia, B., G´ omez, E., Garach´ on, I., and Marcos, J.A.: Studying social aspects of computer-supported collaboration with a mixed evaluation approach. Proc. of the Int. Conf. on CSCL, (2002) 631–632. 5. Daradoumis T., Marqu`es J.M., Guitert M., Gim´enez F. and Segret, R.: Enabling Novel Methodologies to Promote Virtual Collaborative Study and Learning in Distance Education. Proc. 20th Conf. on Open Learning and Dist. Ed. (2001) 6. Bentley R., Horstmann T. and Trevor J.: The World Wide Web as enabling technology for CSCW: The case of BSCW. Computer-Supported Cooperative Work: Special issue on CSCW and the Web, Vol. 6. Kluwer Academic Press. 7. Koschmann, T., Kelson, A., Feltovich, P., and Barrows, H.: Computer-supported problem-based learning. In T. Koschmann (Ed.), CSCL: Theory and Practice of an Emerging Paradigm. Mahwah, NJ: Lawrence Erlbaum, (1996) 83–124. 8. McGrath, J.E.: Time, Interaction and Performance (TIP). A Theory of Groups. Small Group Research, 22 (1991) 147–174. 9. Sfard, A.: On two metaphors for learning and the dangers of choosing just one. Educational Researcher 27(2) (1998) 4–13. 10. Webb, N.: Testing a theoretical model of student interaction and learning in small groups. In R. Hertz-Lazarowitz and N. Miller (Eds.), Interaction in Cooperative Groups: The Theoretical Anatomy of Group Learning. (1992) 102–119.

A New Language to Support Flexible Failure Recovery for Workflow Management Systems 1

1

2

Gwan-Hwan Hwang , Yung-Chuan Lee , and Bor-Yih Wu 1

Dept. of Information and Computer Education, National Taiwan Normal University, Taiwan {ghhwang,u86278}@ice.ntnu.edu.tw 2 Software Project Development Division, Stark Technology Inc., Taiwan

Abstract. In this paper, we propose a new failure-recovery model for workflow management systems (WfMSs). This model is supported with a new language, called the workflow failure-handling (WfFH) language, which allows the workflow designer to write programs so that s/he can use data-flow analysis technology to guide the failure recovery in workflow execution. With the WfFH language, the computation of the end compensation point and the compensation set for failure recovery can proceed during the workflow process run-time according to the execution results and status of workflow activities. Also, the failure-recovery definitions programmed with the WfFH language can be independent, thereby dramatically reducing the maintenance overhead of workflow processes. A prototype is built in a Java-based object-oriented workflow management system, called JOO-WfMS. We also report our experiences in constructing this prototype.

1 Introduction Workflow management systems (WfMSs) are software systems for supporting coordination and cooperation among members of an organization whilst they perform complex business tasks [1–5]. Business tasks are modeled as workflow processes, which are then automated by the WfMS. The workflow model (also referred to as workflow process definition) is the computerized representation of the business process. It defines the starting and stopping conditions of the process, the activities in the process, and control and data flows among these activities. An activity is a logic step within a workflow, which includes the information about the starting and stopping conditions, the users who can participate, the tools and/or data needed to complete this activity, and the constraints on how the activity should be completed. Activities are usually organized into a directed graph that defines the order of execution among the activities in the process. Nodes and edges in the graph represent activities and control flow, respectively. A workflow process instance is the execution of a workflow process definition by the WfMS. The execution of a workflow process instance is controlled by the workflow engine. Two different types of problems or anomalous situations can occur during workflow execution: exceptions and failures [6]. Exceptions are semantic failures that can be caused by a system failure or by a new situation introduced by the external J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 135–150, 2003. © Springer-Verlag Berlin Heidelberg 2003

136

G.-H. Hwang, Y.-C. Lee, and B.-Y. Wu

environment. A comprehensive approach to the management of exceptions is to integrate the exception handler with the WfMS. The exception-handling mechanism must be able to capture exceptional events and react to them. The WfMS may terminate the workflow process or return to the execution of the workflow process after the exception has been handled [7,8]. The other problem in managing workflow processes is that of failure recovery [9– 11]. The goal of failure recovery is to bring the failed workflow process back to some semantically acceptable state so that the cause of the failure can be identified. The problem can then be fixed and the execution resumed with the hope that the workflow process will be completed successfully. The basic failure-recovery process includes the following three steps: 1. The execution of the workflow process is terminated and the workflow engine then decides the end compensation point (ECP) and the compensation set of the occurred failure. 2. Activities in the compensation set are compensated. 3. The workflow process is restarted from the ECP. An ECP is a previously executed activity of the workflow process which represents an acceptable intermediate execution state where certain actions can be taken so that either the problems which caused the failure can be fixed or the execution path of the workflow can be altered to avoid the problem. Compensating an activity A involves executing a compensation subroutine that attempts to undo the effects of the previous execution of A. This compensation can be very expensive, so it is important to minimize compensation scope to avoid unnecessary compensation effort. In this paper, those activities that require compensation are called the compensation set [9] of a failure. End compensation point

...

B1

Activity fails A1

A2

A3

or

A4

...

Ai

Ai+1

...

Rollback

Fig. 1. The basic failure-recovery model

The complex failure-recovery process is illustrated in Fig. 1. We assume that the execution sequence of the activities is A1, A2, A3, …, and Ai in that order; and that a failure occurred in activity Ai. The rollback of workflow process returns the execution to A2, i.e., A2 is the ECP of this failure. The workflow engine then compensates those activities in A3–Ai that are in the compensation set. If an activity needs to be compensated, then the corresponding compensation subroutine of the occurred failure is executed. After all the compensations are finished, i.e., all the activities in the compensation set are compensated, the workflow process restarts from A2. In the re-execution, the workflow process may proceed either from B1 or A4 after the end of A3. The failure-recovery models proposed in [9-11] have some drawbacks. First, they only allow specification of the ECP and compensation set of a failure in an activity in a static way before the workflow process is compiled. This limits the flexibility of failure recovery. A more flexible way is to compute the ECP and compensation dur-

A New Language to Support Flexible Failure Recovery

137

ing the process run-time according to the execution results of activities. Second, the ECP and compensation set are specified by explicitly using the names (or some kind of identities) of activities. Therefore, inserting or deleting activities to or from a workflow process may require modification of the failure-recovery specification in another activity. Although Du et al. [9] proposed a compensation scoping strategy that allows the workflow designer to specify some designated compensation scopes based on data dependencies between workflow activities, their model does not allow the workflow designer to specify the ECP and compensation set in a flexible way, such as by using a programming language. In this paper, we propose a new language, called the workflow failure-handling (WfFH) language, which supports a workflow failurerecovery model with the following features: 1. The ECP and compensation set can be computed or derived during the workflow process run-time according to the execution results and status of workflow activities, as well as the type of failures. 2. The workflow designer can use the WfFH language to program the computation of the ECP and compensation. With the WfFM codes written by the workflow designer, the WfMS employs data-flow analysis technology to compute the ECP and compensation when the failure occurs. 3. The definition of failure recovery and compensation scope between activities can be absolutely independent. With this, inserting or deleting activities to or from a workflow process may not require modification of the failure-recovery specification in other activities. This reduces the maintenance overhead of workflow process dramatically and increases the reusability of workflow activities. 4. The details of information related to the failure can be sent to the ECP and activities in the compensation set to activate the most appropriate compensation for the failure situation that has occurred. 5. There can be multiple failures in a single activity, and each such failure can activate different failure-recovery processes. The remainder of the paper is organized as follows. Section 2 explains, with the aid of some examples, why a language like the WfFH language is needed in WfMSs. Section 3 presents the WfFH language we propose. In Section 4, we detail the system architecture and implementation for a WfMS to support the WfFH language. Section 5 presents the experimental result. Section 6 concludes the paper.

2 Motivation Examples In this section, we will begin with a simplified example of a workflow process to explain why the WfFH language is needed in the failure recovery of the WfMS (see Fig. 2). Assume that the workflow process is a selling process of a wholesale merchant. It consists of nine activities, A1, A2, …, and A9 as well as five failures F1, F2, …, and F5:

Activity A1. Receive order. Activity A2. Build up or update customer information.

138

G.-H. Hwang, Y.-C. Lee, and B.-Y. Wu

Activity A3 (named input_order). Input the order details. Activity A4. Check the customer transaction and credit records. Activity A5. Check the inventory records. Activity A6. (named evaluate_order) Evaluate if the order should be accepted. Activity A7. Pick up goods from the warehouse according to the order specified, and then deliver the goods to the customer. Activity A8. Send the rejection letter to customer. Activity A9. Bill customer. Failure F1. Inventory-insufficient. Failure F2. Over-quantity. Failure F3. Goods were not successfully delivered. Failure F4. Goods were rejected by customer because they did not conform to the order. Failure F5. Unable to get the payment for goods. F1 F2

Start

End 1

A4 A1

A2

A3

A6

A7

A9

A5 F3

F5 F4

End 2

A8

Start of workflow

End of workflow

Work activity

Connection edge

(Failure) Roll back to ECP

Fig. 2. An example of a workflow process

Below we describe some cases where the static method of specifying the ECP and compensation set could cause some problems in the design and maintenance of the workflow process. The first problem is that inserting or deleting an activity may result in a change being required to the specification of the ECP and the compensation set in other activities of the workflow process. For example, assume that A6 should rollback to the earliest activity that relates to the ordered goods when activity A6 causes an inventoryinsufficient failure. In this case the workflow designer specifies the ECP and compensation set to be A3 and {A3, A6}, respectively. However, after that, if the workflow designer has to change the workflow process by adding an activity A10 named confirm_order, which is phone confirmation of the order after A2 (see Fig. 3), the workflow designer has to change the ECP and compensation set of all the five failures F1, F2, …, and F5. For the setting of each failure, its ECP and compensation set may have to be modified, e.g., the ECP and compensation set of inventory-insufficient failure of A6 should be changed to A10 and {A10, A3, A6}, respectively. This kind of maintenance overhead for failure-recovery specification can be even more serious if a subflow is added to an existing workflow process. This is called composite workflow (or nested workflow) [16]; see Fig. 4A. In this case, specification of the ECP and compensation set for the inventory-insufficient failure of A6 should consider all the activities in the added subflow – this can be very tedious and error-prone. We con-

A New Language to Support Flexible Failure Recovery

139

sider that a good way to reduce the maintenance overhead is to provide a mechanism to let the workflow designer change the flow of the workflow process without having to change the failure-recovery definitions of other activities. The failure-recovery mechanism in [9–11] cannot solve this problem. F2

F1

Start

End 1

A4 A1

A2

A10

A3

A6

A7

A9

A5 F3

F5

End 2

F4 A8

Start of workflow

End of workflow

Work activity

Connection edge

Modified failure Original failure

Fig. 3. Change of failure settings after inserting a new activity

A2

A3

(A) Insert a subflow A10: write(quantity=210) A3: write(quantity=210)

(B)

A10

A4

A3

A6 A5

Fig. 4. Problems in changing the workflow process

The second problem is that it may not be possible to determine the ECP or compensation set of a failure until the run-time of the workflow process. This situation is illustrated in Fig. 4B. Assume that the wholesale merchant sets the quantity limitation for some goods during a peak period to, say, 100. Thus, A6 may cause another failure called over-quantity for some specific goods. However, the quantity of the ordered good may be set either by activity A10 or by activity A3, depending on the execution of A10 and A3: if A10 does not set it, then A3 must do so. Thus, the activity that sets the quantity can only be obtained according to the execution results of activities A10 and A3. That is, the ECP or the compensation for over-quantity failure of A6 depends on the execution results of previously executed activities. The WfMS should therefore compute or derive the ECP and compensation set according to the execution results of activities after the occurrence of the failure. The failure-recovery mechanism in [9– 11] again cannot solve this problem. The third case is that a single activity may cause multiple different failures. For example, activity A6 may cause inventory-insufficient and over-quantity failure. The ECPs and compensation sets of these failures are all different. The failure-recovery

140

G.-H. Hwang, Y.-C. Lee, and B.-Y. Wu

models proposed in [9–11] do not mention how to implement a WfMS which allows multiple failures to occur in a single activity: here we propose an architecture of the WfMS to support multiple failures in a single activity. The activities of a workflow process usually involve arbitrarily complex functions. Thus, the activities can be very expensive to compensate and re-execute. It is therefore very important to decide the most-recent ECP and the minimal compensation set during the failure-recovery process. As we have discussed with the example shown in Fig. 2, the static way of specifying the ECP and compensation set causes difficulties in maintaining the failure-recovery definition when the workflow process is changed. Also, it cannot use run-time results of activities to compute the ECP and compensation set. Thus, we have designed the WfFH language to solve these problems.

3 The WfFH Language Before we introduce the WfFH language, we first present the architecture of the workflow process definition which embeds the WfFH programs to support flexible and data-flow-analysis-based failure recovery. The WfFH program is embedded in the definition of the activity. The workflow process definition consists of at least the definitions of all of its activities as well as the specification of the control and data flows, including conditional branching, concurrent execution of activities, looping, and other complex control structures. Fig. 5 illustrates the basic architecture of the definition of workflow process and activity. The flow of activities is presented as a directed graph that defines the execution order of the activities in the process. Nodes and lines in the graph represent activities and control flow, respectively. Note that the directed graph is not the unique way of representing the flow of the activities; existing methods of specifying the flow of activities include the Petri Net [12,13] and generalized process-structure grammar [14]. 3.1

The Structure of Activities to Support WfFH

An activity is a logic step within a workflow. The activity definition is also shown in Fig. 5, which contains basic information for activity execution and additional failurerecovery definitions. The basic information for activity execution includes at least the starting and stopping conditions, the users who can participate, the tools and/or data needed to complete this activity, the constraints on how the activity should be completed (such as the time limits), and the execution codes of the activity. The additional failure-recovery definition in the activity for data-flow-analysis-based failure recovery comprises recovery definitions and definitions of the compensation subroutines. The execution code is the program that executes the activity and which may trigger the failure-recovery process when the execution causes a failure.

A New Language to Support Flexible Failure Recovery

D efinition of activities Definition of activity A 1 Definition of activity A 4 Definition of activity B 1

D efinition of activity A 2

...

Definition of activity A 3

Definition of activity A i

Definition of activity B 1

...

...

Flow of activities

•Start and stoppin g condition •Users w ho can participate •Tools and/or data n eeded •Som e constraints

Basic information for activity execution

Execution codes Begin activity ………. if ((quantity> order_ lim it) & & (period==H O T)) RA IS E_FA ILU RE ov er-quantity(order_N O ,100);

O ccurrence of a failure called RYHUTXDQWLW\

………. End activity

Recovery definitions Recovery definition of failure F1

Recov ery definition o f failure F2

R ecovery definition of failure F3

…

C om pensation subroutine definitions D efinition of a w orkflow process

141

D efault comp ensatio n sub routine

Comp ensation su boutin e for failu re F 1

Co mpensatio n suboutine for failure F2

Failure recovery definition

…

Definition of an activity

Fig. 5. The definition of the workflow process and activities

3.2

The Skeleton of the Recovery Definition

In this paper, we propose using the WfFH language to specify the recovery definition. When a failure occurs, the workflow engine executes the WfFH codes of the corresponding recovery definition of the failure to compute the ECP and compensation set. All the activities in the compensation set should be compensated. In the compensation of an activity, the workflow engine first checks if there is a corresponding compensation subroutine of the occurred failure in the activity – this compensation subroutine will be executed if it exists; otherwise the default compensation subroutine will be executed. Since an activity may cause different failures, the activity definition may contain multiple recovery definitions and compensation subroutines. According to the syntax of WfFH language, each recovery definition has the form shown in Fig. 6. )$,/85(1DPHW\SHDUJW\SHDUJ« %(*,1'HFODUDWLRQ PDNHGHFODUDWLRQRIYDULDEOHV $FWLYLW\BVHWDBVHWDBVHW 5HVRXUFH55 « (1''HFODUDWLRQ %(*,1&RPSHQVDWLRQ6HW&RPSXWDWLRQ FRGHWRGHULYHFRPSHQVDWLRQVHWKHUH « '2B&RPSHQVDWLRQDBVHW (1'&RPSHQVDWLRQ6HW&RPSXWDWLRQ %(*,1(&3&RPSXWDWLRQ FRGHWRPDNH(&3FRPSXWDWLRQVHWKHUH « 5ROOEDFNB7RDBVHW (1'(&3&RPSXWDWLRQ (1')DLOXUH

Fig. 6. The skeleton of a recovery definition written in the WfFH language

A recovery definition programmed with the WfFH language consists of a header and a body. The header begins with a keyword “FAILURE,” which is followed by the name of the failure and a sequence of arguments. The syntax of the argument list of the WfFH language is the same as that for Java [15]. These arguments have two uses:

142

G.-H. Hwang, Y.-C. Lee, and B.-Y. Wu

(1) to provide information for the computation of the ECP and compensation set, and (2) they will be passed to the compensation subroutines of the compensated activities. The compensation subroutines could use the received arguments to perform the most appropriate compensation. The body comes after the header, and comprises three sections. The first section in the body, the declaration section, includes declarations of variables used in the next two sections. Variables declared in the declaration section include:

Variables used to store set of activities. The compensation set and ECP of a failure consist of set of activities. We can use the keyword “Activity_set” to make the declaration (see line 1.3 of Fig. 6). Variables used to store resources. For data-flow-analysis-based specification and computation of the compensation set and ECP, we have to declare some variables which store shared resources accessed by different activities (see line 1.4 of Fig. 6). Others. The WfFH language allows the use of all the data types defined in Java [15], including types defined by the user. 3.3

Methods in WfFH

The data-flow analysis technology (or global data-flow analysis technology) for compiler optimization analyzes how data values are modified across basic blocks of program statements [17]. The data-flow analysis technology used in our failure-recovery model is derived from the data-flow analysis technology used in compiler optimization. However, instead of analyzing the data values modified in program statements, our model analyzes the resource accesses of activities in workflow processes. To build up a data-flow-analysis-based failure-recovery mechanism, i.e., to compute the ECP and compensation set using data-flow analysis technology, the workflow engine which controls the execution of the activities has to monitor and record all the accesses to the shared resources of each activity. During the execution of a workflow activity, it may access private and/or shared resources. Private resources are defined as data used only within the execution of a single activity, whereas shared resources are data that are created, read, written, or modified by multiple activities, or data which are considered as the output results of the workflow process. In the current definition and implementation of the WfFH language, they are two kinds of resources that the activity can access: files and database records. The accesses to shared resources issued by activities are stored in an execution-log database. Each access record stored in the execution-log database contains at least the activity which performs the access, the time and type of the access (i.e., insert, delete, update, or create), and the file name or the primary keys (or table name) of the access database records. File accesses are easy to monitor, but monitoring accesses to database records is much more difficult. We do this using execution-monitoring technology which is proposed and developed for reachability testing of client–server database applications [18,19]. The next section in the definition is the compensation-set computation section, which the WfMS executes to derive the compensation set of this failure. Its syntax is similar to Java, with some extension of functions to support the computation of compensation sets. They can be classified into three main groups as described below.

A New Language to Support Flexible Failure Recovery

143

The first group comprised functions which return the set of activities. We call them activity-manipulation functions:

$&7,9,7<´QDPHBRIBDFWLYLW\µ Given the name of an activity in the workflow process as the argument of this function (possibly containing the wildcard operator * or ?), this function returns the specified activities. For example, DBVHW $&7,9,7<´FKHFN µ will return the set of activities whose names are prefixed with “check.” $&7,9,7<$// This function returns the set of all the activities in the workflow process. $&7,9,7<(;(&87(' This function returns the set of all the activities which have been executed. $&7,9,7<7+,6 This function returns the set of the activity which causes the failure (the current activity). $&7,9,7
6(/(&7B'%B5(&25'6´'%B1DPHµ ´VHOHFWBVTOBWUDQVDFWLRQµ This returns the database records which are queries with the transaction VHOHFWBVTOBWUDQVDFWLRQ from the database '%B1DPH. ),/(6II«IQ This returns the files II«IQ as a resource type. 5(6285&(B5($'B%<DFWLYLW\BVHW This returns all the resources read by DFWLY LW\BVHW. 5(6285&(B:527(B%<DFWLYLW\BVHW This returns all the resources written by DFWLYLW\BVHW. 5(6285&(B'(/(7('B%<DFWLYLW\BVHW This returns all the resources deleted by DFWLYLW\BVHW. 5(6285&(B&5($7('B%<DFWLYLW\BVHW This returns all the resources created by DFWLYLW\BVHW. The functions SELECT_DB_RECORDS and FILES return the specified resources from the shared resources of the workflow process. RESOURCE_READ_BY,

144

G.-H. Hwang, Y.-C. Lee, and B.-Y. Wu

5(6285&(B:527(B%<, 5(6285&(B'(/(7('B%<, and 5(6285&(B&5($7('B%< allow the user to determine what resources are accessed by activities.

The third group comprises the set of operations which support the activity- and resource-manipulation functions:

,17(56(&76 6 . This returns the intersection of activity sets or resource sets (i.e., ^[_[³6DQG[³6`). 81,2166 . This returns the union of activity sets or resource sets (i.e., ^[_[ ³6RU[³6`). 6,=(B2)6 . This returns the number of elements in set S corresponding either to the set of activities or resources. ',))(5(1&(66 . This returns the set which deletes element of S2 from S1 (i.e., ^[_[³6DQG[´6`). 6L . This returns the i-th element in set 6. The codes in this section also conform with the statement and loop structures of Java, which allows the recovery definitions programmed with the WfFH language to be easily translated into Java objects. A statement specifying the resulting compensation set should appear at the end of this section, consisting of a keyword “'2B&RPSHQVDWLRQ” and an activity set variable which stores the resulting compensation set (see line 2.3 of Fig. 6). The final section in the recovery definition for the WfFH language is the ECP computation section. The programmer uses this to specify how to compute the ECP. The syntax and available functions of this section are identical to those for the compensation-set computation section described above. Furthermore, it inherits the computation results of all the variables used in the section in which the compensation set is computed. The ECP computation section also ends with a statement to specify the resulting ECP. It begins with a keyword “Rollback_To” which follows an activity-set variable which stores the resulting ECP. We now provide several examples to illustrate the WfFH language. The WfFH Code in Fig. 7A demonstrates how to use the WfFH language to specify the inventory-insufficient failure of the motivating example we presented in Section 2. We set the compensation set to be activities whose names are postfixed with _order, because the names of A3, A6, and A10 are input_order, evaluate_order and confirm_order, respectively. It is obvious that there is no need to change the recovery definition of inventory-insufficient failure of A6 when A10 is added to the workflow process, and so we did not employ the data-flow analysis technology of the WfFH language in it. However, in the definition of the over-quantity failure (see WfFH Code Example in Fig. 7B), we have to use data-flow analysis technology in the computation of ECP and compensation set. There are two arguments: order_No and order_Limit. The order_No argument is used in the computation of ECP and compensation set, and both of them will be sent to the compensation subroutines. The database record of “quantity” is first retrieved and stored in “OQuantity.” This database record refers to the quantity of the order stored by either A10or A6. Then, each executed activity is checked to see if it wrote to “OQuantity,” and all those that did are added to the compensation set. The ECP is the earliest activity in the compensation set.

A New Language to Support Flexible Failure Recovery

(A)

145

(B)

)$,/85(LQYHQWRU\LQVXIILFLHQW )$,/85(RYHUTXDQWLW\LQWRUGHUB1RLQWRUGHUB/LPLW %(*,1'HFODUDWLRQ %(*,1'HFODUDWLRQ $FWLYLW\B6HWDBVHWDBVHWDBVHW $FWLYLW\B6HWDBVHW $FWLYLW\B6HWFRPSBVHWHFS $FWLYLW\B6HWFRPSBVHWHFS (1''HFODUDWLRQ 5HVRXUFH2,QYHQWRU\ LQWLVL]H %(*,1&RPSHQVDWLRQ6HW&RPSXWDWLRQ DBVHW $&7,9,7<(;(&87(' (1''(&/$5$7,21 DBVHW $&7,9,7<´ BRUGHUµ %(*,1&RPSHQVDWLRQ6HW&RPSXWDWLRQ FRPSBVHW ,17(56(&7DBVHWDBVHW 24XDQWLW\ 6(/(&7B'%5(&25'6 ´:)B'%µ ´6(/(&7 TXDQWLW\ '2B&RPSHQVDWLRQFRPSBVHW )5202UGHU)RUP:+(5(2UGHU)RUP2UGHU1R µ2UGHUB1R (1'&RPSHQVDWLRQ6HW&RPSXWDWLRQ DBVHW $&7,9,7<(;(&87(' %(*,1(&3&RPSXWLRQ VL]H 6,=(B2)DBVHW HFS ),567FRPSBVHW IRUL L VL]HL ^ 5ROOEDFNB7RHFS LI,17(56(&75(6285&(B:527(B%<DBVHWL 24XDQWLW\ (1'(&3&RPSXWLRQ (1')$,/85( (PSW\6HW FRPSBVHW 81,21FRPSBVHWDBVHWL ` '2B&RPSHQVDWLRQFRPSBVHW (1'&RPSHQVDWLRQ6HW&RPSXWDWLRQ %(*,1(&3&RPSXWLRQ HFS ),567FRPSBVHW 5ROOEDFNB7RHFS (1'(&3&RPSXWLRQ (1')$,/85(

Fig. 7. Two WfFH code examples.

4 The System Architecture and Implementation Execution codes

Definition of activities Definition of activity A1 Definition of activity A4 Definition of activity B1

Definition of activity A2

...

Definition of activity A3

Definition of activity Ai

Definition of activity B1

...

...

Flow of activities

Begin activity ……….

JOO-WfMS compiler

if ((quantity>order_limit) && (period==HOT)) RAISE_FAILURE over-quantity(order_NO,100);

Recovery definitions Recovery definition of failure F1

Recovery definition of failure F2

Recovery definition of failure F3

…

Compensation subroutine definitions Definition of a workflow process

Execution code object

………. End activity

Default compensation subroutine

Compensation suboutine for failure F1

Compensation suboutine for failure F2

…

JOO-WfMS compiler

JOO-WfMS compiler

Failure-handling objects

Compensation objects

Definition of an activity

Fig. 8. Generating Java object codes of a workflow process

Here we are implementing a Java-based object-oriented WfMS (JOO-WfMS [21]) which supports the WfFH language. Fig. 8 shows the workflow process definition which conforms to the syntax of the JOO-WfMS as compiled using the JOO-WfMS compiler to generate Java object codes (or Java class files), including some activity objects, a flow object, some failure-handling objects, and some compensation objects. An activity object includes information and codes for executing the activity. Also, each activity object is associated with some failure-handling objects and compensation objects. The flow object is used to control the order of execution of the activities. These Java objects are sent to the JOO workflow engine which activates and controls the execution of the workflow process encoding by these Java objects. There are stan-

146

G.-H. Hwang, Y.-C. Lee, and B.-Y. Wu

dard Java interface definitions for workflow, flow control, activity, execution code, failure, and compensation handler objects in JOO-WfMS. The way to activate the failure-recovery process is specified in the execution code of the definition of the activity (see Fig. 5). In the JOO-WfMS, the execution code of an activity is also a Java program with the failure-recovery extension, which is of the following form: 5$,6(B)$,/85()DLOXUHB1DPHDUJDUJ«DUJQ

The JOO-WfMS compiler translates the above statement into the following Java program: 7RJHQHUDWHDQDUUD\DUJVWRVWRUHDUJDUJ«DQGDUJQ 2EMHFW>@DUJV QHZ2EMHFW>Q@ DUJV>@ DUJ DUJV>@ DUJ « DUJV>Q@ DUJQ 7RLQVWDQWLDWHDIDLOXUHREMHFW )DLOXUHIDLO DFWLYLW\JHW)DLOXUH)DLOXUHB1DPH 7RVHWXSWKHIDLOXUHDUJXPHQWV IDLO6HW$UJXPHQWVDUJV 7RWKURZD-DYDH[FHSWLRQWRVWDUWWKHIDLOXUHUHFRYHU\SURFHVV WKURZQHZ5DLVH)DLOXUH([FHSWLRQIDLO

The following is a fragment from the execution code of the activity definition of A6. It specifies how to activate recovery process of the inventory_insufficient and over-quantity failures: … LILQYHQWRU\RUGHUHGBTXDQWLW\ 5$,6(B)$,/85(LQYHQWRU\LQVXIILFLHQW LITXDQWLW\!RUGHUBOLPLW SHULRG +27 5$,6(B)$,/85(RYHUTXDQWLW\RUGHUB1RRUGHUBOLPLW «

The “LQYHQWRU\,” “RUGHUHGBTXDQWLW\,” “TXDQWLW\,” “RUGHUBOLPLW,” “SHULRG,” and “RUGHUB1R” are local variables in the execution codes of A6. If the value of “LQ YHQWRU\” is less than “RUGHUHGBTXDQWLW\,” it will activate the failure recovery according to the recovery definition named “inventory-insufficient” (see Fig. 7). Also, if “TXDQWLW\” is greater than “RUGHUBOLPLW” and the “SHULRG” is “+27,” the recovery for an over-quantity failure will start. The code translated by JOO-WfMS compiler is shown as follows: LILQYHQWRU\RUGHUHGBTXDQWLW\ ^ )DLOXUHIDLO DFWLYLW\JHW)DLOXUH´LQYHQWRU\LQVXIILFLHQWµ WKURZQHZ5DLVH)DLOXUH([FHSWLRQIDLO ` LITXDQWLW\!RUGHUBOLPLW SHULRG +27 ^ 2EMHFW>@DUJV QHZ2EMHFW>@ DUJV>@ RUGHUB1R DUJV>@ RUGHUBOLPLW )DLOXUHIDLO DFWLYLW\JHW)DLOXUH´RYHUTXDQWLW\µ IDLO6HW$UJXPHQWVDUJV WKURZQHZ5DLVH)DLOXUH([FHSWLRQIDLO `

Fig. 9 uses an example to illustrate how the JOO-WfMS compiler translates the WfFH code in Fig. 7B into a Java program. We currently have a Java implementation

A New Language to Support Flexible Failure Recovery

147

of the JOO-WfMS that supports our proposed workflow failure-handling model. For details about it, refer to [21]. Over-Quantity failure in WfFH

Java Code

)$,/85(RYHUTXDQWLW\LQWRUGHUB1RLQWRUGHUB/LPLW SXEOLFFODVV)DLOXUHB2YHUB4XDQWLW\H[WHQGV)DLOXUH ^ 9DULDEOHGHFODUDWLRQV 9DULDEOHGHFODUDWLRQV $FWLYLW\6HWDBVHW %(*,1'HFODUDWLRQ $FWLYLW\6HWFRPSBVHWHFS $FWLYLW\B6HWDBVHW 5HVRXUFH6HW2LQYHQWRU\24XDQWLW\ $FWLYLW\B6HWFRPSBVHWHFS LQWLVL]H 5HVRXUFH2LQYHQWRU\24XDQWLW\ LQWLVL]H (1''(&/$5$7,21 0HWKRGVWRKDQOGHDUJXPHQWVRIIDLOXUH SXEOLFYRLG6HW$UJXPHQWV2EMHFW>@DUJV ^ IRULQWL LDUJVOHQJWKL IDLOXUH$UJVDGG(OHPHQWDUJV>L@ ` SXEOLF2EMHFW>@*HW$UJXPHQWV ^ 2EMHFW>@REM QHZ2EMHFW >IDLOXUH$UJVVL]H @ IDLOXUH$UJVFRS\,QWRREM UHWXUQREM ` SXEOLF&ODVV>@*HW$UJXPHQW7\SHV ^ &ODVV>@FOD QHZ&ODVV >IDLOXUH$UJVVL]H @ IRULQWL LIDLOXUH$UJVVL]H L FOD>L@ IDLOXUH$UJVHOHPHQW$WL JHW&ODVV UHWXUQFOD ` &RPSXWHFRPSHQVDWLRQVHW &RPSXWHFRPSHQVDWLRQVHW SXEOLF$FWLYLW\6HW&RPSHQVDWLRQ6HW&RPSXWDWLRQ ^ %(*,1&RPSHQVDWLRQ6HW&RPSXWDWLRQ FRPSBVHW QHZ$FWLYLW\6HW 24XDQWLW\ 6(/(&7B'%5(&25'6´:)B'%µ´6(/(&7 LQW2UGHUB1R TXDQWLW\)5202UGHU)RUP:+(5( ,QWHJHU *HW$UJXPHQWV >@ LQW9DOXH 2UGHU)RUP2UGHU1R µ2UGHUB1R 24XDQWLW\ 6(/(&7B'%5(&25'6´:)B'%µ DBVHW $&7,9,7<(;(&87(' ´6(/(&7TXDQWLW\)5202UGHU)RUP:+(5( VL]H 6,=(B2)DBVHW 2UGHU)RUP2UGHU1R µ2UGHUB1R IRUL L VL]HL DBVHW $&7,9,7
Fig. 9. Translating of the WfFH code into the Java program.

5 Performance Evaluation We conduct a series of experiments to evaluate the performance of the failurehandling system in JOO-WfMS. The performance was evaluated by measuring the time required to instantiate the execute code, compensation, and failure-handling objects as well as the computation of compensation set and ECP. All the experiments

148

G.-H. Hwang, Y.-C. Lee, and B.-Y. Wu

were performed on a PC with a 1-GHz Pentium VI processor, 512 MB of RAM, the MS Windows 2000 operating system, and Java Development Kit 1.4.1_01 [22]. Table 1. The times required to instantiate the execute code, compensation handler, and failure objects (in seconds)

Activity A1 Execution code object (code_a1.ser – 169 bytes)

Activity A2 Execution code (code_a2.ser – 169 bytes)

Activity A3 Execution code (code_a3.ser – 171 bytes) Compensation handler object of failure F1 (cfii_a3.ser – 531 bytes) Compensation handler object of failure F2 (cfoq_a3.ser – 531 bytes) Compensation handler object of failure F3 (cfwc_a3.ser – 531 bytes) Compensation handler object of failure F4 (cfwo_a3.ser – 531 bytes) Compensation handler object of failure F5(cfib_a3.ser – 531 bytes)

Activity A4 Execution code (code_a4.ser – 169 bytes)

Activity A5 Execution code (code_a5.ser – 169 bytes)

Activity A6 Execution code (code_a6.ser – 169 bytes) Failure object of failure F1 (fii.ser – 654 bytes) Failure object failure F2 (foq.ser - 698 bytes)

Activity A7 Execution code object (code_a7.ser – 169 bytes) Failure object of failure F3 (fwc.ser – 653 bytes) Failure object of failure F4 (fwo.ser – 651 bytes)

Activity A8 Execution code object (code_a8.ser – 169 bytes)

Activity A9 Execution code object (code_a9.ser – 169 bytes) Failure object of failure F5 (fib.ser – 651 bytes)

Activity A10

0.025

0.025

0.022 0.029 0.029 0.033 0.025 0.031

0.022

0.022

0.024 0.030 0.032

0.021 0.029 0.030

0.021

0.021

0.017

0.015 0.019 0.020 0.020 0.020 0.019

0.016

0.016

0.016 0.020 0.020

0.015 0.020 0.020

0.015

0.021 0.030

0.015 0.020

Execution code (code_a10.ser – 170 bytes) 0.023 0.016 Compensation handler object of failure F1 (cfii_a10.ser – 532 bytes) 0.028 0.022 Compensation handler object of failure F2 (cfoq_a10.ser – 532 bytes) 0.027 0.024 Compensation handler object of failure F3 (cfwc_a10.ser – 532 bytes) 0.026 0.022 Compensation handler object of failure F4 (cfwo_a10.ser – 532 bytes) 0.027 0.019 Compensation handler object of failure F5 (cfib_a10.ser – 532 bytes) 0.027 0.022 The serialized Java objects are on the local hard disk. The serialized Java objects are on a remote Web site in the same network segment (100Mbps).

Table 1 presents times required to instantiate the execute code, compensation, and failure-handling objects of the workflow shown in Fig. 3. In the JOO-WfMS, all these objects are translated into serialized Java objects to support dynamic linking and execution. We also list the size of the serialized Java objects, e.g., the execution code object of activity A1 comprised 169 bytes. The serialized Java objects are either on the

A New Language to Support Flexible Failure Recovery

149

local hard disk or on a remote Web site in the same network segment (100Mbps). Table 2 shows times required to compute the compensation set and ECP. Experimental results obtained demonstrate the efficiency and practicability of the proposal failure-handling model. Table 2. The times required to compute the compensation set and ECP (in seconds) Failure F1 Failure F2 Failure F3 Failure F4 Failure F5

3.20E-4 6.26E-4 1.88E-4 9.40E-5 9.40E-5

6 Conclusion The paper has addressed workflow failure recovery in WfMSs. The new failurerecovery model proposed in this paper provides the workflow designer with a WfFH language in which to write programs to guide the recovery. New features of the proposed new model include: (1) computing the ECP and compensation set according to the execution results during the workflow process run-time, (2) employing data-flow analysis technology to guide the failure-recovery process, (3) allowing multiple failures to occur in a single activity with different recovery definitions, and (4) minimal dependency between activities of the failure-recovery definitions, thereby reducing the maintenance cost and improving the reusability of the workflow process. Due to space limitations, some important issues are discussed only briefly or not at all. First, in our implement, each recovery definition written in the WfFH language is translated into a Java object, which makes the JOO-WfMS use a Java-based workflow engine to activate the failure-recovery process. Second, we have also designed an activity-monitoring protocol for recording the accesses of shared resources, and this forms the basis for the data-flow analysis technology used in our model. Third, we have not described how to send the arguments of the recovery definitions to the compensation subroutines. Refer to [21]formoredetails.

References 1. D. Georgakopoulos, M. Hornick, and A. Shet. Overview of Workflow Management: From Process Modeling to Workflow Automation Infrastructure. Distributed and Parallel Databases, Vol. 3, No. 2, 1995, Pages 119–153. 2. Shi Meilin, Yang Guangxin, Xiang Yong, and Wu Shangguang. Workflow Management Systems: A Survery. International Conference on Communication Technology, 1998. 3. A. Elmagarmid, and W. Du. Workflow Management: State of the Art vs. State of the Market. Proceedings of NATO Advanced Study Institute on Workflow Management Systems, 1997. 4. Workflow Management Coalition. Workflow Reference Model. Workflow Management Coalition Standard, WfMC-TC-1003, 1994. 5. Workflow Management Coalition. Workflow Management Systems: A Survery. Workflow Handbook, 2001.

150

G.-H. Hwang, Y.-C. Lee, and B.-Y. Wu

6. Nina Edelweiss and Mariano Nicolao. Workflow modeling: Exception and Failure Handling Rrepresentation. IEEE International Conference of the Chilean Computer Science Society, 1998. 7. Fabio Casati, Stefano Ceri, Stefano Paraboschi, and Guiseppe Pozzi. Specification and Implementation of Exceptions in Workflow Management Systems. ACM Transactions on Database Systems, Vol. 24, No. 3, September 1999, Pages 405–451. 8. Claus Hagen and Gustavo Alonso. Exception Handling in Workflow Management Systems. IEEE Transactions on Software Engineering, Vol. 26, No. 10, October 2000, Pages 943–958. 9. Weimin Du, Jim Davis, and Ming-Chien Shan. Flexible Specification of Workflow Compensation Scopes. ACM Group, Phoenix, Arizona, USA, 1997. 10. M. Kamath and K. Ramamrithan. Failure Handling and Coordinated Execution of Concurrent Workflows. IEEE International Council for Open and Distance Education, 1998. 11. J. Eder and W. Liebhart. Workflow recovery. IEEE International Conference on Cooperative Information Systems, 1996. 12. W.M.P. van der Aalst. The Application of Petri Nets to Workflow Management. The Journal of Circuits, Systems and Computers, Vol. 8, No. 1, 1998, Pages 21–66. 13. Sea Ling and H. Schmidt. Time Petri nets for workflow modelling and analysis. IEEE International Conference on Systems, Man, and Cybernetics, 2000. 14. N.S. Glance, D.S. Pagani, and R. Pareschi. Generalized process structure grammars (GPSG) for flexible representations of work. Proceedings of Conference on Computer Supported Cooperative Work, 1996. 15. James Gosling, Bill Joy, and Guy Steele. The Java Language Specification (First Edition). Addison-Wesley, Reading, Massachusetts, USA, 1996. 16. D. Worah and Amit Sheth. Transactions in Transactional Workflows. In: S. Jajodia and L. Kerschberg (eds) Advanced Transaction Models and Architectures, Kluwer Academic, Boston, Massachusetts, USA, 1997. 17. Afred V. Aho, Ravi Sethi, and Jeffery D. Ullman. Compilers Principles, Techniques, and Tools, Addison-Wesley, Reading, Massachusetts, USA, 1986. 18. Gwan-Hwan Hwang, Huey-Der Chu, and K.C. Tai. Testing of Non-Deterministic Client– Server Database Applications. The 2001 International Conference on Parallel and Distributed Processing Techniques and Applications (PDPTA 2001), June 25–28, 2001, Monte Carlo Resort, Las Vegas, Nevada, USA. 19. Gwan Hwan Hwang, Sheng-Jen Chang, and Huey-Der Chu, “Testing Client/Server Database Applications,” Technical Report, National Taiwan Normal University, 2002. http://bashful.ice.ntnu.edu.tw/~ghhwang/papers/Testing_CSDB.pdf. 20. Sun Microsystem, Inc. JSR-000053 Java™ Servlet 2.3 and JavaServer Pages™ 1.2 Specifications. http://jcp.org/aboutJava/communityprocess/first/jsr053/index.html, March 2002. 21. Gwan-Hwan Hwang and Yung-Chuan Lee, “The Architecture of JOO-WfMS and its implementation,” Technical Report, National Taiwan Normal University, 2003. 22. Sun Microsystem, “The Source for Java(TM) Technology,” http://java.sun.com, 2002.

Constraint-Based Flexible Workﬂows Jacques Wainer and F´ abio de Lima Bezerra IC – UNICAMP Avenida Albert Einstein, 1251 Caixa Postal 6176, CEP 13083–970, Campinas, SP, Brasil {wainer,fabio.bezerra}@ic.unicamp.br Abstract. This work presents the idea and a prototype of workﬂow systems deﬁned through constraints. We think that in many domain areas, such as health care, workﬂow systems are too inﬂexible. One does not know in advance what activities does the patient has to go through. Actually a new form of interaction with the workﬂow is needed, in which a controller asks the systems which precondition activities are necessary in order to execute a target activity and schedule the target activity. We also present Tucupi, a prototype of such constraint based WFMS.

1

Introduction

Workﬂow management systems (or WFMS) are systems that allow for the speciﬁcation, execution, and monitoring of business processes. In execution, an instance of a process, or a case goes through a series of activities performed either automatically or by people, according to a pre-speciﬁed process deﬁnition. In usual business domains, the process deﬁnition is created well in advance of its use, and although most process deﬁnition formalisms allow for process that have some ﬂexibility, this ﬂexibility is deﬁned in advance as conditional execution of diﬀerent (pre-deﬁned) paths based on some of the case data. In particular, we are interested in the domain of health care. In this domain, as well as others, there is the need for what we will deﬁne as partial workﬂows, that is, workﬂows that are only partially deﬁned and are conditional. When a patient is admitted to an hospital, one does not have information to deﬁne, at that time, all the activities will be performed to/one behalf of the patient. Clearly, after the patient is discharged, one can look back and see the patient’s stay as the execution of a workﬂow: activities ordered in time where performed to/on behalf of the patient, but at no moment there was a workﬂow speciﬁcation that of which the patient’s case was an instance. So patient care, as many other activities, such as software design, are a kind of plan as one goes along workﬂow. The execution of the case, or better the particularities of the case as it unfolds, deﬁnes which activities should be performed next, or in the future. But whoever is in control of the workﬂow case, does not have total freedom to decide which activity must be performed next. There are rules or constraints that must be followed that imposes the execution of unrequested activities, that forbids some activities for being executed or at least being executed now, and delays the execution of activities, and so on. J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 151–158, 2003. c Springer-Verlag Berlin Heidelberg 2003

152

J. Wainer and F. de Lima Bezerra

Moreover, in domains with less deﬁned processes, usually there is a person, or people, which we will call the controller who decides which activities must be performed to the case, which we call the target activity. In the hospital example, a physician (the controller) decides that a surgical intervention is needed (the target activity). In the workﬂow as a helper scenario, the workﬂow will help the controller decide on the implications of the target activity. The implications certainly involves the need to execute activities both before and after the target activity (which we call forced activities). In some domains, temporal constraints regarding the forced activities may place further constraints in the execution of the target activity. For example, an organization may deﬁne a rule that meetings must be proceeded by the distribution of the meeting preparatory material at least two days before the meeting itself. Thus the workﬂow as a helper can inform the controller that to call a meeting with the development team, he must generate the preparatory material, and if he does that immediately the sooner the meeting can happen is in two days. However, standard workﬂow systems are inadequate to model and enact such work activities situations. Workﬂow systems, as used in the business environment, only allow for well deﬁned processes. The workﬂow deﬁnition for such processes is total and complete: the workﬂow deﬁnes all the activities that will be executed in a case and in which order. Once activity A has ﬁnished the system can compute exactly which activities must start now. In such deﬁned processes, the workﬂow system works as a dispatcher – at the end of an activity it computes which activities become enabled and dispatch the case to the executors of such activities. The control of what will be executed is in the WFMS, and some control of when the activity will start (once enabled) is left to the executors themselves (if the WFMS uses the concept of inboxes). This paper is organized as follows: in section 2 we present the representation of the constraints in the workﬂow deﬁnition; in section 3 we present the Tucupi, a prototype of a workﬂow system that it uses workﬂows based on constraints; in section 4 a discusion about temporal reasoning is presented; in section 5 we present some related works and in the section 6 some conclusions and suggestions of extension that can be implemented.

2

Constraint Representation

This section will present the form as the restrictions that the deﬁnition of a process composes must be represented. For in such a way, we will use a restricted language. The language deﬁne both the preconditions and post conditions of a target activity. The simpliﬁed version of a constraint is illustrated in the following example: rule: c1 target: A precondition: B precondition: C postcondition: D

Constraint-Based Flexible Workﬂows

153

We call such rules above as order constraints. The order constraint c1 specify that to perform the target activity A, activity B must have ended (precondition: B), activity C must also have ended, and activity D must happen after A is ended ( postcondition: D). The full complexity of the constraint language is reached by adding the following constraints constructs: – the precondition can be a disjunction of activities target: A precondition:

B or C

state that in order for A to be enabled, either B must have happened or C must have happened; – also in precondition there can be a constraint that an activity should not have happen before the target activity target: A precondition: not b state that in order for A to be enabled, B must not have happen before; – the construct parcondition (after parallel condition) states that an activity must happen either before or after the execution of the target activity target: A parcondition: B state that if A is executed then B must be also executed. The constraints also can be used to represent a traditional (or total) workﬂow deﬁned with the structures: AND-Split, XOR-Split, AND-Join, XOR-Join and sequencing. Space constraints do not allow us to elaborate this further.

3

Implementation – The Tucupi Server

The core of the system is the Tucupi server, which at execution time answers queries, and accept commands and updates from the controller. In fact, the server receives queries and commands from a known source but does not verify that the source is a or one of the authorized controllers. It assumes that some other software component will perform the authentication. The server answers to the following queries: who(A,C,W). This query returns the users that can perform activity A for the case C of the process W. This is a pure WRBAC query; enabled(C,W). This query returns the list of enabled activities for case C of process W. An activity is enabled if its preconditions were satisﬁed; not-ready(C,W). This query returns the list of activities that are not yet enabled for the case C of process W. This includes forced and target activities which do not have all their preconditions satisﬁed;

154

J. Wainer and F. de Lima Bezerra

what-if(A,C,W). This query returns a chain of precondition activities of all forced activities that have to be executed in order to perform the target activity A. For example, if an activity A1 has activity B1 as a precondition activity, and B1 has activity C1 as a precondition activity, then the query will return activities B1 and C1. The server also accept the following updates and commands: started(U,A,C,W). This command informs the server that activity A for case C of process W started now and that U is the executor of that activity ; ended(A,C,W). This command informs that activity A for case C of process W ended at this time; add(A,C,W). This command informs the server to add the target activity in the future of the case C for process W. The corresponding forced activities are either placed in the enabled list (if they have no precondition themselves) or in the not-ready list. 3.1

Architecture

The architecture of server is composed of three components as depicted if ﬁgure 1: WRBAC Component. The component that implements the WRBAC model [7]. WRBAC is an extension of the Role-Based Access Control (RBAC [8, 1]) mechanism to workﬂows. WRBAC adds to the RBAC concepts that of a workﬂow case, and associates to each activity in a workﬂow a corresponding privilege to execute that activity. Using the concept of a workﬂow case it is possible to model dynamic rights and non-rights in extension to the RBAC static modeling of rights. Thus, WRBAC Component is used as a mechanism of access control. Workﬂow Deﬁnition Component. The component used by the user to deﬁne the process using the rules presented above. Workﬂow Engine Component. It is the main component. It is used to process the queries made by users. Moreover, it is used as a mechanism of execution, for example, when the user starts (or ends) a workﬂow or activity. The server was implemented in Prolog, and the current version achieve persistence of the dynamic information by saving the state to a ﬁle after each new update. This, of course, places some limits on the frequency of updates the system can handle, but such limit was not reached in the tests performed (a few updates per minute). 3.2

Rule Derivation

The representation of workﬂow as a set of restrictions has limitations. The definition of workﬂow needs to include declarations that indicate when and which activity must be executed during the execution of a case. However, constraints

Constraint-Based Flexible Workﬂows

155

Tucupi Workflow Engine Component

Interface USES

MANIPULATES

MANIPULATES

WRBAC Component

Organizational Structure: Roles, Users and Privileges

Interface

MANIPULATES

Process Definition: Constraints and Activation Rules

Workflow Definition Component Interface

Fig. 1. The Tucupi Architecture

are declarations that indicate what is not allowed to be made, what [9] called negative rules. The positive rules are rules that indicate what it must be done, therefore the opposite of the negative rules. Rule derivation is a transformation of the rule as presented above into two new rules: a consistency rule and an activation rule. The consistency rule maintain the original semantics of the constraint, whereas the activation is a positive rule.

Constraint rules

constraint(c01) :− not(started(b) −> ended(a); true).

rule: c01 target: B precondition: A postcondition: C

Activation rules

next(b) :− not(started(b)), ended(b). next(c) :− not(started(c)), ended(b).

Fig. 2. A rule derivation example

156

J. Wainer and F. de Lima Bezerra

The ﬁgure 2 illustrates an example of rule derivation. The derived rules had been written in Prolog. The predicates ended and started are update commands presented above. A single rule may generate more than two (Prolog) constraints, depending on the granularity needed for the internal representation of the constraints. This is irrelevant for the current work, but as we discuss in the last section, for future work we expect to add the “constraint overriding” feature of WRBAC [7] into this system, and in that case, exactly how much of the rule is embedded into the constraints is important, since it is these internal constraints that will be overridden. In the example presented in ﬁgure 2, we have a constraint C01 generated from rule with the same name, C01. The derivation states that C01 will be a violation if b try to start and a has not ended yet. The activation rules are generated for each postcondition and for each target activity. These rules dispatch the activation of activity indicated in next function argument. In example presented in ﬁgure 2, we have a next(b) function generated from target activity B and a next(c) function generated from postcondition C. The next(b) function states that b will be the next activity if b has not started yet and the activity a has ended. The next(c) function states that c will be the next activity if c has not started yet and the activity b has ended.

4

Temporal Reasoning

Finally, both the representation language and the Tucupi implementation include some components of temporal reasoning. These features are still in a tentative stage. The representation language allow the modeler to specify that the target activity A must be preceded by the end of B in less than say 10 hours. And that after the end of A, C must be started in no less that 20 hours but no more than 3 days. The implemented system already deals in a limited fashion with temporal limits on activities, but although the system does not perform full temporal constraint satisfaction reasoning, it is yet unclear to us how to fully characterize the temporal reasoning that is indeed performed. For example, the constraint language allow one to deﬁne temporal limits for preconditions, such as rule: r5 target: C precondition: B [10] which state that B must have ended within 10 hours of the start of C. Such information is displayed to the controller, as the answer to the what-if(C,c45,w2) query. Also when computing the forced activities of the target C now, if B has ended in more than 10 hours ago, the system will determine that B must be executed again. Since B must be restarted, some of its precondition, in particular the ones with temporal limits, may no longer support the new execution of B,

Constraint-Based Flexible Workﬂows

157

and they will have to restart also. The system will also compute them as forced activities for the target C. But for example, when C really start, the system does not perform any check if B’s precondition is still valid. The reason is that the server does not start the activity, it is only informed when the activity stared! In standard workﬂows and in our constraint based workﬂow without the temporal information, once an activity becomes enabled, it remains enabled. The new situation, with temporal limits, seems to require the Tucupi server to give up the client-server approach and require that the starting of an activity must necessarily “go through” the system. In this case, the system can control at the time when the controller wants to start the activity if it is still enabled or not. Such change in the system is simple but it moves the system from a “workﬂow as just a helper” to some combination of helper and dispatcher. It is not yet clear to the developers the consequences of such decision. Finally, also as a limitation of the currently implemented temporal reasoning component, computing forced activities is only performed if the web of preconditions (or postconditions) is a tree, that is, C may have temporal preconditions on B, and B may have temporal preconditions on A, but for example A cannot have a postcondition on some activity that is also a postcondition of B or C.

5

Related Work

To the authors knowledge there are very few works on constraint or even logic based workﬂow representation formalisms. The closest work to this research is the one reported in [5,4], in which a ﬂexible workﬂow is deﬁnes as a set of workﬂow segments (in a graphic notation). A full workﬂow is constructed by “gluing” these workﬂow segments. A strong limitation of these works refers to the absence of an activation mechanism and the deﬁnition of post conditions. The work reported in [9] also has similarities with this one. There, a temporal logic is used to represent the temporal ordering among activities in a workﬂow and some of the ﬂavor of using a logic language that do not over-specify the constraint. In that work, a non-monotonic logic is used to infer which activities are enabled and thus can start immediately. In our work we use a simpler rule that all activities that have all preconditions fulﬁlled are enabled (modulo the time limits), and thus can start. Paul Dourish et al. [2] describes Freeﬂow, a prototype workﬂow system that uses constraints as a workﬂow model. Similarly to Tucupi, in Freeﬂow the user has total control over actions in system, but does not have a controlled way of override a constraint. In Freeﬂow, the system only alerts the user about the existence of constraint and all the user has to do is accept or not execute the action in presence of a constraint. Workﬂow with time limits between activities are also not common in the literature ([3,6] are some of the examples). It possible that in business applications such temporal limits are less common, and thus such requirement has not been contemplated by the workﬂow literature. By expanding the areas of possible

158

J. Wainer and F. de Lima Bezerra

application of workﬂow technologies (for example into health care) it becomes clear that such requirements are useful.

6

Conclusion and Future Work

The major extension of the framework described above is to include controlled overriding of constraints. In an exceptional case, it may be necessary to violate the rules expressed in the constraints. For example, if an emergency operation is needed, some of the preconditions of this target activity may be overridden, by a controller whit the proper authorization. WRBAC [7] already includes the concept of overriding (executor) constraints for dealing with exceptional cases, and clearly such idea can be extended into the process deﬁnition itself. Finally, the temporal reasoning component will probably include a full temporal constraint solver algorithm, in order to deal with non-tree graphs of precondition and postconditions. And very likely the server will become more of a dispatcher system in which activities are started by the system and thus the preconditions checks are performed when the activity is about to start. Acknowledgments. The authors would like to thank the comments and contributions of the anonymous reviewers.

References 1. Role Based Access Control: Features and Motivations, IEEE Computer Society Press, New Orleans, Louisianna, December 1995. 2. P. Dourish, J. Holmes, A. MacLean, P. Marqvardsen, and A. Zbyslaw. Freeﬂow: mediating between representation and action in workﬂow systems. In Conference on Computer Supported Cooperative Work CSCW96. ACM, November 1996. 3. J. Eder and E. Panagos. Managing time in workﬂow systems. In L. Fischer, editor, Workﬂow Handbook 2001, pages 109–132. Future Strategies INC, 2000. 4. P. Mangan and S. Sadiq. On building workﬂow models for ﬂexible processes. In The Thirteenth Australasian Database Conference ADC2002, Melbourne, Australia, 2002. 5. P. J. Mangan and S. Sadiq. A constraint speciﬁcation approach to building ﬂexible workﬂows. Journal of Research and Practice in Information Technology, 2002. 6. O. Marjanovic and M. Orlowska. On modeling and veriﬁcation of temporal constraints in production workﬂows. Knowledge and Information Systems, 1(2), 1999. 7. name withheld. W-RBAC: a workﬂow secutiry model incorporating controlled overriding of constraints. submitted, 2003. 8. R. Sandhu, E. Coyne, H. Feinstein, and C. Youman. Role-based access control models. IEEE Computer, 29(2):38–47, 1996. 9. J. Wainer. Logic representation of processes in work activity coordination. In Proceedings of the ACM Symposium on Applied Computing, Coordination Track, volume 1, pages 203–209. ACM, ACM Press, March 2000.

Workflow Recovery Framework for Exception Handling: Involving the User 1

2

Hernâni Mourão and Pedro Antunes 1

College of Business and Administration, Setúbal Polytechnic Institute Campus do IPS – Estefanilha, 2914–503 Setúbal, Portugal, and LASIGE (Laboratory of Large Scale Information Systems) [email protected]

2

Faculty of Science, University of Lisbon, Departamento de Informática Campo Grande – Edifício C5, 1749–016 Lisboa, Portugal, and LASIGE (Laboratory of Large Scale Information Systems) [email protected]

Abstract. Unexpected exceptions in WfMS are situations not predicted during the design phase. Human involvement in handling this type of exceptions has been recognized to be a crucial factor. We developed a framework to support the user in handling these situations by redesigning the flow, ad hoc executing the affected tasks, and manipulating engine status. A good characterization of the exception is needed to help the user identifying the best executable solution. The proposed characterization results from integrating operational, tactical and strategic perspectives over unexpected exceptions. An open source platform was selected to establish a test base on which the framework will be tested.

1 Introduction Workflow exceptions are situations not predicted in the workflow model or when there exists a deviation from the model and the real world [16]. Workflow exceptions have been accounted for almost half of the total working time in an office [21]. Up to now, workflow exceptions have mostly been addressed in a systems perspective, even though a consensus seems to arise on the necessity of involving the user in the recovery of a specific kind of exceptions. Therefore we developed a framework aimed to fulfill this identified gap. The framework is built around the idea that human intervention must be supported with quality information about the problematic situation, status of the workflow engine and possible recovery solutions. Considering the work in progress, this paper currently offers two contributions to exception handling in WfMS: (1) an integrated perspective over exceptions and exception handling, considering three different organizational levels (strategic, tactic and operational) affected by exceptions and respective human roles in recovery (design changes, ad hoc execution, and engine status manipulation); and (2) a set of WfMS components necessary to help and support these roles: event handler, situation aware J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 159–167, 2003. © Springer-Verlag Berlin Heidelberg 2003

160

H. Mourão and P. Antunes

ness, problem characterization and recovery toolkit. These components are currently being validated on an open source platform. The paper is organized as follows. Section 2 reviews the literature and establishes the grounds for the proposed framework. Section 3 presents the integrated perspective, where different exception handling approaches are mapped to the organizational levels where they occur and are handled. In Sect. 4 we describe the components that constitute our solution. In Sect. 5 we describe the project current status, identify the main current contributions, and discuss the expected results.

2

Literature Review

In this section we first identify the characterization of exceptions found in the literature and then the handling strategies adopted. 2.1 Characterization of Exceptions [7] characterize failures and exceptions in a single dimension, encompassing two types of failures and two types of exceptions:

Basic failures – Associated with failures on the systems supporting the WfMS (e.g., operating system, database management system and network failures);

Application failures – Failures on the applications invoked to execute tasks (e.g., unexpected data input);

Expected exceptions – Events that can be predicted during the modelling phase but do not correspond to the “normal” behaviour of the process (e.g., a customer reporting a car accident in a car rental company);

Unexpected exceptions – When the semantics of the process is not accurately modelled by the system (e.g., changes in rules, or a change in the order processing of an important client).

[8] suggests an escalating concept to transform the failures that cannot be resolved in the level where they occur into exceptions. This way, the classification can be reduced to exceptions. [4] combines the above view with another orthogonal characteristic described as “exception source.” The exception source can either be internal or external to the workflow. A similar classification is adopted by [22] but without any distinction between expected and unexpected exceptions. Next, we will analyse the expected and unexpected exceptions in more detail, primarily basing our comments on results produced by the WfMS research community. Later, to complete this review, we will present a broader perspective, oriented towards the organizational semantics. Expected exceptions are cases that can be predicted during the modelling stage but do not correspond to the “normal” process behaviour. Some mechanisms should be

Workflow Recovery Framework for Exception Handling: Involving the User

161

implemented to handle these situations because they can occur frequently [7] and can cause a considerable amount of work to process. In the car accident example, the company has to re-schedule all future rentals for that specific car until the car is repaired. The “normal” behaviour of the process should have been the returning of the car to the company, as planned, while the accident corresponds to a deviation or an “occasional” behaviour: an expected exception. [2] identifies four classes of expected exceptions, according to the events that generate them: workflow, data, temporal, and external. Workflow exceptions occur on starting or finishing a task. When workflow relevant data changes a data exception can be fired. Temporal exceptions are related to time stamps, e.g., car not returned on time. Finally, external exceptions are activated by external signals, e.g., the car accident example. Unexpected exceptions result from inconsistencies between process modelling in the workflow and the actual execution [2]; and result from incomplete or design errors, improvements or changes in the business manoeuvre or quality and customer satisfaction issues not known during the modelling stage. This type of exceptions is frequent in highly complex or dynamic environments and cannot be predicted during the modelling phase. Usually, unexpected exceptions force the process to change to a halt state and require human intervention [13]. In situations where this kind of exceptions occurs frequently, one should consider redesigning the workflow model, if it is out of date, or adopting different technologies based on collaborative work or adaptive workflow systems [3]. [21] proposes a taxonomy based on the organizational semantics associated to exceptions. This work defines a set of base concepts necessary to construct a consistent conceptual framework and fundament the characterization of organizational exceptions. Namely, the concepts of rule, case, event and their relationships are the basis for the framework. The proposed taxonomy was developed from empirical studies. A special attention was made on the social and financial impacts of exceptions. Six different criteria are used to classify exceptions:

Exceptionality – Difference between the exceptional and “normal” event; Handling delay – Time elapsed between the exception identification and handling; Amount of work – Extra work required to handle the exception when compared to the normal event; Organizational influence – Number of people involved in the exception; Cause – A measure of the importance of the reason for the exception; Rule impact – the changes in the organization’s rules due to the exception. Three classes of exceptions were identified according to exceptionality: established exceptions, otherwise exceptions, and true exceptions. Established exceptions occur when rules exist in the organization to handle an event but the right ones cannot be found. Otherwise exceptions occur when the organization has rules to handle the normal event but do not apply completely to the case. Finally, true exceptions occur when

162

H. Mourão and P. Antunes

the organization has no rules. According to the organizational influence criteria, exceptions can also be classified at employee, group and organizational level. 2.2 Exception Handling WfMS systems should deal with failures and exceptions at execution time because predicting any possible cause of failure or exception during design is very difficult or even impossible and makes the system very complex and hard to manage [2; 5; 9; 14]. In a primitive approach, we could rely on the system that supports the WfMS. In fact, most of the commercially available DBMS on the market implement the necessary transaction processing mechanisms to react in case of failure, returning the system to a coherent state and enabling forward execution [2]. On the other hand, some tasks do not run in transactional environments and a typical task can span over a long period of time. This is the complex environment of organizations where typical DBMS solutions are not adequate [22]. Some suggestions to overcome these problems consider relaxing the ACID properties and incorporating compensation mechanisms for backward recovery and forward execution, incorporating the flexibility required for workflow systems [16]. Several researchers are working in these issues [6; 9; 11; 15]. A good survey of this area, which became known as Extended Transaction Models (ETM), is presented by [22]. The error handling semantics of traditional transaction processing systems is also too rigid for workflow [16; 22]. The handling of application failures based on transactional approaches offer, in general, extreme and expensive solutions in terms of lost work and should be avoided. Therefore, some application failures should then be treated as expected exceptions [2]. Some other studies have proposed the adoption of dynamic and adaptive workflow systems to react to exceptions during workflow execution. The operator, on the presence of an exception, could change the system by either creating a new path for the exceptional process or change all the processes running on the system to the newly created path. Some studies have been carried out to keep the system’s consistency and correctness during/after the change, e.g., [1; 10; 18; 20]. [5; 6] recognized the fixed control sequence and the rigid compensation policy of the ETM approach and developed the Event Condition Action (ECA) rules to decouple the detection and handling of exceptions from the system itself and to increase flexibility. [3] describes a system to deal with expected exceptions based on ECA rules. The language Chrimera-Exc is used to specify exceptions and augment the WfMS characteristics to automatically detect and handle expected exceptions. [17] describes a system using a Case Base Reasoning (CBR) scheme to derive patterns for exception handling. The current exception is matched to a knowledge base and the system determines the appropriate action to handle the specific case. Despite all these efforts to automatically handle exceptions, the majority of authors involved recognize the limits of the proposed solutions. They either recognize the importance of interrupting the process and integrating some manual mechanism

Workflow Recovery Framework for Exception Handling: Involving the User

163

[9; 14], or explicitly state that in some situations the role of humans is crucial to collect process specific data not available to the workflow system [2; 13; 17]. To complete this review, it is important to mention two other approaches introducing a broader perspective over workflow exceptions. [12] proposed an integrated architecture of formal coordinated processes with informal cooperative processes. [21] presents an approach focussed on organizational semantics. Petri nets, outside the scope of the WfMS, define the reactions to the various types of exceptions, and should be interpreted as a global organizational reaction to exceptions.

3

Integrated Perspective

From the above discussion we can assume that accounting for all possible exceptions requires an integrated approach, where different levels of the organizational system affected by exceptions must be involved. Depending on the cause and impact of the abnormal situation, a suitable recovery mechanism at the most adequate level should be invoked. The operational level provides an environment for handling basic and application failures only, where the traditional transaction processing techniques can be sufficient to bring the system back to a coherent state and continue execution without human intervention. Whenever these techniques are not able to solve the problem, the event is propagated to the tactical level, and the failure may be converted into an external exception. At the tactical level, the WfMS may automatically handle expected exceptions in many different ways. For instance, using ETM techniques [9]. The extensive work done on adaptive workflow, which falls in this level, should increase the system flexibility and augment its adaptation to real world situations in handling expected exceptions. At this level, human contribution is possible but limited to producing the information necessary to have the system applying the exception handling techniques (e.g. compensation, retry, ignore, etc). Eventually, if none of the techniques implemented at this level are able to handle the event, it should be propagated to the strategic level, where the attention of a human operator to an unexpected exception is raised. Even though several authors present some ideas on how to incorporate human involvement in exception handling, we believe that the problem has not yet been completely addressed. [9] describes the idea of a system that incorporates human intervention in two possible modes: (1) ad hoc extension, where the user can suspend the execution of a task and choose alternative paths or change the execution model; and (2) ad hoc refinement, where the user interrupts the task execution to execute one or more activities and later on proceeds with the interrupted task. Even though the authors integrate this model in their framework, we believe that it should be completed in terms of the tools/methodologies available to help and support the user manipulating the environment in which s/he operates. In [17], a user-interface is provided to assist human intervention. The exceptions tagged as requiring human intervention come to the attention of an expert that can choose one candidate solution within the system proposals, or write a new solution. In

164

H. Mourão and P. Antunes

order to react to unexpected exceptions, the system is notified by an external signal and generates an internal exception event. However, it is not clear how this mechanism can be implemented for any particular type of unexpected exception. Moreover, it is not foreseen any assistance mechanism to provide a general view of the situation nor any support tool to change the model. Note that although human participation is considered at both the tactical and strategic levels, the strategic level envisages a more dramatic intervention in the WfMS. This will be discussed in more detail in the next section.

4

Our Approach to a Solution

In our proposed system, the interaction between the WfMS and the user is supported by the following components: Event Handler. This component is responsible for launching the recovery process whenever an unexpected exception is detected. It interacts with the user in order to display and manage any upstream and downstream exception propagations related with the exception (e.g., a basic failure previously propagated as an external exception, or an employee exception subsequently propagated as a group exception). This component also interacts with the WfMS to identify the target user. In order to facilitate this identification, by default, unexpected exceptions are classified as “established” and “employee.” Situation Awareness. This component is responsible for gathering and displaying to the user generic data about the workflow and engine status associated with the exception. In particular, it lists all tasks defined by the WfMS, their status and other important details, like task goals. This component also allows the user to identify which tasks are affected by the exception. Problem Characterization. This component employs the criteria defined by [21] to obtain from the user the information necessary to classify (or reclassify) an exception as a true, established or otherwise exception. It also allows the user characterizing the organizational influence of the exception (employee, group or organizational level) and identifying the relevant participants. A list of participants is gathered from the WfMS. Recovery Toolkit. Based on the situation awareness and problem characterization, this component offers a collection of pre-defined actions, which can be combined by the user to manipulate the process design, process execution and engine status. The following collection of pre-defined actions is actually considered:

Engine status – Start/terminate or suspend/continue several tasks; manipulate process relevant data or workflow participants;

Process execution – Support ad hoc extensions and ad hoc refinements to the process instances affected by the exception; apply design changes according to the specification;

Workflow Recovery Framework for Exception Handling: Involving the User

165

Design – Change one or several process definitions, either affected by this exception or not; define how and when the modifications are applied (one/all instances, immediately or after completion).

Note that the user can execute, in any order, multiple actions in each one of the above three categories. The heuristic used for proposing the best solutions according to the characterization of exceptions is the following: otherwise exceptions are commonly handled by ad hoc extensions or refinements applied to the affected process instances; established exceptions can be handled by instantiating already available process definitions; and true exceptions require design changes and possibly cascading the exception to other users. If, in the first two cases, the organizational influence of the exception is the organization, the approach must be coordinated with other areas.

5

Project Status and Expected Results

We selected OpenSymphony [19] to implement our solution. OpenSymphony is an open-source platform based on J2EE technology. The prototype consists of Enterprise Java Beans (EJB) for functional components and web-tier components for front end – all components are platform, database and application server independent. The workflow specification uses a XML file rather than a graphical user interface, which gives more flexibility to cope with changes in the process definitions. The workflow engine is based on the concept of a finite state machine where each state is represented by a combination of StepID and status. The engine supports Java-based functions, BeanShell scripts, and Bean Scripting Framework scripts. Another type of functions is triggered by outside sources and run under the system context. Figure 3 shows the user interface implementing our exception handling approach. The user interface highlights the four main components necessary to our approach. The user can analyse the list of exception propagations in the Event Handler area, if any. The interface allows analysing upstream and downstream exceptions, as well as propagating the current exception. In the Situation Awareness area, the user sees a list of all the tasks running on the system (left side). Selecting the affected ones and pressing the right arrow button, they are transferred to the right side. This way it is possible to identify all the currently running tasks that are affected by the exception. Whenever necessary, the specific task details, including its goals, can be viewed/edited. The Problem Characterization area enables the selection of the exception characteristics according to our approach. At this stage only the exceptionality and organizational influence are considered. The other four characteristics (handling delay, amount of work, cause, and rule impact) can only be defined at the end of the exception handling, for historical records. In the organizational influence zone there is an area that changes according the selection, allowing to select an employee, group leader or organizational manager, respectively. This way someone is always associated with an exception. There is also the possibility of sending emails to everyone involved.

166

H. Mourão and P. Antunes

Fig. 1. Interface for exception handling

In the Recovery Toolkit area the user can decide the recovery action(s) to implement on this specific case. As noted before, any combination of the defined above actions can be used for the particular case, although the system suggests some predefined actions. On the type, action, and parameters columns the user selects one option from a list. A working prototype is currently being developed to implement the described framework. We expect to test this prototype with a collection of simulated situations to test the applicability, flexibility and robustness of the framework. A real world situation should complete the study, raising issues not possible to predict in a simulation (particularly concerning the usability of the prototype). With this work we also expect to improve the OpenSymphony platform, allowing the workflow components to cope with unexpected exceptions.

References 1. Aalst, W.v.d., 1999. Generic workflow models: how to handle dynamic change and capture management information. Int. Conf. on Cooperative Information Systems, pp. 115–126. 2. Casati, F., 1998. Models, Semantics, and Formal Methods for the Design of Workflows and their Exceptions. PhD Thesis, Politecnico di Milano. 3. Casati, F., Ceri, S., Paraboschi, S., and Pozzi, G., 1999. Specification and Implementation of Exceptions in Workflow Management Systems. ACM Transactions on Database Systems, 24(3): 405–451. ACM Press. 4. Chiu, D.K., 2000. Exception Handling in an Object-oriented Workflow Management System. PhD Thesis, Hong Kong University of Science and Technology. 5. Dayal, U., Hsu, M., and Ladin, R., 1990. Organizing Long-Running Activities with Triggers and Transactions. Int. Conf. on Management of Data SIGMOD’90, NJ, USA.

Workflow Recovery Framework for Exception Handling: Involving the User

167

6. Dayal, U., Hsu, M., and Ladin, R., 1991. A Transactional Model for Long-Running Activities. 17th Int. Conf. on Very Large Data Bases (VLDB’91). Barcelona, Spain. 7. Eder, J., and Liebhart, W., 1995. The Workflow Activity Model WAMO. Int. Conf. on Cooperative Information Systems, Vienna, Austria. 8. Eder, J., and Liebhart, W., 1996. Workflow Recovery. 1st IFCIS Intl. Conf. on Cooperative Information Systems (CoopIS’96). IEEE, Brussels, Belgium, pp. 124–134. 9. Eder, J., and Liebhart, W., 1998. Contributions to Exception Handler in Workflow Management. EDBT'98, Workshop on Workflow Management Systems. Valencia, Spain. 10. Ellis, C., Keddara, K., and Rozenberg, G., 1995. Dynamic change within workflow systems. Proc. of Conf. Organizational Computing Systems, Milpitas, CA, USA, pp. 10–21. 11. Georgakopoulos, D., Hornick, M., and Manola, F., 1996. Customizing Transaction Models and Mechanisms in a Programmable Environment Supporting Reliable Workflow Automation. IEEE Transactions on Knowledge and Data Engineering, 8(4): 630–649 12. Guimarães, N., Antunes, P., and Pereira, A.P., 1997. The Integration of Workflow Systems and Collaboration Tools. In: A.K. Dogaç, Leonid Ozsu (Editor), Advances in Workflow Management Systems and Interoperability. Instambul. 13. Heinl, P., 1998. Exceptions During Workflow Execution. EDBT'98, Workshop on Workflow Management Systems. Valencia, Spain. 14. Klein, M., and Dellarocas, C., 2000. A Knowledge-Based Approach to Handling Exceptions in Workflow Systems, CSCW, 9(3): 399–412. Kluwer Academic Publishers. 15. Krishnakumar, N., and Sheth, A.P., 1995. Managing Heterogeneous Multi-system Tasks to Support Enterprise-wide Operations. Distributed and Parallel Database Systems, 3(2). 16. Luo, Z., 2001. Knowledge sharing, Coordinated Exception Handling, and Intelligent Problem Solving for Cross-Organizational Business Processes. PhD Thesis, Dep. of Computer Sciences, University of Georgia. 17. Luo, Z., Sheth, A.P., Kochut, K., and Arpinar, I., 2002. Exception Handling for Conflict Resolution in Cross-Organizational Workflows, LSDIS Lab, Computer Science, Un. of Georgia. 18. Myers, K.L., and Berry, P.M., 1999. At the Boundary of Workflow and AI. Proc. of the AAAI-99 Workshop on Agent-Based Systems in The Business Context Held. 19. The OpenSymphony project. http://www.opensymphony.com, 2001, 20–04–2003. 20. Reichert, M., and Dadam, P., 1998. ADEPTflex – Supporting Dynamic Changes of Workflows Without Loosing Control. Journal of Intelligent Information Systems, 10(2): 93–129. 21. Saastamoinen, H., 1995. On the Handling of Exceptions in Information Systems. University of Jyväskylä, PhD Thesis, University of Jyväskylä. 22. Worah, D., and Sheth, A.P., 1997. Transactions in Transactional Workflows. In: S.K. Jajodia, Larry (Ed.), Advanced Transaction Models and Architectures. Kluwer Academic Publishers.

COW, a Flexible Platform for the Enactment of Learning Scenarios Thomas Vantroys1,2 and Yvan Peter1 1

TRIGONE Laboratory, NOCE Team Bˆ at. B6 – Cit´e Scientiﬁque 59655 Villeneuve d’Ascq, France {Thomas.Vantroys,Yvan.Peter}@univ-lille1.fr http://noce.univ-lille1.fr 2 Archimed SA 49 Boulevard de Strasbourg 59042 Lille, France [email protected] http://www.archimed.fr

Abstract. Open and Distance Learning platforms are more than systemis delivering pedagogical resources. They require mechanisms for the enactment and coordination of pedagogical modules and learning activities. A common solution to express learning paths in learning management systems (LMS) can be the use of Educational Modelling Languages (EML). The next step will be the enactment of these models. For that purpose, workﬂow management systems can be used. These systems formerly reserved for highly structured procedures can be used in dynamic and reactive environments such as virtual campuses platforms, thanks to an enhanced ﬂexibility in the execution of models and in the management of exceptions. In this article we shall present COW our ﬂexible workﬂow engine dedicated to open and distant learning. We will compare EML and workﬂow approach and see how to pass from a pedagogical modelisation to a workﬂow modelisation. We shall see how it is possible to organize the pedagogical modules and the learning paths to answer the expectation within the framework of individual courses (lifelong learning orientation) or within the framework of group courses (closer to the traditional face to face learning).

1

Introduction

The model driven approach is gaining momentum. We can see that with the Model Driven Architecture (MDA) [1] promoted by the Object Management Group [2], which aims to separate the model of a system from its implementation. The main reason is that a change in the technology ﬁeld, like passing from Java to C#, should not have consequences on the model because models are persistent and implementation are transient. The same approach can be conducted in learning management systems (LMS). The model of a course is independent J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 168–182, 2003. c Springer-Verlag Berlin Heidelberg 2003

COW, a Flexible Platform for the Enactment of Learning Scenarios

169

from its execution platform. To express models, Educational Modelling Languages have emerged like PALO [3] or EML [4], and a work on standardization has began in the CEN/ISSS (Information Society Standardization System) [6]. The next step is the execution of these models. A possible approach can be the use of ﬂexible workﬂow systems [10], [11]. Indeed, the pedagogical sciences teach us to structure and coordinate the learning activities and as explained in [11] learning is process-oriented. Managing the schedule of the activities performed by students can be a daunting task for tutors and teachers especially if there are a large number of students. They have to keep track of each student’s progress to provide them with new activities. Workﬂow systems are dedicated to this kind of work. However, even in case of virtual classroom style of distance learning, one would like to be able to adapt the learning path of a particular student to better ﬁt his needs. This kind of ﬂexibility is unfortunately not well handled by current workﬂow systems. For this reason, we have decided to start the development of a ﬂexible workﬂow system dedicated to distance learning. In this article, we will present the work we have done to build a ﬂexible workﬂow system suited to LMSs and our reﬂexions about the enactement of Educational Modelling Languages (or more precisely IMS-LD) by our workﬂow system. We will describe how pedagogical modules and learning paths can be organized to support both individual learning paths (lifelong learning orientation) and group based courses (closer to the traditional face to face learning). The next section will present more precisely what are the purposes of the EMLs. We will notably see the diﬀerent category of languages which compose the EMLs. We will emphasize on IMS Learning Design (IMS-LD) which is, from our perspective, one of the best approach to describe a learning scenario. Then in section 4 we will present workﬂow systems in general and more precisely the modelisation aspect in the standard of the Workﬂow Management Coalition (WfMC). After that, we will present COW, our ﬂexible workﬂows system dedicated to the enactment of learning scenario. We will explain the base requirements and how we realize them. Section 7 will show the existence of a common concepts between learning ﬂow and work ﬂow and so the links we can weave in order to transform an IMS-LD scenario into a workﬂow process. Then we will present how the course models are instantiated and enacted. Section 9 will conclude our paper by summarizing our contribution and by reviewing the perspectives.

2 2.1

Educational Modelling Languages Presentation

Teaching is not just delivering information. Current platforms focus more on delivering pedagogical resources than on the pedagocial aspect of learning. Standardization eﬀorts are now moving from content delivery ressources to Educational Modelling Languages (EML). We take as deﬁnition for an EML the one provided by [6]:

170

T. Vantroys and Y. Peter

“An EML is a semantic information model and binding, describing the content and process within a ’unit of learning’ from a pedagogical perspective in order to support reuse and interoperability” EMLs group together many languages with diﬀerents aims. There are languages designed to express questionnaire and assessment like the Tutorial Markup Language (TML) [5] or the IMS Question & Test Interoperability (IMSQTI) [8]. We will explain more in details the IMS Learning Design Speciﬁcation because it is for us the language oﬀering the most easy way to express a learning path in a pedagogical neutral way. Futhermore, it seems to be on a good way to become a de facto standard. 2.2

IMS Learning Design Speciﬁcation

The IMS Learning Design Speciﬁcation (IMS-LD) [7] was published at the end of january 2003. It is based on the work done by the Open University of Netherlands on Educational Modelling Language [4]. This language expresses the “learning ﬂow”, i.e., how the diﬀerent learning activities are linked and the resources they use. A Learning design describes how learning objectives can be reached. As shown in Fig. 1, the core elements are activity, environment, role and method. – the central point of IMS-LD is the activity. An activity deﬁnes the work to do within an environment. An activity is assigned to a role.

Fig. 1. IMS-LD MetaModel from [7]

COW, a Flexible Platform for the Enactment of Learning Scenarios

171

– The environment deﬁnes the learning objects which can be digital or not and the services provided like a chat or a forum. – The role speciﬁes the participants of a learning-design. The roles are divided in two groups, learner and staﬀ. These roles can be sub-typed. – The method determines the global objectives and the prerequisites to begin the learning-design. It also contains the play which deﬁnes the learning process, i.e., the sequence in which the activities are made and the corresponding roles. A play is deﬁned as a theatrical play with acts.

3

Requirements for Learning Scenarios Enactment

As explained in the above section, EMLs are becoming a common way to express learning scenarios because they focus on the pedagogical aspect, more than on the resource aspect. They also oﬀer some great advantages like reusability and the use of high level concepts that can be understood and manipulated easily by a teacher even though models are still expressed in a technical manner (XML) and tools are still lacking. However, enacting these scenarios in a software platform is still an issue. What are the main requirements for this? First, the system must be fully compliant with one or more EMLs but this is implicit. The two main problems are the possibility to redeﬁne a part of the scenario during its execution and moreover to enable the users to participate in the changes. This is necessary because it is sometimes diﬃcult to fully express a scenario in details and some parts can change to adapt to the execution context. The context can evolve globally, changing laws for example, or locally, adapting to the need and the diﬃculties of a student. This is also in agreement with the work done in the ﬁeld of CSCW and with Activity Theory [9] which promote a user-centered and tailorable platform where the user is able to redeﬁne the model and the execution behavior. The others requirements from our point of view are a support for standardised pedagogical ressources (like LOM and SCORM) and a support for cooperation, notably during the changing phases to enable users to manipulate the learning scenario cooperatively for example by a negotiation between the tutor and her students. One category of software platform that can handle all these requirements can be ﬂexible workﬂows systems. So in the next section, we will present theses systems.

4 4.1

Workﬂow Systems Presentation

To deﬁne a workﬂow, we use the following deﬁnition from [14]: “Workﬂow is concerned with the automation of procedures where documents, information or tasks are passed between participants according to a deﬁned set of rules to achieve, or contribute to, an overall business goal.”

172

T. Vantroys and Y. Peter

Usually, workﬂow systems are used in administrative domain where procedures are well deﬁned and don’t suﬀer exception or dynamic redeﬁnition. This is mainly due to the fact that original workﬂows systems were heavily monolitic non ﬂexible systems. Current trend in workﬂow research try to resolve this problem by working on ﬂexible and dynamically redeﬁnable system at run-time. 4.2

The Workﬂow Reference Model

The workﬂow reference model is a standard from the Workﬂow Management Coalition (WfMC) whose aim is to promote the use of workﬂow through standardization and interoperability. This standard does not deﬁne the workﬂow engine itself but rather its interfaces as shown in ﬁgure 2. In a certain way, standardization in the e-learning domain follows the same principle, the LMS are not deﬁned but all the elements used by an LMS are, like pedagogical ressources or EML.

Fig. 2. WfMC reference model [14]

The workﬂow interfaces are the following: Interface 1 deﬁnes an XML language called XPDL (XML Process Deﬁnition Language) [13] to deﬁne process models regardless of the enacting platform. It enables the use of diﬀerent modelling tools as long as they can output XPDL; Interface 2 is used by client applications to access the workﬂow services; Interface 3 deﬁnes how the workﬂow engine can instantiate tools used in activities and get results from them; Interface 4 deﬁnes an XML language for workﬂow interoperability. It enables one engine to create subprocesses in another engine and get the results;

COW, a Flexible Platform for the Enactment of Learning Scenarios

173

Interface 5 is used by administration and monitoring tools to interact with the workﬂow. In order to compare workﬂow modelling and IMS-LD, we will now present the XPDL. 4.3

XPDL

As we have explained in the above section, IMS-LD expresses “learning workﬂow”. Is this learning ﬂow really diﬀerent from work ﬂow ? To answer this question, we will explain the meta-model of workﬂow systems (ﬁg. 3), published by the Workﬂow Management Coalition (WfMC). The 5 top-level entities are Process, Activity, Transition, Relevant Data and Participant. – Process deﬁnes the way to achieve a common goal, i.e., the path between the diﬀerents activities. It determine the execution context (overall description, input values, . . . ). This element is the container of all the other entities of the metamodel. – Activity deﬁnes the work to realize; There are three types of activities. Subﬂow activity allows to execute another sub-process, block activity consists of an activity set which is an aggregation of activities and transitions and atomic activity is the real work to do. At the execution time, this work is transformed into work items which are executed by participants and/or applications. – Transitions are the links between diﬀerent activities. They deﬁne the control ﬂow inside the process; – Relevant Data are the data used and produced by the process and the activities. This data can be linked with the data of the enterprise, as for example an LMS system;

Fig. 3. XPDL MetaModel from [13]

174

T. Vantroys and Y. Peter

– Participant represents a human, role or group to whom work items are assigned. Participant can be linked with the organizational model of the enterprise. After the presentation of EMLs and workﬂow systems, we will now present our platform for the enactment of learning scenarios.

5

The COW Platform

COW (Cooperative Open Workﬂow) is a ﬂexible workﬂow system developped in the Trigone laboratory which aims to enact learning path in LMS. 5.1

Requirements

This work has been driven by the following requirements: – Support diﬀerent learning styles. The workﬂow must be able to handle both individual and group work even within the scope of a single process; – Support collaborative activities. We believe that collaborative learning can be a way to enhance the learning experience and strengthen learners’ motivation; – Support dynamic redeﬁnition of the learning path. A tutor should be able to add activities for example if he detects a weakness in the learners knowledge. There are even some times when one does not even know beforehand the activities that will be needed; – Support for reuse of existing course and activities models. It will be easier for pedagogical engineers to build course modules from existing parts. So we would like to provide predeﬁned models (or skeletons) and also keep track of the models that have been modiﬁed during a course. From a technical point of view, we would conceive a “learning scenario enacting component” which can be included within existing LMS. And for more interoperability, we would also following the existing standards for the implementation of the workﬂow engine. In the next sections, we describe the work done in the Cooperative Open Workﬂow to meet these requirements. 5.2

Workﬂow Architecture

The implementation respects the Workﬂow Management Facility speciﬁcation [15] of the OMG and the workﬂow reference model of the WfMC [14]. Workﬂow Management Facility. The Workﬂow Management Facility (WMF) [15] standardizes the architecture of the workﬂow engine. It has been deﬁned by the Object Management Group (OMG) in accordance with the reference model of the WfMC. This standard deﬁnes entities such as WfProcess and WfActivity or WfResource which correspond to the elements described in a process model like XPDL. We have made an implementation of the interfaces proposed in the WMF with extensions to support collaborative activities, group management and enhance the reuse of models.

COW, a Flexible Platform for the Enactment of Learning Scenarios

175

An Open Micro-kernel Architecture. For the implementation, we have chosen a micro-kernel architecture. Our kernel oﬀers the base functionality of a workﬂow system. It was build using the MetaObject Protocol (MOP) [16]. This approach to obtain ﬂexibility is also used in CSCW [17]. We can realize two types of modiﬁcation in COW at run-time, the process model and the engine behavior. Process modiﬁcation consists in adding/deleting/changing activities and transitions. These changes can be realized for one person or for a group of learners. Behavior modiﬁcation consists in adapting the strategy to the local context, like how to react when an exception occurs ? The solutions can be to stop the activity or to send an e-mail, . . . . Thanks to this architecture, we can easily develop speciﬁc components to adapt the engine to speciﬁc needs. The integration within LMS systems is realized with a web-services approach. Each interface of our sytem is accessible by using the SOAP [21] protocol. User Aspects. Although we don’t focus on user interaction with a workﬂow engine, we have realised for demonstration purpose, a multi-channel access to our system. The engine outputs information in an XML format that we can transform to support multiple presentations such as HTML, WML or even VoiceXML using XSL stylesheets. A more detailed presentation can be found in [23].

6

Workﬂow Systems in Virtual Campuses

There are few virtual campused that use a workﬂow engine to schedule learning activities. We review two of them hereafter. 6.1

Flex-el

The Flexible e-learning system (Flex-eL) [11] has been realized by the Distributed Systems Technology Center (DSTC) [12] and the university of Queensland in Australia. It consists of a distance education platform supported by a ﬂexible workﬂow system. The focus of this work is on supporting the learning process rather than technology with the aim of designing a new learning environment to support new ways of learning. There a learning process for each student. This allow an easy way to adapt the learning path to the real need. Groups of students are dynamically constructed. The project started in march 2000 and the environment is currently tested at the University of Queensland in a course of a Master of Information Technology. According to the authors the ﬁrst results seem positive since there are few abandons. 6.2

Campus Virtuel

The virtual campus platform named Campus Virtuel [18] developed by Archimed SA [19] also integrates a workﬂow system to handle the activities of a course module (ﬁgure 4).

176

T. Vantroys and Y. Peter

Fig. 4. Course model in the Campus Virtuel

A teacher or tutor can break his course into activities and associate the documents to use to each activity. The system is backed by an Electronic Documents Management System to manage and provide the pˆedagogical ressources in the diﬀerent activities. The system is limited by the fact that it cannot handle individual work since every student in a group must have terminated the current activity to be able to access the next one, even though some of the activities could be realized individually.

7

Linking Educational and Workﬂow Modellings

To enact a learning model in a workﬂow system, we have to translate IMS-LD into XPDL. As we have described in the above sections the metamodel of the two languages, we can now draw links between the entities. A simpliﬁed view of the links between IMS-LD and XPDL is given in Fig. 5. The concept of activity is quite identical. We have a direct link between an activity in IMS-LD and an activity in XPDL. Some attributes of ActivityIM S−LD , like learning-objectives cannot be translated directly because these notions do not exist in a standard workﬂow system. To solve this problem, we used an element of the XPDL named extended attribute, designed to add speciﬁc vendor information in the XPDL. Hence, we avoid the loss of information during the transformation. And these information can be used by the LMS. The concept of activity-structure is not exactly an activity-set because there isn’t a self aggregation link for activity-set, i.e., an activity-structure can contains links to other activity-structure while the activity-set can not contain links to other activity-sets. In order not to lose this link, an activity-structure which contains link to another activity-structure is mapped to a workﬂow process. The environment in IMS-LD can be links to workﬂow applications and to workﬂow data. The services are applications.

COW, a Flexible Platform for the Enactment of Learning Scenarios

177

Fig. 5. Links between IMS-LD and XPDL

The roleIM S−LD can be mapped to participantXP DL with a role type. The informations of the methodIM S−LD , including playIM S−LD , are partially mapped to processXP DL and transitionsXP DL . To use IMS-LD models in our platform, we are currently implementing a transformer to pass from IMS-LD to XPDL which is the language used by COW. The rules of transformations are realized by using XSLT, because the two languages are based on XML. Now, we will explain how models are enacted in COW.

8

Course Models and Instances

The main function of the workﬂow system is to schedule the activities of a pedagogical module. Such a module is attended by a group of students (ranging from 1 to n). In the sequel, we will take a course in physics as an example of the modelling of a module to illustrate the management of models and instance inside the workﬂow and the management of both individual and group activities. This module is broken into four activities described hereafter:

178

– – – –

T. Vantroys and Y. Peter

course learning activity associated to the role learner ; exercises activity associated to the role learner ; exercise correction activity associated to the role tutor ; discussion about the module activity associated to the role learner and tutor.

Fig. 6. Modeling of a pedagogical module

8.1

Course Model

Since some parts of the module can be realized at his own rythm by each student, one has to take it into account so as to enable ﬂexibility in the schedule of the activities. There are two ways to manage the schedule of the activities for a group of students : – In the ﬁrst mode, an activity is terminated only when all the students have terminated it. In such a way, the activities of a whole group are synchronized. Even though it is very close to traditional face to face learning, it does not take beneﬁt of distance learning mode; – The second mode identiﬁes the parts of a module that can be realized autonomously. This way each student can progress at his own rythm inside a group with some activities giving a synchronization point to the group. These two modes are supported in COW by the mean of sub-processes. In our scenario, the teacher decides that the three ﬁrst activities can be realized

COW, a Flexible Platform for the Enactment of Learning Scenarios

179

individually by each student. These activities are then modelled into a single process. The process corresponding to the whole module is then composed of two sequential activities (see ﬁgure 6). The ﬁrst one being in fact a reference to the individual work sub-process and the second one corresponding to a synchronous discussion beetwen the members of the group.

Collaborative Activities. To handle collaborative activities, we have made some modiﬁcations to XPDL and the WMF to introduce the notion of workitem. A workitem is an atomic piece of work and an activity is composed of workitems. In the simplest case, there is only one workitem in an activity. However, within a collaborative activity, there can be more workitems. A workitem is attributed to a role, so if multiple actors have the same role, there will be an instance of the workitem for each of them in the activity. Resources are allocated to the workitems rather than the activity. In our example the discussion activity could be done with a chat tool but the learners and the tutor may not have the same rights on the tool since they do not have the same roles.

Time Constraints. Management of time constraints is an important aspect of learning activities. This is particularly true for group based learning where there must not be too much lag between the learners. COW supports the notion if deadlines which correspond to the time at wich an activity must be started or completed. It also support the notion of limit which deﬁnes the minimal and maximal duration of an activity. When a stop deadline of a maximum limit is reached, the workﬂow engine suspends the activity. It can then use diﬀerent policies to handle the case. For example, the system can terminate the activity authoritavely or notify the tutor who will take a decision about it. These behaviors can be dynamically change at run-time to be adapted to a changing context by the tutor.

8.2

Course Instance

The creation of a process instance requires an instance model which describes the mapping of roles to actual users and of resources to tools. The mappings can be global to the model or deﬁned on an activity basis. This separation between process model and instance data allows for a better reuse of models. Figure 7 illustrates the workﬂow operation. Taking the process and activities models and instance data, the workﬂow engine will create a subprocess for each learner. These subprocesses contain the three activities that can be performed individually and each activity contains only one work item. The third activity performed by the tutor role will have three workitems assigned from diﬀerent processes. When all subprocesses are terminated, the engine will create a collaborative activity with one workitem for each learner and one for the tutor.

180

T. Vantroys and Y. Peter

Fig. 7. course instantiation

9

Conclusion and Outlooks

In this paper, we have presented how it can be possible to execute IMS-LD models by using a workﬂow approach. We have compared the two metamodels and realized the mapping between them. Thanks to this comparison, we are implementing a model transformer to translate IMS-LD into XPDL, that will allow us to enact IMS-LD models with COW, our ﬂexible workﬂows engine designed for the educational ﬁeld. From our point of view, this approach is interesting because we use the concepts of two diﬀerent worlds. We think workﬂow technology is a great tool for the management of learning activities inside a virtual campus. Our engine is currently being integrated within the Campus Virtuel from the

COW, a Flexible Platform for the Enactment of Learning Scenarios

181

Archimed Company for their next release which will enable us to start realistic experimentations. There is still some unresolved problems and questions. How the prerequisite can be handled by the workﬂow system as a constrainst between diﬀerent process models and knowing these prerequisites and the wishes of a student, how can we automaticaly construct a learning path ? When we dynamically change the process model, our system saves changes in XPDL. In order to show the modiﬁcation to a pedagogical engineer we must export XPDL into IMS-LD, but we haven’t yet realize this transformation. Our future work will try to answer these questions and considering the use of an MDA approach to generate the implementation of the learning paths from the IMS-LD models. Acknowledgements. Research on workﬂow system has been funded by Archimed SA (http://www.archimed.fr).

References 1. OMG Model Driven Architecture, http://www.omg.org/mda. 2. Object Management Group. http://www.omg.org. 3. Miguel Rodriguez-Artacho. “PALO Language Overview”, technical report LSI Dept/TR-2002-01, Universidad Nacional de Educati´ on a Distancia, january 2002. http://sensei.lsi.uned.es/palo/PALO-TR.pdf. 4. Educational Modelling Language. Open University of Nederland. http://eml.ou.nl 5. Dan Brickley. “Towards an open question-interchange framework”, University of Bristol, http://www.ilrt.bris.ac.uk/netquest/about/lang/motivation.html. 6. CEN/ISSS WS/LT Learning Technologies Workshop. “Survey of Educational Modelling Languages (EMLs)”, version 1, 19 september 2002. 7. IMS Global Learning Consortium. “IMS Learning Design Information Model”, version 1.0 Final Speciﬁcation, 20 january 2003. http://www.imsproject.org/learningdesign/index.cfm. 8. IMS Global Learning Consortium. “IMS Question & Test Interoperability: An Overview”, version 1.2, 11 february 2002, http://www.imsproject.org/question/index.cfm. 9. G´egrory Bourguin, Alain Derycke and Jean-Claude Tarby. “Beyond the Interface: Co-evolution Inside Interactive Systems – A Proposal Founded on Activity Theory”, in proceeding of IHM-HCI 2001, Lille, France, September 2001. 10. Thomas Vantroys and Yvan Peter. “Un syst`eme de workﬂows ﬂexible pour la formation ouverte et ` a distance”, in proceedings of TICE2002, november 2002. http://tice2002.insa-lyon.fr. 11. Joe Lin, Charley Ho, Wasim Sadiq, Maria E. Orlowska, “On Workﬂow Enabled e-Learning Services”, In Proceedings of the IEEE International Conference on Advanced Learning Technologies, ICALT’2001, 6–8 August 2001, Madison, USA. 12. Distributed Systems Technology Centre http://www.dstc.edu.au. 13. Workﬂow Management Coalition. “Workﬂow Process Deﬁnition Interface – XML Process Deﬁnition Language”, WfMC-TC-1025, version 1.0, 25 october 2002. http://www.wfmc.org/standards/docs/TC-1025_10_xpdl_102502.pdf

182

T. Vantroys and Y. Peter

14. Workﬂow Management Coalition. “The Workﬂow Reference Model”, WfMC-TC1003, Version 1.1, 19 january 1995. http://www.wfmc.org/ 15. Object Management group. “Workﬂow Management Facility”,Version 1.2, 2000. http://www.omg.org/technology/documents/formal/workflow_management.htm. 16. Gregor Kiczales, Jim des Rivi`eres et Daniel G. Bobrow – The Art of the Metaobject Protocol. MIT Press, septembre 1991. ISBN : 0-26-261074-4. 17. G´egory Bourguin. “Un support informatique ` a l’activit´e coop´erative fond´e sur la Th´eorie de l’activit´e : le projet DARE”, Ph’D Thesis, Universit´e des Sciences et Technologies de Lille, 13 july 2000, Lille, France. 18. Claude Vi´eville. “Learning Activities in a Virtual Campus”, chapter 15 in The Digital University – Building a learning Community, Reza Hazemi and Stephen Hailes (Eds), Springer, pages 215–227, 2002. 19. Archimed SA. http://www.Archimed.fr. ¨ 20. Linda G. DeMichiel, L. Umit Yal¸cinalp and Sanjeev Krishnan. “Enterprise TM Speciﬁcation”, version 2.0, Sun Microsystems, Inc., 2001. JavaBeans 21. W3C. XML Protocol speciﬁcation. http://www.w3.org/2000/xp/. 22. W3C. Web Services Description Language (WSDL) 1.1. http://www.w3.org/TR/wsdl. 23. Thomas Vantroys and Jos´e Rouillard – Workﬂow and Mobile Devices in Open Distance Learning. In proceedings of IEEE International Conference on Advanced Learning Technologies ICALT 2002, Kazan, Tatarstan, 9–12 septembre 2002. http://lttf.ieee.org/icalt2002/.

Competency Management for Group Formation on the AulaNet Learning Environment Hugo Fuks, Luís Henrique Raja Gabaglia Mitchell, Marco Aurélio Gerosa, and Carlos José Pereira de Lucena Software Engineering Laboratory Catholic University of Rio de Janeiro (PUC-Rio) R. M. S. Vicente, 225, Gávea Rio de Janeiro, RJ, 22453-900, Brazil {hugo,raja,gerosa,lucena}@inf.puc-rio.br

Abstract. The IMS Project uses the notion of competency to model educational objectives. In the AulaNet learning environment competency management is used to form subgroups that, in the case of this article, are assigned to generate new educational content for the Information Technologies Applied to Education course. The purpose of this course is to get learners to learn to work with information technology as a group, turning them into Web-based educators.

1 Introduction Compared to people working only by themselves, working in groups has advantages such as synergy, the ability to consider more information, objective evaluation, cognitive stimulation and member learning from other members [1], which can be very useful both in work and learning environments. However, it is not an easy task to form groups envisaging collaboration. Management of competencies allows the coordinator to apply some criteria to the group formation process, in order to try to achieve the desired results of the collaborative activities. This document shows how competency management was applied to extend the AulaNet1 learning environment in order to provide features that could aid the group formation task. It also discusses the use of these new functionalities in the ITAE (Information Technologies Applied to Education) course, a discipline held entirely on the AulaNet environment for undergraduate and graduate Computer Science students as a field experiment for such new technologies. The following section briefly describes the AulaNet by summarizing the 3C Collaboration Model that guided its development and its services. Section 3 presents some aspects of the ITAE course, aimed to promote change in the learner’s working methods. Section 4 details the competency management features implemented to aid group formation and their use in ITAE. Finally, section 5 concludes the paper.

1

http://guiaaulanet.eduweb.com.br, http://www.les.inf.puc-rio.br/aulanet

J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 183–190, 2003. © Springer-Verlag Berlin Heidelberg 2003

184

H. Fuks et al.

2 The 3C Collaboration Model and the AulaNet To collaborate, people should debate ideas (communication), organize themselves (coordination) and operate together in a shared workspace (cooperate). Communication leads to commitment in performing tasks in order to have some job done. Coordinating these tasks is important to guarantee they are accomplished in the correct order, at the correct time and according to the restrictions imposed. The tasks are accomplished by the cooperation among the members of the group, which operate together in a shared space. This model is presented in Figure 1.

&RPPXQLFDWLRQ PHGLDWHV

KDUPV GHDOVZLWK

&RQIOLFWV

JHQHUDWHV

JHQHUDWHVFRPPLWPHQWV WKDWDUHPDQDJHGE\

IRVWHUV

IRVWHUV

&RRUGLQDWLRQ PHGLDWHV

*URXS $ZDUHQHVV

PHGLDWHV GHPDQGV

IRVWHUV

&RRSHUDWLRQ

DUUDQJHV WDVNVIRU v3.1

Fig. 1. The Collaboration Model

The AulaNet and the ITAE were developed with this model in mind. On the AulaNet, all the services are organized into communication, coordination and cooperation services. The AulaNet services are placed at the disposal of coordinators during the creation and updating of a course, allowing them to select those that they want to make available to the learners. In the ITAE, the course’s coordinator adds services to the course as it unfolds in order to smooth the absorption of the environment by the learners. The communication services provide facilities to allow the exchange of information. These services include: individual electronic mail exchange with the mediator (Contact with the Teachers); electronic mail with the entire group (Discussion List); asynchronous text discussion in a forum style (Conference); synchronous text chat (Debate); and the instantaneous exchange of messages with participants who are connected to the course (Messages for Participants). Since ITAE is a course that is mainly based on participant interaction, it uses all of the communications services. The coordination services, which are designed to organize the group, in AulaNet include a notification tool (Notices), a tool for the basic coordination of the flow of the course work (Lesson Plan), assessment tools (Tasks and Exams), and a tool for monitoring group participation (Follow-Up Reports). The ITAE course uses the following coordination services: Lesson Plan, Tasks and Follow-Up Reports. The cooperation services provide the means for cooperative learning [7], problem resolution and course co-authorship, both for teachers (Teacher Co-Authorship) and for learners (Learner Co-Authorship). The cooperative services also include a list of

Competency Management for Group Formation

185

extra contents that are not associated with any specific lesson (Documentation), and references to textbooks (Bibliography) and Internet pages (Webliography). The ITAE uses Bibliography, Webliography, Documentation and Learner Co-Authorship cooperation services. The Learner Co-Authorship service is used by learners to supply new content to the course, which is validated by the course coordinator.

3 Some Aspects of the ITAE Course The objective of the course is to make educators use the new technologies for teaching/learning. The course was taught for the first time during the first half of 1998 and, since then, one edition has been held each semester. In the beginning, the course structure included a weekly, live face-to-face class that was transmitted to outside learners, and a debate via the Internet, using the Debate service. This embryonic version of the ITAE served to generate educational content for the course, which was generated by recording the teachers’ presentations during the weekly classes and by copying the transcripts of the chat sessions. As it was generated, the content was made available within the environment and learners could access it at any time and from any computer connected to the Internet. Evaluation of learners in the ITAE is based on their participation and the quality of their contributions [13]. Although the AulaNet contains an evaluation service in the form of exams with questions, the ITAE did not make use of this service in order to evaluate learners based on collaborative rather than individual tasks. To help the mediators accompany the learners and to make it possible for the learners to evaluate their own level and quality of participation, follow-up reports of the environment were used to present information about the quantity, quality and type of participation [3]. To supply qualitative information, every and each participation has to be evaluated by the mediators, who need to grade and comment individual participation in the Debate and the messages in the Conferences. The Discussion List messages are not evaluated, since they are not part of the learners’ tasks. In the ITAE, most of the communication and all content self-study are conducted asynchronously. In asynchronous events, learners can participate at a time and place convenient to them and appropriate to the task, having more time to reflect before composing their messages [5]. In addition, though extrovert personalities continue to send more messages than quieter members do, they cannot dominate completely as in face-to-face or synchronous situations. Quieter members still have the opportunity to contribute, as described by [12]. But by reducing the pressure to respond, since it can be done at any time, it is easier for a learner to drop out of the group [6]. The mediators have to demand regular contributions in an appropriate timeframe to avoid dispersion. The Follow-Up reports helped to identify who was and who was not participating. The last phase of the ITAE course is to have the learners actively generating content for the course’s repository. To that end, the class was divided into subgroups, based on the learners’ competencies. For that purpose, the IMS Global Learning Consortium Reusable Competency Definition [10] was implemented in AulaNet.

186

4

H. Fuks et al.

Using Competency Management to Form Groups for Collaborative Content Generation

The Instructional Management Systems Global Consortium (IMS) is a well-known organization in the learning technology field, devoted to the establishment of standards and specifications. To model users’ profiles and learning groups, AulaNet follows two IMS specifications: the Reusable Definition of Competency or Educational Objective [10] and the IMS Enterprise Specification [9]. In such specifications, the word competency is used in a very general sense that includes skills, knowledge, tasks and learning outcomes. 4.1

Modeling and Linking Competencies to Content and Participants

A RDCEO is basically comprised of a globally unique identifier and a human readable title and description. Many other optional fields make the model flexible to be extended according to the specific needs of the application. On the AulaNet environment, they are linked to the contents (lectures, tasks etc.) of a course and, consequently, to the course itself. For the users, they are called Topics. As a result, the RDCEOs on any given AulaNet server reflect the competencies the courses being taught on that server deal with (either as prerequisites or learning outcomes). AulaNet also links RDCEOs to people, in an association named Competency, explained in the next section. 4.1.1 Interest, Qualification, and Performance In the context of AulaNet, a learner’s competency is expressed by three different factors (or dimensions): qualification, interest and performance. Interest reveals how much a learner is willing to be in contact with tasks or lessons involving that competency. It is used, for example, to form learning groups in the scope of a class, dividing up the learners according to the topics each student finds more appealing. Qualification is a declaration made by a learner stating his/her level of mastery (from novice to expert) regarding the competency represented by a RDCEO. It may or may not be backed up by a document such as a diploma or certificate. It maps what the student has learnt from outside the AulaNet environment. For example: in the context of sales force training, it could reflect how many sales a student has accomplished in practice. Performance is very similar to qualification, except that it is automatically filled out by the AulaNet system, according to the learning outcomes. It can be seen as a transcript of the learner’s academic life on the AulaNet. The environment sets the level of mastery of a performance item after processing the grades a learner got on course activities, according to the following:

• The weight of the type of activity. For example: Tasks are more relevant than Debates. • The weight of the RDCEOs they encompass. Although an activity is usually an indivisible unit, it may regard to more than one RDCEO. Example: a certain activ-

Competency Management for Group Formation

187

ity refers to 2 RDCEOs; one being relevant to 75% of the activity, whereas the other is referred in the remaining 25%.

• The obsolescence of the assessment. It reflects the tendency that newer grades are more accurate than older ones, as a person’s competency changes over time. Worth of mention is the fact that interest and qualification/performance are allowed to vary independently. Meaning that it is entirely possible to, for example, be very interested in a specific RDCEO but be a novice on it. Or, to be interested exactly because it is one’s expertise. This three-dimensional structure of an AulaNet RDCEO also reflects the different ways a learner can be evaluated in regard to a competency. Self motivation is reflected by the interest parameter. Self evaluation is reflected on the qualification parameter, which shows the learner’s own point of view about how qualified he/she is regarding that specific topic. And, when a docent assigns grades and weights to the collaborative activities learners performed during a course, it influences the learners’ performance parameter. As the grade may be the product of a group work, letting the group members divide among themselves the points earned by the group as a whole gives learners the chance to be evaluated by their own peers. 4.1.2 Issues Concerning the Use of RDCEOs On previous editions of the ITAE course, learners reported difficulties in evaluating themselves. Apart from being a cultural issue (participants were not used to self evaluation, feeling uncomfortable with it), it is believed one of the reasons for that was the lack of a thoroughly detailed explanation of the mastery levels of the RDCEOs used. To remedy that, the RDCEO’s optional field ‘Definition’ is going to be used to describe proficiency levels in more detail. Another issue Kay [11] points out is the overhead imposed to the learner in managing his RDCEOs declarations, a task that could become a distraction or be completely neglected. With that in mind, ITAE learners are encouraged to manage their RDCEOs at the breaks of the academic schedule. To enforce this policy, ITAE requires the fulfillment of the qualifications and interests of its RDCEOs as part of the enrollment process. Furthermore, notice that the responsibility for the RDCEOs is split up with the different roles there exist in the system: The system administrator defines the RDCEOs; Course Coordinators include RDCEOs into their courses (as Topics); Course Mediators (lecturers) link these topics to the course content; Learners, with the help of their Mentors (a supervisor, e.g.: the head of the employee’s department or a professor guiding a graduate student), fill up their interest and qualification profiles; and the AulaNet calculates the performance coefficient.

4.2

Subgroups in AulaNet and the Matchmaking Algorithm

At AulaNet, there are three different levels of granularity of a group. The first and broader one is ‘course’. Enclosed in a coursed are its ‘classes’ (groups). Learners and mediators belong to a class. The course coordinator belongs to the course, overseeing all of its classes. Optionally, a mediator can further subdivide learners into ‘subgroups’.

188

H. Fuks et al.

Subgroups are modeled in the AulaNet environment according to the IMS Enterprise specification, which recognizes the existence of the three core data objects described on the following conceptual model retrieved from [9]: 1.

Person: the individuals who are undertaking some form of study and/or group related activity (…)

2.

Group: a collection of objects related to learning activities or individuals. (…) There is no restriction on how the Group and sub-group structures can be used with respect to containing other groups, persons, etc.

3.

Group Membership: (…) is used to define the members of a Group. A member can be a Person or another Group (…)

Presently, subgroups are used in association with the Tasks service. When a subgroup is created, it is not immediately associated with a task. That allows the mediator to create several different subgroups, not restricting the number of members on each subgroup or the placement of a learner in more than one subgroup. This way, the mediator is given the freedom to form subgroups at any point of the course and to group learners differently, according to each activity. Once created, a subgroup remains inactive until the mediator associates it with a task. A subgroup can be associated with more than one task, in a structure flexible enough to allow a mediator to assign a learner working in two or more tasks to perform each task with the same group of people, with different people or even to work alone in any of the tasks. Mediators can resort to the environment’s automated subgroup formation feature when subdividing a class. The matchmaking algorithm [2] is designed to better relate learner’s competencies to the tasks to be accomplished. It takes the following input provided by the mediator: the number of subgroups to be formed; the number of members in each subgroup; whether a learner can be assigned to more than one of the subgroups to be formed; what RDCEOs are to be taken into account; what dimensions will be analyzed; and the degree of difference (regarding qualification/interest/performance) among the learners. The mediator is free to accept or rearrange the subgroups automatically formed. For example: mediators may be interested in forming subgroups either by homogeneity or by heterogeneity. By selecting an RDCEO and setting a degree of zero in respect to interest and four to qualification/performance, the mediator is promoting the formation of subgroups whose members are all interested in the same topics, but differ significantly in their qualification and performance. This could be used, for example, when the mediator wants to put together experts and novices with the same interests regarding a specific topic. 4.3

Collaborative Generation and Evaluation of Educational Content

In ITAE, in the end of the course, subgroups of two or three learners are formed using the matchmaking algorithm, using as RDCEOs the topics in the syllabus of the ITAE course. The aim is to group learners according to the topics they would like to study the most, putting together learners with somewhat similar competencies. The subgroup organizes itself in order to generate interactive multimedia educational content and must submit it by a given date. Then, a period of collaborative peer

Competency Management for Group Formation

189

review begins during which the members of at least three other subgroups evaluate each subgroup’s content. This evaluation takes place in conferences created specifically for this purpose. Within these conferences, learners discuss problems regarding the content that has been generated. Once this period is over, the subgroups are given a new deadline to present a revised version that incorporates the contributions of their colleagues. The course mediators evaluate this revised content, and some may be invited to become a part of the course’s repository.

5

Conclusion

The contribution of different understanding or the exposure to alternative points of view can enhance learning [8]. Group members can monitor individual thinking and the group structure provides social support and encouragement for individual effort [1]. In addition, through formulating ideas in their words, and receiving evaluation from peers, learners’ knowledge, thinking skills and meanings are socially constructed [7]. As Web-based educators to be, learners are supposed to be able to generate interactive multimedia didactic content that will be added to the course’s repository. Different from their own educators, Web-based educators work in a collaborative way to generate such contents. For that purpose, they are subdivided into subgroups based on their competencies. Extending IMS RDCEO’s Competency Model with the dimensions Interest, Qualification and Performance it becomes possible to run a matchmaking algorithm to define groups that best correspond to a set of criteria established by the course mediator. It is being used to divide up a class into the topics of the course, one group for each topic. Other possible future uses involving competency management could be: defining a learning or career plan, determining pre-requisites to activities and selecting the appropriated content to be offered to a learner. Acknowledgement. The AulaNet project is partially financed by the Fundação Padre Leonel Franca, by the Ministry of Science and Technology through its Program of Excellence Nuclei (PRONEX) grant nº 76.97.1029.00 (3366), and also through its Multi-Agent Systems for Software Engineering Project (ESSMA) grant nº 552068/ 2002-0. It is also financed by individual grants awarded by the National Research Council to: Carlos José Pereira de Lucena nº 300031/92-0, Hugo Fuks nº 303055/02-2, Marco Aurélio Gerosa nº 140103/02-3 and Luís Henrique Raja Gabaglia Mitchell. 130225/02-9.

References 1.

Benbunan-Fich, R. & Hiltz, S.R. (1999): ‘Impacts of Asynchronous Learning Networks on Individual and Group Problem Solving: A Field Experiment,’ Group Decision and Negotiation, Vol. 8, pp. 409–426.

190

H. Fuks et al. 2.

3. 4.

5.

6. 7. 8. 9.

Cunha, L.M. (2002): ‘Formação de Grupos de Trabalho Utilizando Agentes de Software’, MSc Dissertation, Computer Science Department, Catholic University of Rio de Janeiro, Brazil. http://ritv.les.inf.puc-rio.br/groupware/ [checked on 01/30/2003] Dushastel, P.A. (1997): ‘Motivational Framework for Web-Based Instruction,’ WebBased Instruction, Educational Technology Publications. Fuks, H., Gerosa, M.A. & Lucena, C.J.P. (2002): ‘The Development and Application of Distance Learning on the Internet,’ The Journal of Open and Distance Learning, Vol. 17, N. 1, ISSN 0268-0513, pp. 23–38 http://www.les.inf.puc-rio.br/groupware [checked on 30/01/2003] Gerosa, M.A., Fuks, H. & Lucena, C.J.P. (2001): ‘Use of Categorization and Structuring of Messages in order to Organize the Discussion and Reduce Information Overload in Asynchronous Textual Communication Tools,’ Proceedings of seventh International Workshop on Groupware, CRIWG 2001, IEEE, pp. 136–141. Graham, M., Scarborough, H. & Goodwin, C. (1999): ‘Implementing Computer Mediated Communication in an Undergraduate Course – A Practical Experience,’ JALN, Vol. 3 No.1-May. Harasim, L., Hiltz, S.R., Teles, L. & Turoff, M. (1997): ‘Learning networks: A field guide to teaching and online learning,’ 3rd ed., MIT Press. Hiltz, S.R. (1994): ‘The Virtual Classroom: Learning without limits via computer networks,’ Norwood, New Jersey: Ablex Publishing Corporation. IMS Enterprise Specification (2002): http://www.imsproject.org/enterprise/entv1p1/imsent_infov1p1.html

[checked on 01/30/2003] 10. IMS RDCEO Specification (2002): http://www.imsproject.org/competencies/rdceov1p0/imsrdceo_infov1 p0.html [checked on 01/30/2003]

11. Kay, J. (2001): ‘Learner Control. User modelling and User Adapted Interaction’, Netherlands, n. 11, p. 111–127, Kluwer Academic Publishers. 12. Straus, S.G. (1996): ‘Getting a clue: the effects of communication media and information distribution on participation and performance in computer mediated and faceto-face groups,’ Small Group Research, 27 (1), 115–142. 13. Thorpe, M. (1998): ‘Assessment and ‘third generation’ distance education,’ Distance Education, 19 (2), pp. 265–289.

1

Dynamic Generation of Adaptive Web-Based Collaborative Courses

Rosa M. Carro1, Alvaro Ortigosa1, Estefanía Martín1, and Johann Schlichter2 1

Escuela Politécnica Superior, Universidad Autónoma de Madrid 28049 Madrid, Spain {Rosa.Carro,Alvaro.Ortigosa,Estefania.Martin}@ii.uam.es 2 Fakultät für Informatik, Technische Universität München 85748 Munich, Germany [email protected]

Abstract. In this paper we present the use of adaptation techniques to dynamically generate adaptive collaborative Web-based courses. These courses are generated at runtime by selecting, at every step and for each student, the most suitable collaborative tasks to be proposed, the time at which they are presented, the specific problems to be solved, the most suitable partners to cooperate with and the collaborative tools to support the group cooperation. This selection is based on the users’ personal features, preferences, knowledge and behavior while interacting with the course. The advantages of this approach and the peculiarities of combining individual adaptation with collaboration seamlessly are also presented.

1 Introduction Adaptive hypermedia has been widely used for the development of adaptive Webbased courses [3]. In these courses the students are personally guided during the learning process. They usually interact with the courses alone, in their own time frame, and learn at their own pace. On the other hand, collaboration tools have been used in educational contexts [6] for supporting communication among students, discussions about topics [9], cooperative problem resolution [10], knowledge sharing, and collaborative knowledge construction [8]. A proper use of these tools reduces student isolation and facilitates the development of reasoning skills such as making ideas explicit, arguing, interacting with other students to build a common solution, etc. [1]. Our approach deals with the integration of collaboration capabilities in adaptive Web-based courses and the use of adaptation methods and techniques for the personalization not only of the course contents and navigational options, but also of the collaboration aspects. It consists not just of putting adaptive courses and collaborative tools together, but of integrating adaptation and collaboration in a seamless way.

1

This work has been partially supported by the German DAAD and the Spanish Inter-ministerial Commission of Sc. and Tech., projects TIC2001-0685-C02-01, TIC2002-01948

J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 191–198, 2003. © Springer-Verlag Berlin Heidelberg 2003

192

R.M. Carro et al.

Therefore, the users can benefit not only from adaptation and collaboration, but also from a combination of both of them. This paper is structured as follows: In section 2 the main features of adaptive collaborative courses are described. Section 3 presents the mechanism for generating these courses dynamically. Section 4 contains a discussion about the advantages and open issues concerning this work. Finally, in section 5 the future work is presented.

2 Adaptive Collaborative Courses While interacting with an adaptive collaborative course the students will be guided individually through the course contents. They will also be invited to cooperate with other students in the resolution of certain problems at specific points of the course. In addition, they will be able to share ideas, contact other students, and ask/answer questions about the whole course. In these courses, features such as the most suitable topics to be learned at each time, the multimedia contents to be used for page generation, the navigational options available at every step, and/or the collaboration activities, among others, are adapted to each user by taking into account his personal features, preferences, behaviors and achievements while taking the course. Concerning the collaboration activities, aspects such as the convenience of performing collaborative tasks at certain points of the course, the suitability of a collaborative task itself, the tools supporting the user’s interactions, the partners who a student will interact with, and the type of collaboration, among others, will be adapted. In order to support this personalized guidance, adaptive collaborative courses are described by means of:

- Tasks: represent the activities to be performed while interacting with the course, and can be atomic or composed. Atomic tasks represent theory to be learned, examples to be observed, self-assessment tests or exercises to be solved collaboratively. Composed tasks are decomposed in atomic and/or other composed tasks. - Content fragments: can contain texts, images, videos, simulations, animations, etc., and are used for page generation. Several versions of the same contents (a topic explanation, an example about a certain topic, or a problem statement) can be associated to the same task, each of them intended for a different type of student. - Course-structure rules: describe the organization of tasks in the course, i.e., which subtasks are part of a composed task, the order in which subtasks must be performed, if any, and the requirements for a task to be performed, if they exist. Each of these aspects can be different for different types of students. The requirements for a rule to be activated, that is, for its information to be used for the course structure generation for a particular student, are expressed in the rule activation conditions. These conditions can be related to the student’s features, preferences, actions or behaviors while interacting with the course. - Collaborative-workspace rules: describe the way in which problem statements and sets of collaborative tools are combined to compose specific collaborative workspaces. The sets of tools can be different for different collaborative tasks. Both the statements and the sets of tools can be different for dissimilar types of students,

Dynamic Generation of Adaptive Web-Based Collaborative Courses

-

-

-

193

even if performing the same task. The features of the students a workspace is intended for are stated in the respective rule activation conditions. Problem statements: describe the problems to be solved, including the goals and expected results. Different problems can be associated to the same task, so that the most suitable one for each group of students can be selected at runtime. Collaborative-tool rules: describe the way in which collaborative tools are integrated in the interface. Normally, the set of tools for each workspace has a subset of main tools and a subset of additional tools. The former compose the main interface, while the later are accessed from it. Different combinations for the same set of tools can be described in order to satisfy the user’s needs. For example, generally, students with a textual learning style prefer to propose solutions and discuss by writing texts, while those with a visual learning style usually prefer to create diagrams and draw their proposals. The most suitable tools for each group of students will compose the main interface, while the other tools will be accessible from it. There exist a set of collaborative-tool rules by default, so that if there is no special need, it is not necessary to describe them. A more complete description of collaborative-workspace rules and collaborative-tool rules can be consulted at [4]. Global collaboration tools: the course designer can specify which collaborative tools (email, forum, chat) will be available to support the communication and cooperation among all the users that are interacting with the same course. A set of global collaboration tools is provided by default. Rules for student grouping: are taken into consideration during the group formation. Rules to be used by default are provided; they indicate that students with similar features and preferences will be grouped. The course designer can define rules with different criteria to form the groups, either specifically for certain collaborative tasks or for the whole course.

An adaptive collaborative course can be completely described by tasks, coursestructure rules, collaborative-workspaces rules, content fragments and problem statements. The course designer must also specify the user features to be considered with either individual or collaborative adaptation purposes. These features are attributes whose values can be discrete values or ranges of values; the designer will be able to select among those proposed in the authoring tool and/or to specify new ones, if needed. He will be able to provide a pattern (with background, headers, etc.) to be used to generate all the pages related to the same course, as well as to indicate if he offers himself to be consulted during the course execution by e-mail. The description of adaptive collaborative courses will be supported by an authoring tool that is also being developed. In this tool, collaborative editors, forums, chats, file sharing and e-mail programs are available, so that the course designers will only have to select the specific ones to be offered for each collaborative task.

3 Dynamic Course Generation Once the course components have been described, the course itself is dynamically generated for each student at runtime. In order to support this process, a system has been developed starting from the TANGOW system [5] and including functionality

194

R.M. Carro et al.

for supporting collaboration among users [2]. This new system interprets the course descriptions, triggers the corresponding rules and generates the pages to be presented to the students dynamically, step by step, by selecting the most appropriate course components (tasks, contents, problems, collaborative tools, etc.) depending on the student’s features, preferences and actions during the course execution. It stores all the actions performed by the students and uses them to adapt the course in the following steps. The whole process is illustrated in Fig. 1 and is explained next.

Student Features & Actions Grouping Rules

Course-Structure Rules

Pagination. Theory Tasks

ì Group 1

Individual Tasks

Collaborative Tasks

Features

Group 2

Group 3

Features

Features

Groups

Available Tasks

Collaborative-Workspace Rules Problem Statements

Pattern

Subgrouping Rules Collaboration Tools

Content Fragments

History of Previous Groupings

ó

Individual Pages Generated

Collaborative-Tool Rules

ö Subgroup 1 (group1)

Group 2

Group 3

Task C1 - Statement 1

Task C1 - Statement 1

Task C1 - Statement 2

Collaborative Workspaces Generated

Fig. 1. Dynamic Generation of Adaptive Collaborative Web-Based Courses

Dynamic Generation of Adaptive Web-Based Collaborative Courses

195

When a student starts taking a course, the course-structure rules are analyzed in order to select one that describes the decomposition of the main task of the course, and whose activation conditions are satisfied by the student. The rule is triggered, and, depending on the rule sequencing-mode and the subtask prerequisites (if any), all the subtasks, only some of them, or a single task are made available to the student. During the course execution, the most suitable tasks for the student to perform are selected in a similar way at every step, by taking into account the course-structure rules and the student’s features and previous achievements (see in Fig.1). The next step concerns the generation of the page to be presented to the student. Depending on the number of available tasks, the student is presented with a selection menu or with a page of contents. In the first case, the menu is built starting from the tasks descriptions. In the second case, if the task is not collaborative, the system selects the most suitable content fragments to build the page. These fragments are selected among the set of fragment variants associated to the task, by comparing the student’s features with the ones each variant is intended for. In addition, an annotated table of contents is generated, so that the students can know which tasks are (not) available at each time and which ones they have already performed. A progress bar and a button bar are also generated. If a common pattern has been provided, it is used to generate the page (ó in Fig. 1). When the student is ready to perform a collaborative task (the task is included in the set of available tasks), the system checks if it is possible for him to collaborate with other students. The first step concerns the group formation. Groups are formed, at a first stage (ì in Fig. 1), by taking into account the user’s personal features and preferences (including aspects such as the learning style and background, among others) and their interaction style (such as the frequency of interactions with the course). In a second stage, for each collaboration task, as soon as it is available to more than one user belonging to the same group, subgroups start to be formed, so that users can initiate the cooperation. During this phase, their opinions and preferences based on previous collaboration experiences are also considered (i.e., other users they do not wish to interact with again). The teacher could specify different criteria for subgroup forming, such as mixing novice and advanced users, or active with passive ones, if desired. Default grouping rules can also be specified (i.e., the maximum size of a group). Once a subgroup is formed, its members’ features constitute the group profile, which will be enriched with other attributes concerning the users’ interactions. When a subgroup is ready to perform a collaborative task, the corresponding students are informed (the link to this task is activated). The collaborative workspace is build as soon as one of the students starts performing the task. Firstly, the collaborative-workspace rules that describe the potential workspaces to support the execution of the task are evaluated. The one whose activation conditions are satisfied by the students in the subgroup is triggered, and the most suitable problem and set of tools for the subgroup are selected. Secondly, the collaborative-tool rules are evaluated and the corresponding one is triggered to get information about the collaborative tools that will be used to support the students working on the task and also about their layout. Finally, the page is built by joining the problem statement, the set of tools described above, the access to the additional tools and other supplementary tools, such as a buddy list, in an integrated interface (ö in Fig. 1). If several partners are interacting at the same time, it is possible to enable the access to synchronous tools. The students in a subgroup can organize themselves for the task execution: they can divide the task, provide partial solutions, discuss and join them in a complete one; they can

196

R.M. Carro et al.

solve the problem altogether; or they can provide complete independent solutions to be discussed until they agree the best one. Their actions are stored to get information about the task execution. If we want to analyze not only when and who used a tool or provided a solution, but also the meaning of their interactions with the different tools, it is necessary to add semantic information, which we are currently considering. During the whole learning process, the student progress while interacting with the course individually is considered not only with individual adaptation purposes but also to decide about collaborative aspects such as the presence or absence of collaborative tasks or the group formation, among others. The subgroup actions while performing collaborative tasks can also affect the remaining course evolution, both for each of its members while working alone and for the subgroup in subsequent interactions. The actions performed by students and subgroups, such as the pages visited, the exercises done (individually and collaboratively), the contributions to collaborative tasks and the obtained results, among others, are stored to be used with adaptation purposes during the course execution.

4 Discussion The use of the approach presented allows the creation of Web-based courses in which adaptation and collaboration are seamlessly integrated. In these courses, it is possible to adapt not only the presentation of a course to individual students but also the collaboration issues, by considering each student’s personal features, preferences, behaviors and achievements. Starting from a unique course description provided by the course designers, personalized courses are dynamically generated by including and/or removing components or groups of components, and by setting their sorting and compulsoriness. Concerning the adaptation of collaboration aspects, different students can be presented with the same collaborative task at different times. The requirements for a task to be available can be different depending on the student taking the course. Furthermore, collaborative tasks can be proposed only to certain type of students. For each collaborative task, the specific problem to be solved can be selected for each particular subgroup, among those related to the task. It can also be different for distinct subgroups, although related to the same task. For example, it is possible to consider the difficulty of the problems associated to a task, to select the most suitable one for a group of students, according to the knowledge they have acquired previously. The selection of the problem statement depends on the problem characteristics and on the group features and achievements while learning the involved subjects. The tools to support the interactions among students while working on a collaborative task can be dependant on the specific problem to be solved and can also be adapted to the features of each group, even if solving the same problem. The main goal is to create collaborative workspaces in which each group can feel comfortable. The only requirement to exploit these adaptation capabilities is to define the corresponding course-structure rules, collaborative-workspace rules and, optionally, collaborative-tool rules, indicating the types of users each rule is intended for. An advantage of this approach is that the teacher does not need to define/create specific workspaces for each collaborative task. In the simplest case, he only needs to provide the problem statements and select among the workspace configurations offered by

Dynamic Generation of Adaptive Web-Based Collaborative Courses

197

default. In this case, when a given task requires the utilization of specific tools, the workspace configuration can be specified for this particular task. The separation of course contents, structure, problem statements and collaborative tools facilitate the reuse and maintenance of components. It is easy to add, remove or modify a collaborative task, a set of tools to be used in a workspace or a problem to be solved collaboratively. In the same way, collaborative tasks can be easily moved from one point of the course to another, and prerequisites for a task to be proposed can be simply changed. It is also easy to modify a course according to new needs detected. In general, new adaptation requirements can be implemented adding or modifying rules. Courses are dynamically generated at runtime. Therefore, when a change is made, the consequences are reflected in the course, being unnecessary to check for possible inconsistencies (course descriptions are checked at design time). Concerning the student grouping, the dynamic formation of groups offers the possibility of grouping students which are ready to perform certain tasks, avoiding situations in which a student is waiting for the others to learn the required topics to solve the problem. However, integrating adaptation and collaboration is not an easy task. On the one hand, adaptation is oriented, a priori, to the personalization of courses to individual students, focusing on their personal features, so that they can learn at their own pace. On the other hand, collaboration must be addressed from both the cognitive perspective and the social perspective. The users are required to acquire a compromise with their partners, and it is important for each member to feel comfortable with the others to take advantage of the experience. Therefore, it is necessary to use proper criteria to manage the social aspects of the collaboration and to support the whole experience. Many decisions concerning the user grouping depend on the context in which an adaptive collaborative course is used. For example, if it is widely offered for long-life learning, it is probable for the students to be very different. Moreover, they may connect to the courses at completely different moments. Even it is possible for some users to access to the course only with consultation purposes. On the contrary, if the course is used as an additional support to traditional classes, it is very probable that the users take the whole course in a delimited time frame. The number of students participating in a course and the course duration may also determine collaboration issues such as the need of establishing deadlines for collaborative task resolution or the minimum/maximum number of students for each group. The context must also be considered in order to take decisions about the way of solving or avoiding undesirable situations such as: students waiting too long for their partners to participate (When should the system send a warning to the students? What is “too long” in each context?), students waiting too long to be grouped (How long should they wait, as maximum? Should they be incorporated to recently formed groups? Should new groups be formed with several of these students, although the new groups do not satisfy all the criteria for student grouping?), students whose partners have left the course (Should they wait for other students to be ready to join them? If yes, how long? It is better for them to join recently formed groups?). In order to satisfy the users’ needs while interacting with others in different contexts it would be convenient to implement a mechanism for changing the criteria used for student grouping dynamically, depending on the context in which the adaptive course is used. In order to get the best answers to all these questions and the best criteria for adaptive group formation depending on the context, it is necessary for us to experiment with adaptive collaborative courses with different real students in different contexts.

198

R.M. Carro et al.

5 Future Work As it has been concluded in the previous section, this approach needs to be tested with real students in order to get feedback about the effectiveness of integrating adaptation and collaboration in different contexts, and also about the criteria to be used to adapt collaboration aspects such as the student grouping or the solutions to undesired situations. We will create new adaptive collaborative courses and design the corresponding experiments. These experiments could also provide us information about how students work and learn [7], especially if we include semantic information to support the internal analysis of the student interactions, which we are considering. We are developing an authoring tool to support the description of adaptive collaborative courses and we plan to develop a monitoring tool for the teachers to get information about the course evolution, including individual and collaborative aspects.

References 1. Barros, B., Verdejo, M.F.: Designing Workspaces to support collaborative learning. In: Pobil, A.P., Mira, J., Moonis, A. (eds.): Tasks and Methods in Applied Artificial Intelligence. LNAI, Vol. 1416. Springer-Verlag (1998) 668–677 2. Borghoff, U., Schlichter, J.: Computer-Supported Cooperative Work – Introduction to Distributed Applications. Springer (2000) 3. Brusilovsky, P. Adaptive hypermedia. User Modeling and User-Adapted Interaction, 11 (2001) Kluwer Academic Publishers, 87–110. 4. Carro, R.M., Ortigosa, A., Schlichter, J.: A Rule-based Formalism for Describing Collaborative Adaptive Courses. In: Palade, V., Howlett, R., Jai, L. (eds.): KES 2003. LNCS/LNAI. Springer-Verlag (2003). In press. 5. Carro, R.M., Pulido, E., Rodríguez, P.: Dynamic generation of adaptive Internet-based courses. In: Journal of Network and Computer Applications 22 (1999) Academic Press, 249–257 6. Dillembourg, P. Collaborative learning: cognitive and computational approaches. Elsevier, Oxford, 1999 7. Muehlenbrock, M., Hoppe, U.: Computer supported interaction analysis of group problem solving. In: Proceedings of the Computer Support for Collaborative Learning (CSCL) Conference. Palo Alto. Stanford University (1999) 398–405 8. Schlichter, J. Lecture 2000: More than a course across wires. Teleconference – The Business Communications Magazine (1997) 18–21 9. Suthers, D., Xu J.: Kukakuka: An Online Environment for Artifact-Centered Discourse. Education Track of the Eleventh World Wide Web Conference. Honolulu (2002) 472–480 10. Vizcaíno, A., Contreras, J., Favela, J., Prieto, M.: An Adaptive, Collaborative Environment to Develop Good Habits in Programming. In: Gauthier, G., Frasson, C., VanLehn, K. (eds.): Intelligent Tutoring Systems 2000. LNCS 1839. Springer (2000) 262–271

Collaborative Authoring, Use, and Reuse of Learning Material in a Computer-Integrated Classroom Nelson Baloian, José A. Pino, and Olivier Motelet Universidad de Chile, Departamento de Ciencias de la Computacion Blanco Encalada 2120, Santiago, Chile {nbaloian,jpino,omotelet}@dcc.uchile.cl

Abstract. Reuse of computer based learning material is a key requirement for any practical approach to support adaptive and dynamic teaching/learning inside and outside the classroom. Unlike hardware technology innovations, the software support for reuse inside the classroom is still not satisfactory. We present an approach to reuse material based in the Computer-integrated Classroom (CiC) environment and a special type of active documents used for containing learning material defined by the user to fit the particular needs of a lecture. This approach allows collaboration at two levels. The first one involves learning unit authors, who can jointly develop a course and teach it independently. The second level of collaboration refers to teacher and students exchanging and sharing documents. This framework does not impose a certain teaching/learning style. It rather supports the seamless transition from one teaching/learning mode to another one, using the same material.

1 Introduction There has been much work done to support the creation and management of multimedia-based learning material and courses for e-learning (see [10] for a sampling). However, most of it is intended to be used only in a distance-learning scenario. Despite this, many current teaching/learning activities still take place inside the classroom. Also, the new tendencies are to redefine the role of the teacher as someone who catalyzes and moderates collaborative learning activities or someone who manages distributed activities and a variety of (learning) resources. We conceive a face-to-face lecture supported by computer technology as a succession of various teaching and learning activities like presentations by the teacher, individual or collaborative problem solving, discussion, etc., where computers and computer-based learning material play a key role enriching and supporting these activities [9]. Computer technology should support each activity with the proper tool and learning material. However, the costs of producing good quality computer-based learning material are frequently high and their range of use limited. For these reasons, many authors have pointed out the convenience of reusing already existing learning material for other teaching/learning contexts. The works of [14,4] and initiatives like LOM [18] are directed to achieve this goal. In this work we present a framework for supporting teachers in the collaborative authoring of a learning unit. On a second phase, it supports the flexible and collaboJ. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 199–207, 2003. © Springer-Verlag Berlin Heidelberg 2003

200

N. Baloian, J.A. Pino, and O. Motelet

rative use of this material in a Computer-integrated Classroom, considering the different backgrounds the students may have, preferred teaching/learning style of teacher and students. By creating a learning unit we mean here selecting and sequencing some learning materials for a defined learning goal in such a way it can be adapted to a particular case of teaching/learning situation [8]. The structure of the learning unit syllabus plays a key role for achieving this goal [11]. The final users of this system are the teachers. It is designed to facilitate the management of the learning material (retrieval, distribution, share, and collection) supporting the seamless transition from one learning activity type to another. For example, the teacher may present a document previously stored in the repository of the lecture or create it on an electronic blackboard. Then, she can distribute it to the students and ask them to modify or complete it in an individual or group working session. Then, she can collect the results and present them on the e-board. Another teacher may prefer to collaboratively solve the problem with the whole class by sharing the same document. This framework allows to maintain the dynamics of the lecture by supporting all these actions with a minimum of required steps. In a first part this article relates the framework to the existing approaches. Then it describes the tools that implement our ideas in the context of the CiC. Finally, it discusses their collaboration and reuse properties through the particular example of a current Java programming course at our university.

2 Related Work Numerous electronic supports for the teacher’s task are studied in the field of distance e-learning. However our work goes out of the scope of distance learning since it deals with the face-to-face classroom situation. In this context the requirements are different and involve some visualization and usage issues. Making a lesson for both distant and face-to-face electronic learning environments involves management, distribution, and collection of didactic activities. Syberwork [15], LearnITy [16] or WebCT [17] provide administration support for those tasks. Moreover, those tools enable the cooperative building of the lesson with asynchronous or synchronous facilities. LearnITy offers indeed the possibility of predefining some strategies that could distinguish the author’s personality or adapt to different student levels or learning habits. In a face-to-face context, we pretend to enable dynamic adaptation of the lessons structure depending on direct feedback from the students. In a distant learning context, building lessons structure and strategies is done before the actual learning period. Then, the student himself chooses the structure he thinks is best suited to his level. He could sometimes be assisted in his choice by an expert system computing the results of tests he previously fulfilled. By contrast, in an interactive lesson, the teacher should do this choice herself based on the analysis of the reactions and feedback from the students. The existing face-to-face learning environments like Hypercourseware [12], and E-Class [1] focus on supporting the teacher through distribution and collection of activities, on monitoring the lesson status or capturing the teacher live-contribution on the activities. Nevertheless, they do not aim to let the teacher dynamically adapt the lesson to the audience.

Collaborative Authoring, Use, and Reuse of Learning Material

201

Adapting the lesson dynamically assumes the teacher has previously built a non deterministic graph of activities from which to extract the actual structure of the course. A teacher support should allow her to build, organize and use this graph during lesson delivery. Concept maps [13] are web diagrams where ideas or concepts are visually related in an intuitively organized, non-deterministic structure. They present an interesting principle of organizing ideas in a visual and inductive manner. Each node maps one concept. However, in our case, we want to map activities that not necessarily match the scope of one specific concept. On the same visual principles, web cartographers like Nestor [7] and Webmap [6] allow to reference, position and link web documents for enabling easy and traced navigation. Those tools offer relevant visualization and collaborative building facilities but do not provide support for didactic activities.

3 Using Active Documents in a Computer-Integrated Classroom A Computer-integrated classroom (CiC) [3] defines a hardware environment and a specially designed software system trying to integrate computers into the everyday classroom rather than to use laboratories. The CiC system has been designed considering the room will generally be equipped with an electronic blackboard being operated by the teacher to present, create and/or manipulate learning material. Additionally, the teacher and some or all of the students have personal computers or PDAs, which are connected to the system via a network. A server acts as a repository for the learning material and administrative information. This system provides tools to enable teacher and students to retrieve, save, exchange, (asynchronously) distribute, and (synchronously) share documents of any type in a classroom setting. 3.1

Learning Material as Freestyler Active Documents

Freestlyler [9b] was incorporated to the CiC environment as a visual tool for generating, presenting and manipulating learning material. It manages and displays both

Fig. 1. A FreeStyler document using the Java Palette

202

N. Baloian, J.A. Pino, and O. Motelet

visual objects and handwriting add-on in a layered manner. It benefits from the CiC support and enables synchronous collaborative work on shared documents. A powerful feature of Freestyler is its usage of ad-hoc pluggable modules called palettes to define new functionalities. Each palette contains a domain-oriented visual object that can be placed in the documents. For instance, a palette for supporting the teaching and learning of programming with Java provides some specific objects: java code, program input, program output. By linking them, they become dependant. They accept also some specific actions like compile, edit, and execute (Fig 1). 3.2

Creating the Syllabus of a Learning Unit with Freestyler

As presented above, Freestyler is used to create, present and manipulate learning material. We extended it to define the structure and contents of a learning unit. This version is called SurfStyler.

Fig. 2. A lesson built with Surfstyler

Collaborative Authoring, Use, and Reuse of Learning Material

203

McCalla [11] presents a number of self-adapting tutoring systems for supporting individual learners and he considers the graph as a key structure for the learning unit syllabus in order to achieve flexibility. This is because a graph allows more that one way to sequence concepts while maintaining a coherent order between predecessor and successor nodes. This structure is better than considering a syllabus as a sequential list of concepts to be taught. Baloian et al. [2] present a graph structure for representing the syllabus of a learning unit with the aim of having several versions of a lecture according to different teaching styles, length and/or depth of the course. This was achieved by including a special palette and adding other functions to Freestyler. Fig. 2 shows a lesson graph built with Surfstyler. Each node references one didactic material. Dragging the material in Surfstyler creates the node. Double clicking on the node opens this material. Because of their features, we use mainly FreeStyler active documents as learning material. However, Surfstyler accepts any type of material that can be opened by local applications installed on the operating system like Slide show, Web browser, Media player. Following Colazzo & Molinari’s suggestion in order not to increase the students' disorientation while using educational software [5], the use of Surfstyler should be limited to the teacher. It allows the teacher to decide which materials to display on the electronic board and which documents or collaborative tasks to distribute to the students. 3.3

Legends in Surfstyler

Surfstyler provides a way to specify its contents to provide a consistent navigation and use of didactic material. First, each node is described with some keywords. Second, a legend is attached to the graph. Legends give meaning to colors and shapes of the nodes and colors of the arrows in a way similar to legends used in cartography. Each node has an array of 2-tuples that associates both colors and shapes with legends. Similarly, each edge has an array of 2-tuples that associates colors with legends. Therefore, when the user loads a legend, the graph takes the pre-specified appearance for this legend. The legends are XML files built with Surfstyler. The teacher herself can design and customize the legend for the specific purpose of the lesson. She can also share it and let it be improved by other teachers. 3.4

Didactic Legends and Didactic Networks

We designed a legend for didactic purpose, the Didactic Legend, aware of the fact that the different teachers’ experiences and personalities will make it evolve. The Didactic Legend specifies the type of didactic activities with the color of the nodes and the type of documents with the shape. For the arrows, we implement the concept of Didactic Networks [2] and specify their color as different rhetoric relations between material types: introduced by example to, introduces to, explained by, exemplified by, refined by, summarized by (Fig. 2). This type of relations can help to define specific teaching strategies as inductive learning, deductive learning, or “short version” of the lesson. For instance, an inductive learning strategy means that examples and facts will induce the understanding of general rules and laws. This is why in such a learning mode the examples have higher priority than the explanations. It implies the links explained by, refined by will more likely be used instead of the explained by

204

N. Baloian, J.A. Pino, and O. Motelet

or introduced by example to links. We compute this notion by attributing different weights to the meaning given to the arrows. The weights are recorded as filters defined in the legend and applied to the arrow appearance.

4 Collaboration and Reuse in the CiC Environment Teachers can benefit from sharing the learning material and the syllabus of the learning unit, but they must be able to adapt it to their preferred teaching styles or they can select appropriate examples or explanations during the lectures according to the students needs and feedback. Thus, the system does not impose a certain teaching/ learning style or activity. It rather gives teachers and students the opportunity to choose the learning activity they prefer to use at any time, enabling the use of the existing learning material, the creation of new one, and the support of a seamless transition between the different activities. We will explain how the system does it. 4.1

Collaboration and Reuse during the Authoring Phase

In order to support collaboration during the authoring phase, teachers should be able to easily add, delete and/or modify elements without having to alter much of the original structure. The system should also support versioning and annotation as well as different roles like principal author, consumer, reviewer or coordinator (e.g., in the context of having a common learning material repository for the whole organization). In our system, the syllabus of a lecture is created as a Surfstyler document using the didactic legend. It allows also the annotation of the changes being introduced by the different authors and the automatic versioning of a document. Surfstyler offers the granting and taking of read/write permissions, which allows the definition of various roles in this process. Reuse of learning material is strongly supported by the graph structure because the contents of a certain node (learning material) can be borrowed from the node of another learning unit. Asynchronous collaboration work during authoring is enabled by the CiC repository and the Surfstyler versioning feature. Synchronous collaboration is achieved because Surfstyler allows the co-editing of a single document in real time. 4.2

Collaborative Use during a Lesson

We want to enable teachers to decide when, how, and with which material they prefer to perform presentations, individual or collaborative problem solving sessions, discussions, etc. The system should support the teacher to perform these activities using the prepared learning material or developing new one during the lecture and especially, to allow seamless transitions between collaborative and non-collaborative activities using the same material. To support this we first tried to identify the most recurrent management activities performed by teachers with the learning material in a CiC environment and try to automate it. Figure 3 shows the teacher’s tool for administrating the learning material. In the snapshot the teacher is selecting files and students for sending/sharing learning material. We can classify actions in two groups:

Collaborative Authoring, Use, and Reuse of Learning Material

205

Distributing/Gathering Documents. During a classroom session the teacher can distribute and gather documents of any type to and from the students. Documents can be located in the Document Manager or in a local directory, either at the teacher’s electronic blackboard or on the students’ computers. Sharing Documents. By sharing a document we understand many people viewing and modifying the same document at the same time. This can be used when the teacher asks a student to present his work to the rest of the class. Allowing other students or the teacher to use the document being shown and adding notes and drawings can support useful contextual discussions.

5 Discussion This paper presents Surfstyler, a tool for lesson-management in the CiC. It enables synchronous and asynchronous co-authoring, share and reuse of learning material, seamless distribution and collection of collaborative or non-collaborative learning activities and dynamic adaptation of the course based on direct evaluation of students’ feedback.

Fig. 3. The teacher’s CiC administration tool

CiC, Freestyler and SurfStyler are all written in Java and take benefits of its multiplatform portability. The data level is also portable in the sense that the lesson graphs built with Surfstyler, as any Freestyler documents, are stored as XML files. As we already discussed, a system of customizable legends enables the flexibility of Surfstyler. Those legends can be adapted to the application domain, the culture of the users or/and the specific needs of a lesson. They are independent modules stored in XML files and can be reused with any other lesson graph. While most research in the fields of e-learning and computer-supported classrooms mainly focus on lesson scheduling and monitoring or lesson capturing, our approach deals mainly with the issue of supporting adaptable teaching in the classroom. At a practical level, we claim the adaptability of the course is a factor that depends on the

206

N. Baloian, J.A. Pino, and O. Motelet

granularity and diversity of the materials. The other key factor is the structuring of the material in a graph form. The fact is that educational institutions will continue accumulating teaching material. Some of it will become obsolete, the rest will continue to be useful. A tool such as Surfstyler will allow to profit from this collection, since it makes possible to incorporate portions of it in several courses and in different ways. We have used SurfStyler and CiC in a real case involving a course on Java programming, lectured in two occasions. Two teachers have used these new tools incorporating previous material they had. Before this experience, they had used a Web browser, MS Powerpoint, and Studio One (Java Programming Environment) with the same hardware. A total of 43 students have followed these courses and the new environment was used in a total of 10 sessions. The first informal evaluations are positive, showing added value to the tools use. We expect to have more results soon on usability and worth of the approach. Of course, further studies and experiments on the visualization and navigation aspects in the graph of the lesson syllabus are definitely required.

References 1. Abwod, G. Classroom2000: An Experiment with the Instrumentation of a Living Educational Environment. IBM Systems Journal, Special issue on Pervasive Computing, vol. 38, Nr. 4, pp. 508–530, October 1999 2. Baloian, N., Pino, J.A., Hoppe, H.U. Intelligent Navigation Support for Lecturing in An Electronic Classroom. In: Artificial Intelligence in Education, Lajoie and Vivet (Eds) IOS Press, 1999, Amsterdam, pp. 606–610 3. Baloian, N. Berges, A. Buschmann, S. Gassner, K. Hardings, J. Hoppe, H.U. Luther, W. Document Management in a Computer-Integrated Classroom. In Haake & Pino (Eds): Groupware: Design, Implementation and Use. LNCS 2440, pp. 35–44, 2002 4. Brown, A., Short, K. On Components and Objects: Foundations of Component-Based th Development. Proceedings of the 5 International Symposium on Assessment of Software Tools. IEEE Computer Society Press. Jun. 1997 5. Colazzo, L. & Molinari. To see or not to see: tools for teaching with hypertext slides. Proceedings of the ED-Media 95. Graz, Austria; June 17–21, 1995. pp. 157–162. 6. Domel, P. (1994). WebMap – A Graphical Hypertext Navigation Tool. Proceedings of Second International WWW Conference, 1994 7. Eklund J, Sawers J & Zeiliger R NESTOR Navigator: A tool for the collaborative construction of knowledge through constructive navigation. In R. Debreceny & A. Ellis (eds.) proceedings of Ausweb99, Southern Cross University Press, Lismore. 1999 8. Halff, H.M. Curriculum and instruction in automated tutors. In: Polson, M.C.; Richardson, J.J. (eds.). Foundations of Intelligent Tutoring Systems. Hillsdale NJ: Lawrence Erlbaum 9. Hoppe, H.U.; Baloian, N.: Zhao, J.; Computer support for teacher-centered classroom interaction. Proceedings of the International Conf. on Computers in Education. Taipei (Taiwan), Dec. 1993. pp. 211–217 9b. Hoppe, H.U., Gaßner, K.: Integrating Collaborative Concept Mapping Tools with Group Memory and Retrieval Functions. In: Stahl, G. (eds.): Computer support for collaborative learning: Foundations for a CSCL Community. Lawrence Erlbaum, Hillsdale, New Jersey, USA (2002) 716–725 10. Landon, B. OnLine Educational Delivery Applications: A Web Tool for Comparative Analysis. Standing Commitee on Educational Technology; Center for Curriculum, Transfer and Technology. URL: http://www.ctt.bc.ca/landonline/

Collaborative Authoring, Use, and Reuse of Learning Material

207

11. McCalla, G. The search for adaptability, flexibility, and individualization: approaches to curriculum in intelligent tutoring systems. In: Jones, M.; Winnie, P. (eds.). Adptative Learning Environments. Springer-Verlag, NATO ASI Series. 1992 pp. 123–143. 12. Norman, K.: Hypercourseware for assisting teachers in the interactive electronic classroom. In: J. Willis, B. Robin, & D. A. Willis (eds.): Proceedings of Fifth Annual Conference of the Society for Technology and Teacher Education, Washington, D.C., USA, 1994 pp. 473–477 13. Novak, J. Learning, Creating, and Using Knowledge: Concept Maps As Facilitative Tools in Schools and Corporations. Lawrence Erlbaum Assoc. 1998. 14. Roschelle, J., DiGiano, C., Koutlis, M., Repenning, A., Jackiw, N., Suthers, D. (). Developing Educational Software Components. Computer, Vol.32, Nº 9, 1999 pp. 50–58. 15. Syberworks: e-learning course authoring http://www.syberworks.com/product_SA.htm 16. LearnITy™, Aunwesha integrated suite, e-learning suite: http://www.anuesha.com 17. Webct, e-learning suite: http://www.webct.com 18. IEEE P1484.12: Learning Object Metadata Working Group. Draft Standard for Learning Object Metadata. An unapproved draft of a proposed IEEE Standard, 2000. (http://ltsc.ieee.org/wg12/)

Supporting Collaborative Drawing with the Mask Versioning Mechanism 1 2 3, Alexandre Pereira Meire , Marcos R. S. Borges , and Renata Mendes de Araújo *

1

Mestrado em Informática – Núcleo de Computação Eletrônica and Instituto de Matemática/UFRJ [email protected] 2 Núcleo de Computação Eletrônica and Instituto de Matemática/UFRJ [email protected] 3

Escola de Informática Aplicada - UNIRIO [email protected]

Abstract. This work presents a synchronous collaborative graphical editor that implements a proposal of an awareness mechanism of a collaborative artifact evolution. The graphical editor allows real-time, highly interactive collaborative work, using the mask metaphor to help participants in creating new diagram versions without interrupting the interaction as also to provide awareness of the diagram versions created. This paper describes the mask metaphor, the collaborative editor that implements this metaphor and discusses a case study conducted with the use of the tool.

1

Introduction

Collaborative editors aim at providing communication channels, coordination and awareness functionalities for helping participants in recognizing the action of others in the artifact being built. In only one work session, this artifact passes through many stages or versions representing the steps taken for its construction. Basically, a workspace is shared where the artifact under construction is disposed. Each participant can act on the artifact, changing it according to his need or following any coordination protocol. This work focuses on the issue of artifact evolution. The construction of collaborative work artifacts – especially diagrams – are burdened by the absence of mechanisms that help participants to discuss different alternatives, to make decisions and to follow the evolution of the artifact being built. Some proposals address this issue providing functionalities for changing and version control but few of them help participants to generate parallel alternatives of the same diagram and to discuss, compare and evaluate the content of each version in order to take specific decisions.

*

also collaborating at IM/NCE - UFRJ.

J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 208–223, 2003. © Springer-Verlag Berlin Heidelberg 2003

Supporting Collaborative Drawing with the Mask Versioning Mechanism

209

It is argued that a collaborative editor can provide a set of functionalities aiming at: a) representing participants’ consensus over the whole diagram or part of it; b) allowing parallel work and discussions by subgroups analyzing new alternatives that can be merged on the common product; c) helping participants to reach consensus and viewpoint convergence based on the alternatives outlined throughout the editing interaction. This paper presents the proposal of such collaborative editor – CO2DE –, which aims at achieving the objectives outlined above. The concept underlying CO2DE functionalities is the mask metaphor. This concept implements a versioning mechanism for collaborative graphic editing where changes on the artifact can be created independently or not from the overall work, the change context can be identified, and, finally, the participant can discuss and make decisions about those changes. The paper is structured as follows: Section 2 addresses some issues for being aware of changes in collaborative editors. Section 3 depicts the CO2DE editor functionalities. Section 4 describes case studies conducted to evaluate the use of CO2DE. Finally, conclusions are presented in Section 5.

2

Awareness and Discussion of Changes in Collaborative Editors

Text editors are the most popular software tools used in organizations. Products like Microsoft Word or similar offer functionalities for collaborative reviews such as: the creation of annotations in the text, the assignment of colors for modifications made by each author and different text styles to show participants that a review was introduced in the text - for instance, the removed text is stroked through and new text is underlined. However, since each author can only make each modification on his turn, a coordination process or a work protocol must be defined among authors in order to review the text being constructed. 2.1

Knowing What Is Going On

In collaborative editing tools, mechanisms adapted from single-user text editors provide useful awareness information for the group. Telepointers, multi-user scrolling bars and fisheye viewers are examples of awareness mechanisms aimed at showing participants’ position in the collaborative text [1]. Collaborative graphical editors also provide shared workspaces where authors share the same drawing or diagram and the modifications are broadcasted to each participant individual view. Graphical Fisheye Views [2] is an example of awareness mechanism for helping co-authors in focusing on detailed portions of the workspace and being aware of what are the others’ position and focus. Radar Views is another awareness mechanism that shows a minimized view of a diagram. On this view it is delineated each user’s working area at that specific moment [3]. Whatever is the awareness mechanism provided by a collaborative editor, its main objective is to offer what is called feed through [4] – any change in the shared objects at the workspace must be remotely reflected to other users. As much important as the possibility to reflect changes, is the possibility of retrieving the sequence of actions taken by the group over the shared text or diagram.

210

A. Pereira Meire, M.R.S. Borges, and R. Mendes de Araújo

The possibility of being aware of the versions an object passed through is important information for helping authors to understand the obtained results and to continue their interaction. The Stick-Ons [5] can be considered as a proposal of an awareness mechanism for text versioning in a collaborative editor. The Stick-Ons are based on the adhesive tape metaphor. To substitute a part of the text, the reviewer “glues” a stick-on over it and fills it with a new text. Lately, if any reviewer wants to know what the original text was, he can remove the stick-on and see what is behind it. While doing that, the original text is presented with a shadowed texture, as if pieces of glue have remained over it after the stick-on had been removed. A text being reviewed by a group is presented in Figure 1. The various parts of the text with different background color scales represents texts that were replaced by authors by gluing stick-ons and writing on them.

Fig. 1. Stick-Ons [5]

Tam et. al [6] present an evaluation of a set of awareness mechanism for representing changes on artifacts, what is called Change Awareness. Figure 2 shows how the effects of change in a diagram can be expressed. Changes in positions are represented by shadows; strong colors indicate that the artifact suffered a great number of changes. Other mechanisms show the nature of the change (modification or movement).

Supporting Collaborative Drawing with the Mask Versioning Mechanism

211

Fig. 2. Change awareness [6]

2.2

Discussion and Convergence of Viewpoints

During a collaborative editing session, participants have the opportunity to add their contributions simultaneously in order to build the final product. Being aware of each contribution usually leads to discussion, to the need of clarifying viewpoints as also to the generation of new ideas. Santoro, Borges and Pino address such issues in the CEPE cooperative editor [7]. This tool supports process elicitation and modeling, providing features for participants to discuss the problems and to add comments, like in a “brainstorming” session. Its communication facilities allow participants to exchange messages, referring to an element in the diagram. Opinions and ideas can be attached to the elements, using a set of icons to distinguish comments, suggestions, inquiries, mistakes and a scratchpad for discussion. Awareness capabilities are also available using colors, telepointers and multi-user scrollbars. 2.3

Working in Parallel

As mentioned above, by being aware of each participant contribution and the discussions conducted within the context of an editing session, participants may be caught by new ideas that should be explored as a relevant alternative for bringing quality to the collaborative artifact. However, the functionalities available in synchronous collaborative editors, for instance, usually force participants to contribute each one on its turn and the entire group must be focused on his idea in order to discuss it. In asynchronous interaction, on their turn, participants express their ideas to be known by others but it is often difficult to report the editing context where the idea took place. Additionally, concurrent manipulation of shared objects often leads to conflict situations. Usually, conflicts are considered as an undesirable situation. However, it is

212

A. Pereira Meire, M.R.S. Borges, and R. Mendes de Araújo

possible to understand a conflict as an opportunity for interaction since at least two participants are interested in the same portion of the collaborative artifact [8]. Instead of avoiding or controlling conflict through blocking mechanisms, what about allowing each participant to build their own version or alternative of the shared artifact and supporting them in negotiating their viewpoints? For these situations, it should be interesting if the collaborative editor offers functionalities to support independent and parallel sub-group work. Each sub-group could work on a different piece of the shared workspace without bothering the main discussion. Meanwhile, the discussions conducted by this sub-group could also be registered and, if acceptable, even incorporated to the main collaborative artifact.

3

CO2DE

This work discusses the idea of providing mechanisms to collaborative editors that aims at promoting parallel work, treating conflict as opportunities for new ideas and providing memory about the versions of the artifact being built. A collaborative drawing tool was developed, supporting the creation of UML diagrams. The editor is called “CO2DE”, a reduction for the term “Collaborate to Design”, mentioning the collaborative activities of a group to design a diagram [9]. CO2DE provides functionalities for marking the versions of the diagram being constructed using the concept of masks. Some group facilities are offered to provide awareness of others’ activities, communication and coordination in order to support both synchronous and asynchronous interactions. By providing functionalities to deal with the mask concept, CO2DE supports participants in its collective knowledge building about the artifact being constructed: it is a way for brainstorming and representing multiple viewpoints; and it supports the comparison, discussion, combination and convergence of these different viewpoints. 3.1

The Mask Metaphor

The mask concept [9] allows representation of multiple versions of a diagram designed in collaborative session. This concept is based on the presentation slide metaphor. Once a version of the diagram is developed, a new version can be built, by putting a slide upon it and drawing on its surface like a mask. The new mask may contain new symbols and changes to the symbols of the previous version. Removing the mask shows the contents of the subjacent diagram version. The process of constructing a diagram may consist of a sequence of versions or masks, each one representing one stage in the evolution of drawing process. Each mask is considered the child of its predecessor. To keep consistency, a mask cannot be modified if another one was generated from it – we say that the mask is closed or frozen. Also, a mask can evolve into two or more alternatives, when the alternatives are built upon the same original mask. This way, the collection of all masks created during a drawing session can be organized as a tree, each node reflecting one version or mask (Fig. 3). This metaphor, applied to collaborative drawing, offers the facility for

Supporting Collaborative Drawing with the Mask Versioning Mechanism

213

a group to distinguish relevant stages in the artifact evolution, as also to explore and evaluate concurrent versions raised during their interaction. The mask metaphor uses the same concept of Stick-Ons to create a diagram version starting from an existing version. Although Stick-Ons are applied in a portion of the document text (a word, phrase or paragraph, for instance) and masks reference the whole artifact (diagram).

Fig. 3. Masks evolve in a tree structure

3.2

Functionalities

User Interface Similar to other editors, the CO2DE functionalities can be accessed through its graphical interface, selecting an option in its menu or tool bar, or using its mouse sensitive drawing panel. The main window consists of three main areas (panels) as shown in Fig. 4. The Drawing Panel is the biggest one, with horizontal and vertical scroll bars, where the diagram can be edited using mouse events in conjunction with menu editing functions. Symbols in the diagram can be created, modified, moved and deleted. It has a WYSIWIS interface, providing work awareness over a shared mask. The Mask Panel is presented in the upper right corner of the window, as a list of masks for the diagram being constructed during the collaborative drawing work. The item selected in the list is the mask currently selected by the user, which is shown in the Drawing Panel. In this panel, users manage the mask hierarchy. This functionality is better explained in section “Versioning”. The User Panel is simply a list of all participants logged in the session, which is continuously updated as new member joins in or leaves. This panel is located in the lower right corner of the window, and is just a static panel – no user action is available on it. Modeling The editing functions available for users are very similar to the ones in a typical graphical editor. There are operations to create a new diagram, to open an existing

214

A. Pereira Meire, M.R.S. Borges, and R. Mendes de Araújo

diagram, and to save the diagram. There are editing operations to insert, modify, move and delete symbols in the diagram. In the CO2DE context, those operations are applied to the mask currently selected by the user, as described further.

Mask Panel

User Panel

Drawing Panel

Fig. 4. CO2DE main window

Collaboration In the user panel, one of the participants is indicated as the coordinator of the session, as seen by the “(Coord)” after his name. The coordinator is the user who first logged into the CO2DE session. If he has a diagram in his drawing panel, this is used as the diagram to be shared during the session. The other users receive this diagram in their drawing panel automatically, as they join the session, with the list of masks built so far. When a participant joins the session later on, he can see through the mask structure how work has evolved. Navigating through this structure, he can be aware of and compare versions. He can analyze the contributions, changes made, alternative proposals, and negotiation between participants, registered in the communication facilities, chat and annotations, presented in the session. CO2DE provides awareness functionalities through a WYSIWIS interface, where all editing operations made by one of the participants are immediately reflected in the others’ shared workspace as shown in Figure 5. This is true for all participants working in the same diagram mask. For participants working in other masks, those operations can only be perceived when they select the corresponding mask, which characterizes a WYSIWID interface (Figure 6). Telepointers are also implemented in the tool, allowing participants to see in which part of the shared workspace other partici-

Supporting Collaborative Drawing with the Mask Versioning Mechanism

215

pants are located. As mentioned above, only telepointers of participants who selected the same mask are shown.

Fig. 5. Two participants working in the same mask (WYSIWIS interface)

Fig. 6. Two participants working in different masks (WYSIWID interface)

216

A. Pereira Meire, M.R.S. Borges, and R. Mendes de Araújo

Versioning Working with diagram versions in CO2DE seems as virtually manipulating presentation slides upon the shared work area. Once connected to a session, the user has one diagram version (mask) drawn in his drawing panel. This mask represents the stage of the diagram since it was first created in the beginning mask, with all modifications in the sequence of masks, until the current one (figure 7). The user may select another available mask, and the diagram is redrawn to show the selected version.

4 3 1 0

Presentation slide metaphor

Mask Tree

Fig. 7. Each mask represents an evolution path

Masks with “children” cannot be modified. Only masks that represent “leaves” in the tree structure are editable. In those ones, the user is allowed to insert, to move, to modify or to delete symbols, on his drawing panel. Every change is instantly reflected in the work area of other users connected to the session, working on the same mask. Each one of these operations is associated to the currently selected mask, being represented in this mask and its successors. The deletion operation of a symbol, in special, is done logically – the symbol is removed from the current mask, but continues to be drawn in its predecessors. This helps capturing its representation thereafter and avoids loosing its context about modifications during the design evolution [8]. To manipulate the mask structure, the user has to use the mask panel and its corresponding operations. Those are operations to manipulate the masks, allowing masks selection, creation, closing, blocking and unblocking. When a participant wants to create a new mask, he must select the mask, which will be the parent of the new one. The new mask will be created as its child. Then, he chooses the operation ‘New Mask’, either in the menu or in the toolbar corresponding button. The creation is only allowed if the parent is closed. Closing a mask is as simplest as selecting it and calling the ‘Close Mask’ operation. There is a restriction here; only the creator of the mask or the coordinator of the session is allowed to close the mask. This operation cannot be undone and, once closed, no more editing operations can be done in this mask. Blocking a mask gives the exclusive editing of the mask to a participant. Other participants can select the

Supporting Collaborative Drawing with the Mask Versioning Mechanism

217

mask, but are prohibited of modifying it. The mouse pointer is changed to a padlock icon when passed upon a symbol by other participants, indicating that editing operations are temporarily unavailable. Later, the exclusive user can unblock the mask, turning it modifiable again. Participants can add annotations using the clip symbol, attached to object symbols or to an area in the diagram. Comments can be inserted in the clip cumulatively, as free text. When opening the clip, the contributions annotated in all masks in this same path are presented in chronological order. This helps to keep track of the context of discussion during the evolution of the editing activity. The Chat function in CO2DE is based in the mask context. Every message sent is associated with the mask currently selected by the sender. The chat window shows only the messages generated in the current mask and its predecessors (Figure 8). With this resource, we try to keep the communication based in the context of the discussion. Users working in the same mask are not annoyed by messages exchanged on other masks.

Fig. 8. Chat in CO2DE

CO2DE allows saving in disk all the work generated during a group session, recovering it a posteriori to be used in another session, or for analytical purposes. All contributions are saved – the diagram built, with each mask created, and the messages sent through the chat. 3.3

Using CO2DE

CO2DE was designed to help software developer groups to interactively build an UML diagram. Its aim is to explore the use of groupware features on collaborative

218

A. Pereira Meire, M.R.S. Borges, and R. Mendes de Araújo

modeling activities, giving participants the opportunity to create and discuss alternatives for evolving the diagram in a real-time fashion, like a brainstorm session. Although there are communication and coordination functionalities available, it seems necessary to previously prepare the group before the drawing session, explaining the meeting objectives. A closure meeting may also be important in order to discuss and evaluate the alternatives created and to decide on the final version of the diagram.

4

Evaluation

In order to evaluate CO2DE, case studies were designed and conducted. The evaluation observed how the use of the mask concept helped a work group to evolve in the drawing process, creating and improving the sketches of the diagram, and converging to a common solution, supported by the collaborative editor features. We aimed to evaluate not only the technology aspects but also, and more important, the interaction issues, such as decision-making, the conflicts that occurred and how the group managed to solve them. 4.1

Design

The evaluation design and discussion followed the guidelines suggested in CSCW Lab proposal for groupware evaluation [10] and are described in the following sections. Evaluation Hypothesis. The research hypothesis of the case studies could be stated as: the functionalities available in CO2DE aided group participants in creating different alternatives for a diagram and converging to a common artifact based on these multiple versions. Issues. In order to verify this hypothesis, some issues were outlined: I1. Did the mask mechanism available in the tool allow participants to easily create different alternatives of a diagram? I2. Could participants be able to discuss among themselves within the context of a specific mask? I3. Did the mask mechanism and associated discussion help participants to take decisions about which mask better represents the group work result? Dimensions of Evaluation. According to CSCW Lab, a groupware evaluation can focus on one or more of three dimensions: evaluating the tool usability; evaluating if the tool helped participants to reach an appropriate collaboration level; evaluating the cultural impacts the tool brought to each individual, to the group or to the organization. Whatever is the evaluation aim, the CSCW Lab suggests that the group context must be well understood in order to interpret each evaluation result.

Supporting Collaborative Drawing with the Mask Versioning Mechanism

219

The main focus of CO2DE evaluation design was on the level of collaboration and the tool usability issues. Therefore, it addressed these dimensions using the following variables: Group Context: Three case studies were conducted for the evaluation of CO2DE. In each case study a different group was invited to participate. Previous experience in OO software development, use of CASE tools and use of groupware tools were considered as important variables to characterize the groups. Usability: This version of CO2DE was a prototype and the case studies also aimed at verifying its viability while being used. However, it was not the main focus of this evaluation to conduct a deep analysis on the tool usability. Thus, these case studies could be classified as what we call “pilot-evaluations” [10][11]. Collaboration Level: CO2DE was conceived to help editors to generate multiple views of the collaborative artifact, to allow parallel work and to support discussion and decisions about the created versions/views. In order to evaluate it, the case study considered variables such as: the number of masks created by group participants (the degree of multiple views); the number of levels presented in the resultant mask tree (indicating group convergence/divergence); the degree of change between the created mask (indicating relevant contributions/changes); and if the final product reflected a relevant result in respect to the work problem complexity. Measurement Instruments. All information about the interaction is registered in CO2DE database, including a log document of user actions. This record was the main source of quantitative information for measuring the variables outlined above. Additionally, after each work session, participants filled out a questionnaire where other information, mainly subjective, could be retrieved. Scenario. The case study scenarios comprised the task of building UML collaboration diagrams for a pre-defined system use case [12]. A document describing the use case was distributed to the group along with its oral presentation in a meeting right before the interaction with CO2DE. After reading the use case and solving any doubts, participants started the interaction using the tool. Each evaluation scenario comprised two working sessions (with two different use cases to be detailed as UML collaboration diagrams) in order to compare their outcomes. In the first session, groups were limited to open new versions of the shared diagram in a linear sequence, i.e., multiple views of the diagram were not allowed. Thus, participants had to follow altogether the artifact evolution. In the second session, participants were able to freely use the mask mechanisms. Participants worked synchronously in the same room, although it was suggested not to talk to each other in a face-to-face manner. It was supposed that they should use the communication channels available in CO2DE – chat and annotations. Results and Observations. These were the findings obtained with the case studies, based on the CSCW Lab dimensions: Group context: Three groups of six members performed this evaluation scenario. Post-graduate students composed the first two groups. The other group was composed by IT professionals (system analysts and programmers) of a government agency. Participants of all groups had previous experience in software development. The par-

220

A. Pereira Meire, M.R.S. Borges, and R. Mendes de Araújo

ticipants in the first two groups had previous experience in using groupware tools. The last group, however, was more experienced on the use of CASE tools. Another important aspect to be observed is that the post-graduate students had less experience in working together while the third group was composed by members who knew each other well and had plenty of experience of working as a group. Usability: The experiments were the first occasion to apply the CO2DE tool in groups of six participants, working simultaneously, manipulating the shared workspace with a high number of contributions. The first session, especially with the posgraduating students, were quite unsatisfactory in terms of usability. Every single operation like clicking, dragging-and-dropping, navigating on menu options took many seconds. It seems the group were working in slow motion. A lot of noise could be heard inside the groups, as people complained, questioned and requested technology support. That situation led us to review the implementation of workspace redraw functions, specially the telepointers. A new version of CO2DE were built and applied in the second session, solving the mentioned problems and resulting in a more stable and smooth work. These were reflected in a substantial noise reduction, with a complete silence in the laboratory environment – communication between participants occurring basically through the chat facility. Most of the participants had not experienced interactions through synchronous tools. In all three groups, the first contact with the tool led participants to use some resources lately, like dragging-and-dropping. Some of them got confused when seeing all telepointers moving around inside the drawing panel. The awareness resources were positively evaluated, like telepointers, although some pointed out that it works fine for the people working in the same mask, but not for people situated in other masks (affirmative 5, table 1). Again, the result reflects the difficulties of interaction of the second group, in its four concurrent masks. Collaboration Level: The two groups of pos-graduated students made a very discreet use of the masks. While we expected a large structure, with many concurrent masks, conflicts, discussions, detaching the different points-of-view between members, the number of masks created was very limited. In the second session, when that facility was to be explored, one group developed a sequence of three masks only. An unique concurrent mask was created, but only one member worked on it, with minimum contribution. Mainly, work inside this group was conducted with all participants together, evolving throughout the represented sequence. Conflicts would have occurred only in graphical editing, punctual level. The unique concurrent mask was not relevant as an alternate version of the diagram. Inversely, another group developed four concurrent masks, all created from the initial one. This situation characterized a subdivision in the joint work, forming four sub-groups, some of them with just one member. Although some discussion has occurred among the sub-groups, co-authoring (activities) happened in a limited way in the masks. We believe this situation caused a weakness in the interaction possibilities between the sub-groups. The table in table 1 lists the main results from the questionnaire submitted to the participants to capture their opinions and feelings in this study. A list of affirmatives was proposed where participants should classify it in a scale from 1 to 4 - (1) completely disagree, (2) disagree, (3) agree, (4) completely agree. Each column presents the average value for the corresponding group of participants.

Supporting Collaborative Drawing with the Mask Versioning Mechanism

221

Group work supported by the mask mechanism favored establishing the stages through which work evolved. This result was reported positively by all three groups, as can be seen in the first affirmative in the table above (table 1). All groups indicated that masks favored to follow the evolution of group work, except group 2. This would be a symptom of the sub-division that happened with this group, creating four concurrent masks, with little interaction between them. Table 1. Qualitative evaluation applied to group members after the case studies

Affirmative 1

Using masks made it easy to define the stages of work, adequately indicating the version of the diagram 2 Using more than one mask in a session, establishing concurrent versions, favored to follow group work 3 When a participant selects one mask, he can easily identify the contributions added to it 4 Telepointers favored awareness of other activities. 5 The features allow identifying other participants, and where are they working exactly 6 Group work using a shared workspace with a WYSIWID interface can be considered productive 7 Using chat, it was possible to establish a channel of communication between participants 8 Context-based chat favored participants communication 9 The context-based chat records the message sequence in an understandable way, allowing participants to recall them lately and understand them clearly 10 During the sessions, establishing a coordinator role was important to conduct work

Group Group Group 1 2 3 3,3 3 3,8

3,3

2,5

3,4

2,7

2,7

3,2

3,5

3,2

3,4

3,7

2,5

3,2

3,6

3

3,6

4

3,2

2,8

3

1,8

3,2

3,3

2,7

3,6

2,2

2,3

3,4

In a joint session, the pace of work follows the pace of communication. During our study, we observed how groups proceed to interact, discuss, negotiate and make decisions, and which way they preferred to communicate and accomplish their tasks. Affirmatives 7, 8 and 9 tried to evaluate communication features. The first group adopted the chat functionality as their communication channel, rarely making use of some verbal or gesture to interact. That’s why their evaluation of chat was greatly positive. The second group had tried it the same way, but have experienced some trouble, some way because of bad performance in the first session, but also explained by the sub-division in four masks, turning their conversation into four separated chat rooms,

222

A. Pereira Meire, M.R.S. Borges, and R. Mendes de Araújo

as CO2DE does not join messages from concurrent masks. This explains their low value when questioned about context-based chat. The third group deliberately adopted the verbal, face-to-face communication in their sessions, perhaps because of their lack of experience with groupware. Limitations. As we started the first laboratory sessions, we observed a difficulty in all groups to understand the scenarios. Some participants reported that too much time was wasted during the collaborative work, discussing and explaining concepts that have not yet been understood. This observation showed us the need to prepare each group with a pre-meeting, clarifying doubts. In CO2DE, one participant is established as the coordinator, with some special rights in mask manipulation. This designation is suggestive and informal. We lacked for a formal coordination role in our study, guiding other participants in their tasks, and asking for commitment. The coordination happened in a distributed way during the sessions, through negotiation between team members, especially with the posgraduated students groups.

5

Conclusions

This paper presented a collaborative graphical editor as a proposal to address the problem of evolution awareness in a group editing session. The CO2DE tool is based in the concept of masks to establish the versions or stages through which a diagram evolves during its elaboration, allowing participants to work in the same or in concurrent versions – which characterizes WYSIWIS and WYSIWID interfaces, respectively. We identified some key issues in collaborative work, such as discussion and negotiation of viewpoints, conflict handling, and change awareness, citing related studies in the literature. The CO2DE functionalities are described, showing how it tries to approach the same issues. At last, some case studies are presented, in which the editor was submitted to use by three groups, trying to evaluate some of the target issues. The study has shown that the masks would be a useful feature for evolution awareness, although we faced limitations of time and resources, and a deeper research in this sense should be conducted. During the sessions, we observed a moderate use of the mask feature by the groups of designers. This would be explained by the short period for participants to get practice in the new tool, as well as the fact that people do not have the habit to establish versions, as the work evolves. In fact, analyzing the chat discussions, it comes clear that members try to coordinate their actions, negotiate the accomplishment of tasks before proceeding to the next step, but this rarely result in a concluded version. Well-known collaborative features like telepointers and chat were explored, based in the mask context. Using the masks to support collaborative work offer groups the opportunity to divide in smaller sub-groups, favoring concurrent work but making it difficult to communicate between sub-groups. The case studies gave as the chance to evaluate not only the technological facilities of CO2DE, but, even more relevant, how people manage to collaborate and complete their tasks when faced with the mask capabilities.

Supporting Collaborative Drawing with the Mask Versioning Mechanism

223

Some future work would benefit from this study, extending or reusing the results achieved. The most evident is preparing and realizing other case studies, considering more sessions or longer sessions, groups with more participants or geographically dispersed groups. CO2DE tool would also be used in researches from other areas, like context, group memory or communication.

References 1. Laboratory for HCI and CSCW, GroupLab, University of Calgary – http://www.cpsc.ucalgary.ca/Research/grouplab

2. Greenberg S., Gutwin, C. and Cockburn, A. Awareness Through Fisheye Views in RelaxedWYSIWIS Groupware. Proceedings of Graphics Interface, Toronto, Canada, May/1996, pp. 28–38 3. Gutwin, C. and Greenberg, S. The Effects of Workspace Awareness Support on the Usability of Real-Time Distributed Groupware. ACM Transactions on Computer-Human Interaction (TOCHI) 6 (3), 243–281, September/1999 4. Greenberg, S., Baker, K., Gutwin, C. Heuristic Evaluation of Groupware Based on the Mechanics of Collaboration. Report 2000-669-21, Department of Computer Science, University of Calgary, Alberta, Canada, October/2000 5. Pino, J.A., Pineda, E. Stick-Ons Revisited. Proceedings of the Seventh International Workshop on Groupware (CRIWG'01), September/2001, Darmstadt, Germany 6. Tam, J., McCaffrey, L, Maurer, F., Greenberg, S. Change Awareness in Software Engineering Using Two Dimensional Graphical Design and Development Tools. Report 2000670–22, Department of Computer Science, University of Calgary, Alberta, Canada, October/2000 7. Santoro, F., Borges, M.R.S., Pino, J.A. CEPE: Cooperative Editor for Processes Elicitation. Proceedings of the Collaboration Systems and Technology Track of the ThirtyThird Hawaii International Conference on System Sciences (HICSS-33), January/2000. (In CD-ROM) 8. Borges, M.R.S., Pino, J.A., Salgado, A.C. Requirements for Shared Memory in CSCW applications. Anais do WITS'2000, 10th Annual Workshop On Information Technologies and Systems, Brisbane, Australia, December/2000, pp. 211–216 9. Borges, M.R.S., Meire, A.P., Pino, J.A. An Interface for Supporting Versioning in a Cooperative Editor. To appear in Proceedings of the HCI International, Crete, Greece, June/2003 10. Araujo, R.M., Santoro, F.M., Borges, M.R.S, The CSCW Lab for groupware evaluation. In: th Groupware: design, implementation and use – Proceedings of the 8 International Workshop, CRIWG 2002, La Serena, Chile, September 2002, LNCS 2440, Haake, J., Pino, J. (eds)., pp. 222–231 11. Mangan, M.A.S, Araujo, R.M., Kalinowski, M., Werner, C.M.L., Borges, M.R.S., Towards the Evaluation of Awareness Information Support Applied to Peer Reviews of Software Enth gineering Diagrams. In: The 7 International Conference on CSCW in Design, 2002 12. Booch, G., Rumbaugh, J., Jacobson, I., The unified modeling language user guide. Addisson-Wesley, 1999

An Agent Framework to Support Opportunistic Collaboration 1

1

Melfry Moreno , Adriana Vivacqua , and Jano de Souza

1,2

1

COPPE/UFRJ – Computer Science Department Graduate School of Engineering 2 Institute of Mathematics Federal University of Rio de Janeiro – PO Box 68511 Zip Code 21941-972, Rio de Janeiro, RJ, Brazil {melfry,avivacqua,jano}@cos.ufrj.br

Abstract. In increasingly networked times, CSCW systems have become more common. In most of these, individuals work collaboratively from their personal computer terminals, unaware of their peers. In this scenario, opportunities for collaboration often go unnoticed. In this paper, we investigate aspects of unplanned cooperation and how it might be encouraged. We propose an agent framework to encourage and support unplanned cooperation between people not necessarily in the same team. Agents build user profiles and match users according to their interests, activities and opportunities for cooperation. By matching users’ work contexts, needs and resources, we expect to uncover opportunities for collaboration that might otherwise go unnoticed. We believe that the notification of users of these opportunities will lead to more frequent collaboration between them.

1 Introduction As more people and organizations become connected and cooperative work tools become commonplace, it becomes more common to find people working together in virtual environments. Most environments allow for message and file exchanges, discussions and co-editing. Some of these environments are media rich, including audio and video interaction in addition to standard tools. However, certain opportunities for interaction are lost in these environments, such as the informal hallway conversations and suggestions that may influence one’s line of thought or work. When at the computer, a person’s awareness of the environment is severely limited and the absence of environmental information often presents a setback. Instant Messaging systems and their awareness tools have started changing that somewhat: people can now be aware of others they know who are online at the moment and contact them should they need assistance. However, excessive messaging can be disruptive in a work environment, as has been pointed out in [16]: to a large extent, information about the activities of others is irrelevant in the current working context and only hinders work. We believe more can be done to jump start collaboration. Through user profiling, interest and expertise management and context awareness, it might be possible to better leverage users’ skills, competencies and available J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 224–231, 2003. © Springer-Verlag Berlin Heidelberg 2003

An Agent Framework to Support Opportunistic Collaboration

225

time and induce cooperative work. This is especially true in unstructured or loosely structured work environments, where work groups and teams are highly reconfigurable and not necessarily pre-set from the start. The academic environment is one such example: research teams may be engaged in different lines of work and specialists may join the group and contribute at different points. They may work as temporary additions to the group (with the objective of solving a particular problem, for instance) or they may become permanently involved with the project as a whole. Many opportunities for cooperation are wasted for lack of awareness that the opportunity even exists. Individuals don’t know of others skills, interests, availability or willingness to collaborate in a project. Furthermore, it’s not as easy to get to know and trust someone in the virtual world, or to bump into someone you know and might be able to collaborate with. Some systems allow for informal interaction in the hopes to stimulate conversation and creativity in their members, with various results. The extra information provided by awareness systems leads to a need for careful control of information flow, so as not to disrupt users. The issues of what information to present, when, how and to whom have grown in importance. To address these issues, we turn to profiling and matchmaking techniques, in order to filter the amount of information to be provided and the moment and recipients of the information. Another issue invariably associated with the provision of awareness information is privacy violation: a user's privacy may be violated by making details of their activities available that should have been kept private. Every piece of information about a user that is made available to others is a potential privacy violation. In this paper we propose an agent-based framework to support awareness and discovery of potential collaboration opportunities. We begin by introducing some background work (section 2), then move on to the framework in section 3, and wrap up in section 4.

2 Background Work Several previous works have dealt with video interfaces and using video to support personal awareness and informal interactions. One such example is VideoWindow [12]. Piazza [8] enables people to be aware of others who are working on similar tasks when using their computers, thereby enabling unintended interactions. It also supports intentional contacts and planned meetings. PIÑAS [14] is a platform that provides potential and actual collaboration spaces, as well as specific services customized to support collaborative writing on the Web (Doc2U [14]). 2.1

Awareness

Awareness has received much attention from the CSCW community in the past few years, as researchers realize the importance of being aware different aspects of the environment in a collaborative work setting. For instance, Pinheiro et al. propose a framework for past event awareness, in which users become informed of past occurrences, results and work history (including evolution of shared data, members’ actions and decisions, etc.), so as to better collaborate in the present [15]. Other authors have proposed prospect awareness systems, to enable individuals to envision potential

226

M. Moreno, A. Vivacqua, and J. de Souza

benefits of collaboration in an attempt to motivate collaboration [6]. Many recent papers have addressed awareness in mobile computing environments, where location awareness is a central issue for collaboration [10]. Other research has focused on document or task based awareness, and providing information to users about who is working on the same document or performing similar tasks at a given moment [8, 13]. The most basic form of awareness is personal awareness, such as provided by current messenger systems, where a user specifies a list of contacts and the system displays their availability and status. We believe the first step towards a successful collaboration is becoming aware of the opportunity to collaborate. We therefore focus on potential collaboration awareness, and aim to provide users’ with information on opportunities for collaboration, a similar problem to that addressed in [14]. 2.2

Unplanned Interactions

Kraut [12] presents a useful classification of the different types of interaction found in work environments: (1) Scheduled: conversations previously scheduled or arranged; (2) Intended: one where the initiator set out specifically to visit another party; (3) Opportunistic: one in which the initiator had planned to talk to other participants sometime and took advantage of a chance encounter to have the conversation; (4) Spontaneous: a spontaneous interaction in which the initiator had not planned to talk with other participants. He also points out that the majority of conversations in organizations are informal in nature and that these are usually short, involve two people and build upon previous discussions. They tend to happen because one person happens to be near another at a time when one wants to ask for or provide information. Studies show that these informal interactions play a central role in helping workers learn, understand, adapt and apply formal procedures and processes [8]. Few systems have focused on support for opportunistic and spontaneous interactions. In [13], virtual proximity is defined as situations in which users access the same data or users invoke the same application in the virtual environment. We take a similar approach, using an individual’s current context (what one is currently working on) to search for others who might be interesting to talk to, within that context. Our system also takes the user’s context into account, providing only information that is relevant to the user at the moment, so as to not worsen the problem of information overload or disrupt the user’s flow of work or line of thought.

3 CUMBIA Framework We have envisioned an agent-supported peer-to-peer architecture, CUMBIA, where each user has a cluster of agents to help with knowledge management and collaboration tasks. These agents are in charge of identifying potential cooperation situations and trying to make these come to fruition. Agent-oriented techniques are finding increased usage in a range of telecommunication, commercial, and industrial applications [9], as developers and designers realize it’s potential. Agents are especially suited to the construction of complex peer to peer systems, because they are light-

An Agent Framework to Support Opportunistic Collaboration

227

weight, permit parallelization and easy reconfiguration of the system. Agents have been used in groupware for a long time due to their social abilities [3]. A recent survey of the application of agents in groupware and CSCW can be found in [4]. Systems such as Personal Assistant [5] and COLLABORATOR [3] are some successful examples of agent approaches used in developing collaborative tools. AwServer, and E_Places are good examples of agent-based awareness work [1]. 3.1

Agent Architecture

In CUMBIA, each user has its own agency to assist with knowledge management and cooperation tasks. In this architecture, there are four agent teams to perform specific tasks as shown in Figure 1. Agent Teams and main functionalities are:

Fig. 1. CUMBIA Agent Architecture

• User Interface: displays information to the user and allowing the user to specify parameters and information to the other Agent Teams. • Collaboration: allow for the easy and quick establishment of contact when the possibility for collaboration arises, provide tools for cooperation (forums, etc.) • Awareness and Matchmaking: search for other users with whom it might be interesting to establish contact, contact other agents for their users’ profiles and contexts, compare user profiles to current context and work environment. • Knowledge Management: manage user’s personal data and build initial profiles based upon it, keep track of documents, searches, ongoing collaborations and current research. User interface agents perform all interface related functions, providing information to the users and requesting information from them. UI agents mediate requests between agents and users. We have not concentrated on the best ways to display information at this point, but agents will be able to decide on the more appropriate ways of displaying information when they receive it and decide on the proper time to display it, thus addressing the problems of what, how and when (given that who is fixed). We will be building upon work done in [1]. Knowledge Management, Awareness and Matchmaking and Collaboration Services are discussed in more detail next.

228

3.2

M. Moreno, A. Vivacqua, and J. de Souza

Knowledge Management Services

KM agents provide profiling functionality to the system. Basic units in the profile are projects and interests, which are interrelated. Part of the profile information has to be explicitly provided, and another part is automatically inferred. Users always have the last say on their profiles, being able to correct the information and determine which information can be made public and which can’t. In CUMBIA, a person is always working on a project. Thus, the basic context units are project definitions. Projects are related to documents, people, collaborations and research, but are inherent to each user. So, an ongoing cooperative project might (and almost certainly will) have two or more different project definitions associated with it, one for each user. This is consistent with the fact that each individual has their personal view of reality, and organizes their work accordingly. It is useful, of course, to keep track of the correspondence between individual projects that represent the same group endeavor. Profiling Agents keep track of the following information:

•

Contact Information: information necessary for one person, potential or actual collaborator, to contact the user: Name, Title, Email, Phone, etc.

•

Areas of Interest: areas in which the user has some interest. May be automatically or manually setup, and ranked by interest and activity level

•

Projects: projects the user is involved with. These are classified according to their activity status: Past, Present, and Future. Projects may have associated deadlines that can help prioritize agents’ work.

•

People: a user’s contact list, this may be classified in different categories, such as personal or work contacts, previous, current or potential collaborators, researchers, etc. Contacts are related to projects in the context of collaborations entered and to areas of interest when the users have similar interests. Users can rate people regarding their relevance to an area of interest or project.

•

Web History: agents track pages the user accesses when navigating the Internet. The user can rate sites according to their relevance to the work or project in progress (this information can also be inferred from time spent on documents, number of accesses, etc.)

Profile information is saved in a Knowledge Base. The system logs message exchanges (text, email, discussion) and these are linked to projects, forming a personal project history. This history serves to inform future discussions, to assist users in establishing common understanding, and to allow users to “pick up from where they left off” when entering new interactions. In addition, it helps users establish patterns of cooperation, determining which users have been cooperative in the past (and possibly favor these in the future) and which ones have consistently avoided interaction with the user (to possibly avoid these in the future). Several sources of information can be used to build user profiles: email, bookmarks and publications read and written are just some of them. In many approaches, documents are analyzed for their text content and keywords are extracted and then rate each document according to its importance to the user. Document rating is based on number of accesses, length of access, type of access (read, write, print), and distri-

An Agent Framework to Support Opportunistic Collaboration

229

bution (whether it was sent to someone else or not). Thus, documents in users’ profiles are ranked by popularity, and keyword importance is calculated accordingly. It is important to note that the system allows the user to establish what information is made publicly available for awareness and matchmaking purposes. The system is as transparent as possible, so users understand the process and how their information is being used. 3.3

Awareness and Matchmaking Services

We identify opportunities for collaboration by matching a user’s current context with other users who might be interesting to collaborate with, thus “recommending collaboration”. Given a user’s context, agents search the profile information for project-related information, building a “project profile”. This “project profile” will have information on a user’s resources for this projects (documents, references, links) and a user’s needs for the project (which can be inferred by searches performed and references downloaded). Agents will search for other users who might be able to provide some of the user’s needs. This match is made according to both users’ contexts (if one doesn’t have to leave their current context to help another, that is preferable than having to change contexts). The match also takes into account the potential for reciprocity (does the other user need something the first user can provide?), in an attempt to provide some motivation for cooperation. When an opportunity for collaboration comes up, a user is notified. Opportunities are time sensitive, and the user should be informed of the potential for reciprocity (if any) and should be given information on the other user that includes past partnerships and cooperative behavior. Furthermore, it is important to make the initiation of collaboration as effortless as possible. So, when agents detect that some information or document a user has might be useful to another user, they can automatically suggest what to send it be sent. In this fashion, a user has less to worry about regarding finding appropriate information. Users may always choose to engage in longer interaction, entering a chat or message exchange. To speed up the searches, matches can also be made “offline”: these pre-matches are run in the background to find users who might be interested in any of the projects or areas of interest the user is involved in, building and storing simplified models of other users. 3.4

Collaboration Services

Once a collaboration opportunity has been identified, an individual may become an incidental collaborator or an active collaborator. Incidental collaborators are those who provide occasional suggestions and sometimes attend meetings. Active collaborators become inserted in the project, and will have to deal with its schedules and deadlines. It is important to know each participant’s status and to know whether any tasks are dependent on them. It may be useful to integrate some project management capabilities to assist with active collaborations. In our system, we provide all the standard collaboration support tools, such as discussion lists, messaging systems, shared whiteboards, file sharing mechanisms and email. Most of these already exist as

230

M. Moreno, A. Vivacqua, and J. de Souza

modular solutions, which can be plugged in, so we will progressively add tools and services to the system as they become necessary.

4 Conclusion and Further Work One of the biggest problems when moving to a virtual work environment is that individuals lose opportunities for spontaneous, unplanned interactions. These opportunistic interactions usually happen when individuals are co-located and bump into each other in hallways or peek into each other’s office for a quick exchange. This has caused the recent emphasis in awareness systems and recognition of the importance of informal interactions. There seems to be a general feeling in the CSCW community that “awareness information is good”, so it is provided. However, many systems proposed provide awareness without any focus to it. Systems provide users with information on others’ current online status, past or present activities or objects being used, but provide no extra impetus towards cooperation, hoping that it will happen just because users can now observe each other (to an extent, it does). We believe that more can be done to encourage cooperation: systems can provide additional information on what information is relevant to the other users at the moment and how one can cooperate. It seems that most systems don’t exactly have a purpose for providing awareness information. We focus on the opportunities that arise from users’ work at their stations. Through careful analysis of users’ work activities we can establish what topics are relevant and where they might need assistance. We can also establish what users are proficient in what areas and in this manner find possible cooperation opportunities between them. Most systems lack the ability to uncover opportunities for cooperation. Furthermore, by focusing on the reasons for providing awareness information and working towards that end, we expect to reduce the information flow and direct users towards opportunities for cooperation. This is better than providing a lot of extra awareness information that users will have to sift through, and consider whether each one is useful. Further work is also needed in the areas of user motivation for cooperation and user trust. We adopt an agent-based approach to solving this problem, giving each user an Agent Team to assist with knowledge and information management, as well as search for peers who might be interesting to make contact with. We believe the first step towards establishing cooperation is identifying the potential collaborative situation, and the next step is making the act of cooperating as effortless as possible. Profiles contain a wealth of information so we can test different matching techniques and variables to determine which work best. Additionally, all information and matching rules may be parameterized by the user, to achieve better results. There is still much work to be done, namely in the areas of context inference and rule building for matchmaking. We will be testing and improving on matching and profiling methods as the project evolves, to see what rules work best. We are implementing the first prototype, for an academic work environment, and should have some initial results soon. Academic work environments are usually loosely structured, in that there is some structure but it is flexible and adaptable. Usually, several opportunities for spontaneous collaboration exist. In this environment, group formation happens as common interest appears and individuals come together to work for a period of time (the duration of a project) and disband later (but

An Agent Framework to Support Opportunistic Collaboration

231

ties remain, as does the possibility of further collaboration). Additionally, cooperation may be externally triggered, for instance, with the appearance of a new funding opportunity. External funding agencies may provide guidelines for projects (which usually involve the participation of a number of specialists): in this case it becomes important to find and organize a group of interested, qualified people to form a group and write project proposals to take advantage of the opportunities. We expect this to be a good application domain, and one that will provide plenty of useful information for our project.

References 1. 2. 3. 4. 5. 6.

Alarcón, R. and Fuller, D. Intelligent Awareness in Support of Collaborative Virtual Work Groups. In: Haake, J. M. and Pino, J. A. (Eds.) CRIWG 2002, LNCS 2440, pp. 147–167, Springer-Verlag, 2002 Bergenti, F., Garijo, M., Poggi, A., Somacher, M. and Velasco J.R. Enhancing Collaborative Work through Agents. VIII Convegno dell'Associazione Italiana per l'Intelligenza Artificiale, 2002 Ellis, C.A. e Wainer, J. Groupware and Computer Supported Cooperative Work. In Weiss, G. (Ed.) Multiagent, Systems, MIT Press, 1999 Enembreck, F. and Barthès, J. P. Personal Assistant to Improve CSCW. Proceedings of the 7th International CSCWD, Rio de Janeiro, 2002, pp: 329–335 Hoffman, M and Herrmann, T. Prospect Awareness – Envisioning the Benefits of Collaborative Work. Available online at:

7.

http://iundg.informatik.uni-dortmund.de/iug-home/people/MH/ ProspectAwareness/PAhome.html

8.

Isaacs, E.A., Tang, J.C. and Morris, T. Piazza: A desktop Environment Supporting Impromtu and Planned Interactions. Proc. CSCW’96, Cambridge, MA, 1996 Jennings, N.R. An Agent-Based Approach for Building Complex Software Systems. Communications of the ACM, April 2001/Vol. 44, No. 4 Kortuen, G., Gellersen, H.W., Billinghurst, M. Mobile Ad Hoc Collaboration. Proceedings of CHI 2002, April 2002, Minneapolis, USA Kraut, R., Fish, R., Root, B., and Chalfonte, B. Informal communication in organizations: Form, function and technology. In S. Oskamp and S. Spacapan (Eds.), People’s reactions to technology in factories, offices and aerospace, The Claremont Symposium on Applied Social Psychology, Sage Publications, 1990. pp. 145–199 Matsuura, N., Fujino, G., Okada, K. and Matsushita, Y. An Approach to Encounters and Interaction in a Virtual Environment. Proceedings of the 1993 ACM Conference on Computer Science, Indianapolis, Indiana, United States, 1993 Morán, A. L., Favela, J., Martínez-Enríquez, A. M. and Decouchant, D. Before Getting There: Potential and Actual Collaboration. In: Haake, J. M. and Pino, J. A. (Eds.) CRIWG 2002, LNCS 2440, pp. 147–167, Spring-Verlag, 2002 Pinheiro, M.K., Lima, J.V. and Borges, M.R.S. A Framework for Awareness Support in th Groupware Systems. Proc. 7 International Conference on Computer Supported Cooperative Work in Design – CSCWD’2002, Rio de Janeiro, Brazil, Sept 2002 Sohlenkamp, M. Supporting Group Awareness in Multi-User Environments through Perceptualization. GMD Research Series Report, No 6, 1999. Fachbereich MathematikInformatik der Universität – Gesamthochschule, Paderborn, 1998

9. 10. 11. 12.

13. 14. 15. 16.

Groupware Support for Cooperative Process Elicitation 1

1

1

2

Rosa M. de Freitas , Marcos R.S. Borges , Flávia Maria Santoro , and José A. Pino 1

Departamento de Ciências da Computação and NCE Universidade Federal do Rio de Janeiro Caixa Postal 2324, CEP:20001-970, Rio de Janeiro, Brasil [email protected], {mborges,flaviams}@nce.ufrj.br 2

Computer Science Department Universidad de Chile Casilla 2777, Santiago, Chile [email protected]

Abstract. We propose an alternative approach to the usual business process improvement, in which company workers play an active role in re-designing the organization's processes in a cooperative style. We present the CEPE tool - Cooperative Editor for Processes Elicitation - which is a cooperative graphic editor that supports the building of the knowledge about the current process and reports associated problems. Moreover, this paper presents the results of a case study in which the editor was used.

1 Introduction Currently, management spends too much time correcting problems that should not have occurred in the first place, if business processes were correct. According to Harrington [1], emphasis should now be placed on preventing problems. Improvements can take many forms. Barriers must be removed which interrupt the flow of work and processes must be streamline to reduce waste. The way to improvement is through business process improvement (BPI). Business Process Improvement involves implementing major changes in the way organizations are managed. BPI’s major objectives are to make processes effective to achieve desired results; to make processes efficient to minimize resources; and to make processes adaptable to meet both customer and business changing needs. Business processes used today by most companies have not kept pace with today’s business environment. Management must focus on and invest resources to revise critical business processes to make them more efficient, effective, and in tune with the needs of individuals, customers and the organization [1]. The use of the BPI strategy has lead to reengineering within organizations. “Companies that undertake reengineering not only compress processes horizontally by having case workers or case teams perform multiple, sequential tasks but vertically as well.” [2]. As already confirmed by several studies [3][4][5], reengineering is not only a one-time event, during which all processes have been optimized, but requires a permanent care of the processes, adapting them to the demands of the organization. J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 232–246, 2003. © Springer-Verlag Berlin Heidelberg 2003

Groupware Support for Cooperative Process Elicitation

233

Process improvement projects are usually provided by outside consultants. The advantage of doing so this is that they are not involved with the current model of the organization. However, external consulting also carries drawbacks in this area. One is the high cost of the service [6][7]. Other disadvantages are related to the reengineering results, which may alienate employees or be too ambitious for the current culture of the organization. On the other hand, reengineering may also be considered a challenging and permanent cooperative task. In order to achieve better results, it should involve as many agents as possible. They can contribute to the understanding of current practices and to their improvement. The first task of such process improvement project is to elicitate the current process and to identify its problems. Considering that each individual has particular forms of working, perceiving and describing the reality based on his/her own values, beliefs and truths, we could not affirm that simply stating ideas and visions together will represent this reality. It is necessary to represent the several and different views about the work inside an organization. This task has a strong aggregative characteristic, stimulating effective participation of workers in order to achieve a vision that describes the details of each process that maps the organization’s life. This paper describes a computer-based tool, which aims at helping the workers with the joint effort of consultants in the unambiguous cooperative elicitation of the current process, the identification of potential problems and the development of eventual solutions. The main goal is to provide support to the description of processes, establishing a common language among participants, independent of time and space. The CEPE tool, which stands for Cooperative Editor for Process Elicitation, can be used after workers are trained in the process improvement activities and for those who are ready to adopt a positive attitude towards the process improvement project. The focus of the proposed approach is on a participatory basis design. The CEPE tool exploits the cooperative nature of such a task and at the same time generates a predefinition of current processes, which will be the basis for the formal definition of the organization ‘To-Be process’. This article is divided into 4 parts. In Section 2, we discuss the issues related to cooperative process design. Section 3 presents the CEPE groupware. A case study developed with the use of CEPE is described in Section 4. Section 5 concludes the paper.

2 Cooperative Process Design The administration and improvement of processes allow companies or industries to develop faster and help key-area processes to be more efficient. There are several opportunities "to start again" with the processes re-engineering. For example, it is advisable to reformulate a process that is aimed at outsourcing before giving it to an outside company. Another example, an inadequate information technology infrastructure, which constitutes an opportunity for processes improvement; several companies need to reconstruct important systems, but they should not simply automate inadequate or incompatible processes. It is probably more preferable that these companies combine the radical innovation with the continuous improvement [8]. The details of a specific method or approach to the process improvement can vary, but some activities are fundamental for the success of any initiative: the selection of

234

R.M. de Freitas et al.

processes for redesign, the examining of the process improvement providers, the understanding of the existent process and the project of a new one. It is important, however, to understand the existing process before designing a new one. The comprehension of the existing processes provides a measure of the value of the process improvement proposal. The processes improvement can also highlight the need of better coordination and administration of the functional interdependencies. In this context, the processes elicitation activity consists of detailing the role of each process inside an organization. Usually, this stage is the preliminary phase of a process improvement project. The work of external consultants excludes the involvement with the organization’s employees. It seldom can count on the support of tools designed for the task. Borges and Pino [9] report advantages and disadvantages of this approach: the exclusion of the organization’ workforce and the imposition of the recommended solution upon the routine of existent work are some of the most important disadvantages. It is desirable that the internal culture of the organization could absorb frequent changes, resulting in the appreciation of its own mistakes and successes. However this attitude is rare. It is a great challenge to promote innovations in institutions with the cooperation of involved people. Borges and Pino [9] advocate an alternative approach to processes re-engineering that is characterized by the participation of the organization’s members in the change proceedings. It contemplates not just the concern and the incentive, but also the way to implement a re-engineering program tuned by a gradual, continuous improvement, that promotes the involvement of both the external consultants and members of the organization. The employees develop an important role, re-designing the processes in a cooperative way. It is expected that the employees' commitment with the success of the reengineering project will help to reduce resistance factors. Several people should work in the cooperative design (description) of the process. There will be many contributions coming from different individuals: each one will exhibit how he/she “sees" the task or the process that is being redesigned. Thus, little by little, an organization is portrayed. All participants draw a map of the organization’s processes. The resulting knowledge that now becomes common to everybody is the most important result that the organization can obtain from this work. Drawing the map of processes is an interactive activity. The design of the processes, the information technology and the new organization will be improved and refined, until it reaches an understanding of the process and its frontiers. Communication needs to be effective and qualified, because it is an essential requirement to the commitment of a participative approach. Another important aspect of this activity concerns the absence of a notion of finishing an elicitation. A stop criterion does not exist. The basis for finishing is the satisfaction conformity within the team. There are five problems associated with the cooperative elicitation: 1. The knowledge comes from diverse base and varies vastly in the quality of information and exhibition. 2. The current knowledge comes from many different sources. The description or the contents of the processes need to be negotiated. 3. 4. The conflicts need to be resolved. 5. The knowledge itself is uncertain and unstable.

Groupware Support for Cooperative Process Elicitation

235

The elicitation may be seen as an evolutionary process: as stages develop more details are required, or existent parts through the description of the exceptional behavior cases, which portray errors or very simplified expressions, are classified. Different people, with contrasting perceptions will read the map of processes, which should be comprehensible for all of them. Therefore, the graphic representation form is important, moreover, it needs to be readable by different groups of people, who will extract the information they need from the description of processes. The graphic representation of a process can be extremely useful in the understanding of process flows. We claim that a groupware tool supporting process elicitation could help to improve the group’s work procedures. It is necessary to describe processes, which gather knowledge and contributions distributed among its members and represent them in a single document. It is unreasonable to expect from a single participant to be able to describe a complex process with fidelity and thoroughness. No matter how much individual effort a person makes, he/she will not be able to manage to represent the organization’s business processes information fidelity alone. This requires a non-trivial coordination of work to be accomplished. It is necessary to represent the different visions about the reality of the subject (the work accomplished inside of the organization), respecting the part of individual awareness, which is provided by means of contributions and individual descriptions. Processes elicitation in an organization is a very complex task that consumes time and energy. Nonetheless, knowing the processes of an organization is revealing the way it operates and it is certainly one condition for its success.

3 CEPE – A Cooperative Editor for Processes Elicitation Santoro, Borges and Pino [10] proposed the first version of CEPE implemented over the GroupKit toolkit [11]. Mechanisms used in similar tools, for example, CESD [12][13] were analyzed and taken as reference. From that analysis, some basic points were specified. The requirements for a cooperative tool to elicitate processes are [14]: •

To present a highly interactive and friendly interface;

•

To exhibit the flow of materials and information among activities;

•

To identify the main bottlenecks and limitations of the process;

•

To portray graphically the parts of the process and

•

To draw in real time a graphic view of the processes.

During a processes elicitation session, the participants can represent the processes and describe them, in terms of tasks and relationships among them. The potential users of this tool are the employees of an organization who will participate in the redesigning of the processes, such as, secretaries, managers, administrators, directors, business analysts, system analysts and consultants. The consultant should play the facilitator’s role, observing how the elicitation is being constructed and eventually passing on suggestions and messages, instructing the participants to review parts of the work previously executed. The complete description of all processes is stored in order to keep the memory of the elicitation.

236

R.M. de Freitas et al.

Description CEPE is a Cooperative Graphic Editor, which provides a space to describe a process, and collect information about the process. Furthermore, problems could be discussed on a continual basis, allowing additional comments and suggestions about each process, which is being elicited. Thus, providing some awareness mechanisms. It uses a set of elements extracted from the Regatta Project Model [15] and generates an outlet, which is likened to a workflow model. CEPE was developed on top of the COPSE environment, which is a framework intended for building real-time shared applications supplying group communication functions [16]. The applications are written in JAVA. The MySQL database management system was used to register the whole process, as well as the associations made by the participants to its elements, preserving the memory of the whole process. Elements During a CEPE session, participants may add elements in order to build the map of the processes. They may also describe the current tasks and the relationships among them. CEPE elements can be included in a design by selecting the “Elements” option of the Main Menu. Table 1 shows CEPE elements. Table 1. Graphic Elements Representation

Element

Graphic Representation

Reference

Stage/Role R l Descripti

Option

0Event

The CEPE elements can be added to a design through the “Elements” option of the Main Menu. The following is a description of these elements. 1.

Reference is a physical or virtual location in the company. Examples of a reference are the Finance Directory, the Personnel Department, and the Quality Control Team. The graphical representation is a rectangle (Figure 1).

2.

Stage is the activity to be executed within the process. Some basic components must be associated to it, for example, a task, a reference, a role, incoming and outgoing products, resources, execution time and a description of the activity. Each one of these must be selected from lists, except time and description. An ellipse divided horizontally represents the stage. The role description and a task description are set to the superior and inferior parts of the ellipse (Figure 2).

Groupware Support for Cooperative Process Elicitation

237

Fig. 1. Creating a reference during a process’ elicitation

Refinement of stage descriptions is possible. The stage can expand to accommodate a more detailed description of the levels of the tasks. When this feature is used, a traced line is drawn in the border of the ellipse. In the expansion a new stage is created to define every element (role, task, etc) related to this new stage.

Fig. 2. Creating the stage

3.

Task is the activity executed within the stage. During the creation of a stage, a task must be chosen from the list of available tasks.

4.

Role describes the function performed by someone. Examples of roles are a secretary, a production assistant and so forth. In the creation of a stage, one or more roles can be attributed to a task; these roles are selected previously from the list of roles.

238

R.M. de Freitas et al.

5.

Option are connections that link stages. After describing a stage it may be necessary to link it with other(s) stage(s). Links connecting one stage to another, many to one or one to many stages are provided. One may choose option (yes/no), a condition ‘and’ or ‘or’ (split or join), to combine or to dissociate flows. When choosing logical operators, more than one stage may be associated to the option.

6.

Event indicates the flow from one stage to another. Flows are allowed between existing elements such as stages and references. The insertion of an option forces the creation of a flow. The origin and the destination of any flow must be indicated. Its graphic representation is an arrow appearing on the screen after creation (Figure 3).

Fig. 3. Events (selection of origin and destination)

7.

Comments are texts carrying suggestions, questions, and proposals, referring to mistakes, placing critiques that can be associated to any element during elicitation. Thus, the participants’ opinions and ideas are stored for later reference. These comments have iconic representation. Clicking on an icon enables the associated comment to be shown in a specific window. Comment icons are positioned close to the element they are related to. Some examples of comments are shown in the Figure 4.

8.

Products (incoming or outgoing) are objects necessary for the execution or are generated in the context of tasks. Reports and forms are examples of products. Either incoming or outgoing products are selected from a list of products.

9.

Resources are physical or virtual elements that support the execution of tasks. Examples of resources are printers, cameras or specific software. Some tasks need special resources in order to be executed, such as a bright sheet of paper to print a photo. Once created, a resource is included in the resources list. Resources appearing in stages are selected from a list of previously defined resources.

Messages Messages can be sent to one or all participants. They are quite useful for the facilitator who can call the attention to unsolved situations and to address suggestions to specific members of the group.

Groupware Support for Cooperative Process Elicitation

239

Fig. 4. Comments represented by icons

Black participant view.

Green participant view.

Fig. 5. Two views (green user and black user)

Awareness The tool provides the following awareness mechanisms: a)

A different color is associated to every new user. Every element inserted by a user is drawn with the color associated to that user.

240

R.M. de Freitas et al.

b) A special icon NEW is used to highlight new elements (stages, comments and references) included since the last session of any participant. c) The map of the elicitation process can be drawn with the elements introduced by a single participant, allowing one to observe the involvement of each participant in the elicitation. d) CEPE allows anyone to check who is currently logged in. Views A view is an alternative form of representing a stage or any other existing element in the elicitation session. CEPE provides a way of describing an alternative view of any element, i.e., elements can be represented by more than one description. A dashed line rectangle with a magnifying glass icon around the described element. As in any similar situation, the object is drawn with the color associated to the user (Figure 5).

4 A Case Study with CEPE A case study was accomplished in a drug distribution company [17]. Besides being open to the innovations of the academy, this company had already gone through an unsuccessful process improvement program. A cooperative approach, supported by a cooperative tool stimulated the company in "trying" the participatory process improvement. The case study took place in 2002 and focused on two main objectives: 1.

To test a cooperative tool to support the processes elicitation;

2.

To explore the participative focus allied to a groupware, aiming at fostering the cooperation within a work team.

The Company Remedial1 is a drug dealer, with its head office based in Uberlândia-MG, Brazil, which also has branches in 3 different states: Paraíba, São Paulo and Distrito Federal in Brazil. It has an annual turnover of 60 million dollars; it relies on 450 employees, with an additional 400 autonomous workers (100 drivers and 300 representatives). Remedial works with approximately 400 pharmaceutical and perfumery sales representatives in order to attend to the needs of 6000 clients/month, spread geographically over the states of Minas Gerais, São Paulo, Rio de Janeiro, Santa Catarina and Distrito Federal, besides the capitals of the northern territories of Brazil. The operation of the company is totally decentralized, but the administration of Budget and Costs Control is centralized in Uberlândia, as well as the payments. Two analysts and the manager coming from the Budget Department were selected to participate in the experiment. All of them had a Business academic background. 1

Fictitious name

Groupware Support for Cooperative Process Elicitation

241

Methodology The experiment was conducted in two phases: the first without the groupware tool and without the participative approach, and the second phase with participative focus and use of the groupware tool. For both phases, a consultant was selected. Once phases 1 and 2 were accomplished, the results were then compared. We expected to observe the participative focus, with the use of the tool during the processes elicitation, the cooperation level among the participants and the time taken to deliver the results of the document. Analyzing the data collection we then wrote a qualitative report on each of the participant’s contributions in the map of processes generated and also the information exchanged throughout the process - messages and data. At the end of the experiment, the participants answered a questionnaire (in order to collect and register the impressions, observations, critics and suggestions).

Fig. 6. Process mapped by the consultant

Description For both phases, the defined allotted time was four days for the accomplishment of the task.

First phase: The consultant established routines for individual interviews with the members of the team. The consultant set up the map of processes and it was only presented to the team after the end of the second phase (Figure 6). Three sessions of interviews were conducted. Second phase: A training program was up set presentating CEPE to the team. Four sessions lasting approximately two hours, with a process map example showed how to work with CEPE. The mission of the team was to elicitate processes related with the Budget area (chosen by the management) using CEPE to

242

R.M. de Freitas et al.

produce the map of the processes cooperatively. The team was instructed to use only the communication tools (message and chat) provided in CEPE. By the end of the second phase, a questionnaire was applied to gather impressions on the accomplished work. Results Obtained:

q

In relation to the interaction among the participants: Table 2. Summary of messages exchanged Types of Messages (*) Messages of socialization (personal presentation) Messages with work content (contributions to the work) Messages of coordination (suggestions for the good course of the work, linkage of the work, schedule negotiations, exits) Messages without work content (confirmation, agreement)

Number of messages exchanged

q

Number

%

10 102 21

7 72 15

9 142

6

In relation to participant’s contributions: Table 3. Individual contributions on the final document

Green Participant Black Participant Blue Participant

q

Total MesParticipation sage per Par- in Final Product ticipant 68 high 49 high 25 low

Relationship among contributions high high low

In relation to the impressions of the participants: Table 4. Results from the answers of the questionnaire Qualitative Analysis 0Satisfaction with work Cooperation Grade Team Coordination Communication Participation in Team

high high good very good very good

Analysis and Interpretation The work team worked cohesively. The coordinator (manager of the area) who contributed less (quantitatively) was justified because of the countless times he had to give attention to the phone calls. The team behaved in a uniform way when having to face challenges; there was integration and a good understanding among the participants, which became evident on several occasions, which was noted in their comments in the assessment questionnaire. Here, a first conclusion can be reached: the team demonstrated a capacity

Groupware Support for Cooperative Process Elicitation

243

of self-management and coordination of the tasks. Therefore they achieved good results in the issues referring to interaction and coordination. The team reported a feeling of improvement in the interactions and in the understanding of the activities performed within the company - the amount of interactions also increased significantly. Many comments were associated to each element of the processes map and discussions were generated based on these comments. It enriched the relationship among the individual contributions. In general, they did a good job on coordination in revising the final map of processes. The team did not use the chat tool as much as expected, perhaps because the technology was not familiar to them. In spite of the fact that the environment provided this mechanism, on several occasions it was necessary to ask the participants to only use the tool communication channels provided, not verbal communication. None of them had experience in the use of this kind of software, thus they did not have a previous expectation about the results of the work. One of the interesting aspects observed is the fact that using a real cooperative tool, different from everything they had tried before, was enough to establish a cooperation state within the team. People are accustomed to the traditional group work; with division of tasks they had to change their working dynamics. Changes in work usually bring instability. Reactions like rejecting the new methodology or unwillingness to cooperate may appear. Even so, this was not observed. In the accomplishment of the experimentation proposal, the team assumed the "incumbency" as a serious work and with the participation of the direct leadership, the commitment was high, everybody encountered a lot of responsibility. They felt enthusiastic about using the tool and reported that they felt satisfied with the work with such an interactive tool, with a colored and highly pro-active environment. They also reported the use of tools of this nature should be part of daily life, because it acts as an inductor of synergy, leading the team to a cooperative state. The more the team understands and knows the process, which it is working with, the more the cooperation level is improved. In that situation, the use of the tool seemed to induce the cooperation. The conclusion was positive: people reacted well to the use of the new technology, they were stimulated and the acceptance was excellent. There are limitations associated to the short time placed on the experiment, which inevitably results in a relatively small project. The experiment was conducted during working hours in the company. If the team had had extra time to complete the work, perhaps it could have had a better reflection on the processes and on the form and style of executing it. This could have had a positive impact on the results in cooperation. Problems in the office environment digressed the attention of the work of at least one of the participants. The process mapped was relatively simple (Figure 7), thus the elicitation elapsed without any significant problems, which facilitates the analysis later. Since just one team was analyzed, there is not a possibility to accomplish comparisons. The obtained results can be strictly related to the specific characteristics of the team. The tool, when attributing colors to the participants, facilitates the identification of the individual work. The final product presented contributions from all the members of the team. The final map of processes exhibits that, characterizing the participation of each one. According to the interaction, it is possible to conclude that only looking at the quantitative results, we cannot affirm a lot of things: who sent more messages, did not always put in it relevant content. It is very important, when analyzing this point, to try

244

R.M. de Freitas et al.

to understand if each individual got to understand the activity accomplished by others and then to enter or to stay in a cooperation state.

Fig. 7. Process mapped in the collaborative experiment

It was noticed during the elicitation that the team was sometimes confused with the definition of interfaces (the sequence) of the processes. With the elapsing of the work, this point improved and gave place to quite profitable discussions, with a lot of enrichment about the knowledge of each process.

5 Conclusions and Future Work In the face of changes and the dynamism that characterize the society nowadays, organizations need continuous adaptation in order to survive in a highly competitive market. This type of adaptation can be done through a process improvement project, which means, to redesign the processes of the organization. The idea is not to execute the processes in the same way, but to question first if this is the most appropriate way. The accomplishment of improvement levels in such processes means replanning from beginning to end, with the employment of all the innovative technologies and resources available.

Groupware Support for Cooperative Process Elicitation

245

This paper presented a proposal on how to deal with the first step of a process improvement project with the full participation of baseline workers supervised by consultants. It describes a groupware tool aimed at the elicitation of processes. By elicitation, we mean the specification of processes, the identification of problems and bottlenecks and their requirements for improvement. The tool embedded the support to the necessary interaction among workers in order to express their knowledge about the process and to reach the consensus about what needs to be improved and where. It is important to understand an existing process before projecting a new one. There are at least four reasons to document the existent processes before proceeding to the innovation: the understanding of the existent processes facilitates the communication among the participants; in many complex organizations there is no way to implement new processes without understanding the existing ones; the recognition of the problems of a process helps to avoid its repetition in the new process; and the understanding of the current processes provides a measure of the value of the process improvement proposal. Frequently organization processes were never described, or viewed as processes. The analysis provides an opportunity to report problems that may have been occurring for a long time. The examination of the process shows bottlenecks, redundancies and unnecessary activities that were not recognized before. The improvement, simplification and rationalization opportunities are born from these detailed analyses of the processes. A graphic representation of the interfaces and components of the process have great value, mainly as a communication media that can be used to document the evolution of the flow of work, as long as the simplification techniques are applied. The documentation and analysis of the processes are seen as an interactive activity. In that context, the groupware tools are suitable to improve the interaction and to facilitate the communication among the members of a team, in a process improvement project. The cooperative editor CEPE was conceived and developed to support the phase of elicitation of processes in the participatory process improvement. Its main characteristic is to allow the representation of multiple views for the same element or group of elements. It represents the different visions, from different sources in the same document, that is, in the same map of processes. CEPE is essentially graphical; it makes use of icons to represent comments to the elements and awareness mechanisms to increase the quality of the interaction within the work team. Although we have used it in experimental situations, we believe that much can be learned when the tool is used in real Process Improvement projects. We are especially interested in finding out whether the interaction among workers really contributes to the enhancement of the process improvement work and to increased cooperation among workers. Acknowledgements. This work was partially supported by the CNPq (Brazil), grant Prosul AC-62. Flavia Santoro was sponsored by FAPERJ (project number E26/152.116/2001).

246

R.M. de Freitas et al.

References [1] Harrington, J.H., 1991, “Business Process Improvement: The Breakthrough Strategy for Total Quality, Productivity, and Competitiveness”, McGraw Hill, New York [2] Case, J., 1995, “Open-Book Management; The Coming Business Revolution”, New York: HarperBusiness [3] Chaffey, D.: “Groupware, Workflow and Intranets – Reengineering the Enterprise with Collaborative Software”, Digital Press, Boston, MA, 1998 [4] Hammer, M. and Champy, J.: “Reengineering the Corporation: A Manifesto for Business Revolution”, Harper Collins Pub, New York, NY, 1993 [5] Poh, H.L. and Chew, W.W.: "Business Process Reengineering: Definitions and Models Revisited". http://www.iscs.nus.sg/~isasia/Paper/complete.html [6] Clark, A.S., Downing, C.E. and Coleman, D.: “Groupware at Big Six Consulting Firms: How Successful was it?”, In Groupware: Collaborative Strategies for Corporate LANs and Intranets, ed. By D. Coleman, Prentice Hall PTR, 1997, pp. 533–561 [7] Gatermann, M. and Krogh, H.: "Special Report on Reengineering" (in German). Manager Magazine 12 (1993), pp. 117–214 [8] Schnitt, D.: "Reengineering the Corporation Using Information Technology", Journal of Systems Management, January 1993 [9] Borges, M. and Pino, J.A., “PAWS: Towards a Participatory Approach to Business Process Reengineering”. Proceedings of the CRIWG’99, Fifth International Workshop on Groupware, pp. 262–268, Cancún, Mexico, September 1999. IEEE Computer Society Press, Los Alamitos, CA, 1999 [10] Santoro, F.M., Borges, M.R.S., Pino, J.A., 2000, “CEPE: Cooperative Editor for Processes º Elicitation”. In: Proceedings of 33 Hawaii International Conference on Systems Sciences – HICSS’2000, Hawaii, EUA [11] Groupkit – http://www.cpsc.ucalgary.ca/projects/grouplab/projects/GroupKit.html

[12] Herrera, C., Borges, M.R.S. and Pino, J.A., 2000, "CESD: Participatory Selection of Business Process Designs", CSCW-D The Fifth International Conference on Computer Supported Cooperative Work in Design, Hong Kong [13] Mouro, E., Borges, M. and Garcez, C., 1999, ”A Groupware Tool to Support Participatory Business Process Reengineering”, Proceedings of International Workshop on Groupware– CRIWG’99, IEEE Computer Society, Cancun, Mexico [14] Freitas, R. M., Ribeiro, L. G., Ribeiro, M. M. G. e Borges, M. R. S., 2002, “CEPE: Um Editor Cooperativo para Elicitar Processos”. Proceedings of XVI Simpósio Brasileiro de Engenharia de Software, pp. 360–365, Gramado, Brazil [15] Swenson, Keith D., 1993, “Visual Support goes Reengineering Work you Process”. Proceedings of the Conference on Organizational Computing Systems. [16] Dias, M.S. & Borges, M.R.S., 1999, "Development of groupware systems with the COPSE infrastructure", Proceedings of International Workshop on Groupware – CRIWG’99, IEEE Computer Society, Cancun, Mexico [17] Freitas, R.M., 2003, “Reengenharia Participativa apoiada por uma ferramenta de groupware: CEPE, um editor cooperativo para a elicitação de processos”, 2003, M.Sc. Thesis, Universidade Federal do Rio de Janeiro, Rio de Janeiro, Brazil

Improving the Use of Strategies in Computer-Supported Collaborative Processes César A. Collazos*, Luis A. Guerrero, José A. Pino, and Sergio F. Ochoa Department of Computer Science Universidad de Chile Blanco Encalada 2120, Santiago, Chile {ccollazo,luguerre,jpino,sochoa}@dcc.uchile.cl

Abstract. The members of a work group need to apply a common strategy to collaboratively solve a problem. A good strategy will mainly depend on the collaboration scenario, participants’ background, and available tools. This paper presents two widgets that have been useful to help to define and use good group members’ strategies in collaborative learning scenarios. The concepts behind these widgets can be reused to support strategy definition processes in order to improve the efficiency and effectiveness of computer-supported collaborative processes

1 Introduction Computers have become very important to support group work and collaboration. People interact with other people in all aspects of life and, as computers have become prevalent, users seek computer support to extend their interactions. Besides, advances in networking technology and software systems will lead to an emphasis on interpersonal computing. Understanding group dynamics and the collaborative process of work groups are then both interesting research fields and the basis for new tools to support the findings. In this scenario, the computer supported collaborative learning process has received much care [15]. In this process, the results of learning activities depend not only on the student’s skills to execute a task, but also on the strategy of collaboration with teammates to do it. The use, understanding and adoption of a strategy are crucial for an effective and efficient collaborative learning. In a series of preliminary experiments in Computer-Supported Collaborative Learning (CSCL) environments, it has been observed that groups with little experience in collaborative work, understand, use and adopt cooperation strategies in a bad manner [8]. In these experiments, although all groups were deficient in the strategy definition, those that tried to define and communicate a strategy got better results in CSCL activities. Based on this preliminary information, our work explores whether *

On leave from FIET, Universidad del Cauca, Colombia.

J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 247–260, 2003. © Springer-Verlag Berlin Heidelberg 2003

248

C.A. Collazos et al.

the impact of a consistent use of a strategy can produce good results during this kind of activities. Our hypothesis claims a good use, definition and adoption of strategies should imply good collaboration, which in turn it is known to lead to good learning. This hypothesis is emphasized in the case of groups just formed or with little collaborative experience. We have designed a widget to support discussions within the learning group and another one to support monitoring the tasks done by the group. These widgets are intended to improve the strategic aspect of group work and thus, they provide a way to validate the hypothesis. Both widgets were embedded in a tool called TeamQuest, which is a labyrinth type collaborative game. Two versions of this tool were used during the experiments, one with widgets and another one without them. The performance of the learning activities was measured by using the indicators proposed by Collazos et al. [8]. The participants in the experimental activities were primary school students. Next section presents related work about methods to promote the use of strategies in CSCL activities and the justification of our proposal. Section 3 describes the preliminary study that originates this proposal and the results obtained from such study. Section 4 presents the TeamQuest tool and the widgets developed to improve the use of strategies. Section 5 describes the experiments carried out in order to measure the impact of consistent strategy use over a CSCL activity, and the obtained results. Finally, Section 6 presents the conclusions and future work.

2 Background Since the advent of computer supported collaborative work, CSCL research has been of major interest. It has been conclusively argued that a focus on the process of collaboration is necessary in order to understand the value of working together with peers for learning [20]. CSCL is a research area that reports a great amount of scientific work in several aspects. Unfortunately, there are no studies focused on how to improve the use of strategies in collaborative activities using computer technology. Collaborative learning technologies must go beyond generic groupware applications, and even the basic technology is not yet well developed [24]. Therefore, it is necessary to define a model describing how to design socio-technical environments that will promote collaboration within groups. From the collaborative work viewpoint, effective groups have goals being clarified and modified as follows. There should be the best possible match between individual and group goals. They are also cooperatively structured so all members are committed to reach them. Results of experimentation have shown groups were ineffective because communication was poor. This could be explained by lack of strategy understanding shown by some members of the group. Thus, it is not only important to understand the problem, as Dillenbourg mentions [12], but to be aware that the rest of the people can understand the problem situation during a collaborative activity. Soller et al. [23] claim the way in which a student shares new knowledge with the group and the way in which the group responds are important. They determine to a large extent how well this new knowledge is assimilated into the group, and whether or not the group members learn the new concept. Also, as Clarck & Schaefer [3] men-

Improving the Use of Strategies in Computer-Supported Collaborative Processes

249

tion, for co-construction to occur, participants must not only make a contribution, but must also get their contribution to be accepted by their partners. Team potential is maximized when all group members participate in discussions. Building involvement for group discussions increases the amount of information available to the group, enhancing group decision making and improving the participants’ quality of thought during the work process [16]. Therefore, encouraging active participation could increase the likelihood that all group members understand the strategy, and decreases the chance that only a few participants understand it, leaving the others behind. Unfortunately, none of the observed groups of the reported experiment behaved in this direction [8]. Based on that finding, we have designed a software tool including widgets intended to improve the strategy performance of the groups during a collaborative activity.

3 Preliminary Work Collazos et al. have defined five indicators which evaluate several aspects of the collaborative learning process [8]. Four of the indicators of collaboration (IC) are based on these activities proposed by Johnson et al. in [1]: use of strategies (IC1), intragroup cooperation (IC2), checking the success criteria (IC3), and monitoring (IC4). The fifth indicator is based on the performance of the group (IC5). Specifically, IC1 tries to capture the ability of the group members to generate, communicate and consistently apply a strategy to jointly solve a problem. IC2 corresponds to the use of collaborative actions in order to provide help when anyone requests it. IC3 measures the degree of involvement of the group members in reviewing boundaries, guidelines, roles and the main goal during the group activity. The objective of IC4 is to oversee if the group maintains the desired behavior to solve the problem, keeping focused on the goals and the success criteria. IC5 corresponds to the quality, time and work of the group activity. These indicators were used to evaluate the collaboration process in a CSCL scenario at a basic school by using two similar tools, namely Chase the Cheese [8] and TeamQuest [9]. The scenario and participants used in the experimentation were comparable, and the results in both situations were similar. Table 1 presents a summary of these results. Analysis of these results shows the shared construction of a strategy to do group work is related to a successful process, to the individual construction of cognitive context, and to the experiences shared by the group members. It could be indicating a tendency. Unfortunately, the studied groups were ineffective collaborative groups because they were weak in collaborative attitudes, and this aspect is reflected somehow in the wrong process of definition, adoption and use of strategies. In order to explore the strategy use influence on the collaborative process results, the experiment specified in [9] was repeated in a controlled scenario. The new experiment involved the same tool, but two widgets were included. These widgets were designed to promote and enhance the use of a strategy during the collaborative process. Next section describes the tool used in the experiments.

250

C.A. Collazos et al.

Table 1. Results of previous experiments according to the collaboration indicators1. IC1: Use of Strategies; IC2:Intra-goup cooperation; IC3: Checking the success criteria; IC4: Monitoring; IC5: Performance. Group

IC1

IC2

IC3

IC4

IC5

0 1 2 3 4 5 6 7 8 9 10

0.69 0.31 0.68 0.48 0.71 0.75 0.71 0.47 0.27 0.28 0.48

0.69 0.71 0.62 0.61 0.74 0.84 0.72 0.80 0.75 0.75 0.80

0.20 0.20 0.20 0.50 0.80 1.0 1.0 0.20 0.20 0.20 0.20

0.75 0.80 0.80 0.74 0.78 0.86 0.85 0.80 0.82 0.81 0.83

0.65 0.57 0.69 0.63 0.66 0.61 0.52 0.53 0.54 0.54 0.53

4 TeamQuest TeamQuest is a collaborative game which is played by four persons, each one with a computer. The computers are physically distant and the only communication allowed is computer-mediated. All activities by participants are recorded for analysis and players are made aware of that. The game goal is to go from an initial to a final position through a labyrinth, with the highest possible score, avoiding obstacles and picking the necessary items to carry out the mission in the way. The time spent in the trip is also considered only in case of a tie. Each member of the work group can see only a portion of the game scenario. The members’ information needs to be shared if the group wants to achieve its goal. That aspect corresponds to the positive resource interdependence, which relies on the fact that each individual owns specific resources needed for the group as a whole to succeed [17]. The difficulty level of the game - which can be adjusted - is relatively high. Therefore, the group must define and apply a good strategy in order to solve the labyrinth. The participants are given very few details about the game before playing, and they must discover most of the rules while playing. They also have to develop joint strategies to succeed. The players of a team must reach a common goal satisfying sub-goals in each of the four game stages. Each player is identified with an avatar and name (Fig. 1). The TeamQuest main user interface has three well-defined areas: labyrinth, communication and information. The labyrinth area has four quadrants, each one assigned to a player who has the “doer” role (active player), while the other three players are collaborators for that quadrant. In a quadrant, the doer must move the avatar from the initial position to the “cave” that allows pass to the next quadrant. In the way, the doer

1

Lowest score is 0.0 and highest score is 1.0

Improving the Use of Strategies in Computer-Supported Collaborative Processes

251

must circumvent all obstacles and traps of the map (these obstacles are not visible to all players). Moreover, the doer must pick items useful to reach the final destination. The user interface has many elements showing awareness: the doer’s icon, score bars, items which were picked up in each quadrant, etc. (Fig.1). The communication zone is located at the right hand side of the main screen and it has several windows with faces characterizing each participant avatar. Each participant has a window to write text messages, a receiver selector, and a send button. Also, there are three other windows, similar to the message writing window, which display the messages received from the other players. The information zone displays information about the game status, obstacles, traps, individual views of the game, and game final results.

Fig. 1. TeamQuest user interface

The team game score is computed based on the individual score of each player, shown in the score bars. These individual scores start with a predefined value and they are reduced or increased whenever a player’s avatar collides with a trap or gets a reward (life potion). The group final score is the addition of the individual scores. This tool was used in the experiments mentioned in section 3, which have shown group deficiencies in the definition and use of a strategy to carry out the play. Thereafter, additional elements were designed and included in the software tool with the goal to improve the use of strategies. Next two sections present the new elements that were embedded in TeamQuest to enhance these activities. These elements were called negotiation table and monitoring window. 4.1

Negotiation Table

The negotiation table is a discussion environment. Group members can use it during a break. Breaks may be done at any time during the play. They provide opportunities for

252

C.A. Collazos et al.

analysis of the work done, thus allowing the definition and reinforcement of the common goals. Establishing common goals is part of constructing common grounds, since actions cannot be interpreted without referring to the shared goals, and reciprocally, goal discrepancies are often revealed through disagreements on action [14]. Members of a group do not only develop shared goals by negotiating them, but they also become mutually aware of these goals. The strategy the group must use to solve the problem is not the same if individually decided by each group member. If it is going to be shared the strategy has to be decided somehow and then communicated, understood, and - to some extent- it has to be agreed by all members of the group [5]. As Dillenbourg & Self mention, if strategic decisions are necessary, they will be object of explicit agreement like any other decision made by the members of a group [13]. Hence, the first need is for a shared environment in which communication and discussion is possible. Statement, definition and discussion of strategies may then occur. Moreover, the tool should stimulate this discussion in several occasions. Of course, the break should not be penalized: while using the negotiation table, the play chronometer remains stopped. We have included an initial Negotiation Table, where the group members must decide a group name. The user who creates a new game session accesses directly to the negotiation table and becomes its main user. This user must also coordinate the first activity of the game, which is to give a name to the group (positive interdependence of identity). Subsequent players entering the game are directed to the negotiation table. The negotiation table has a chat tool, which allows group members to discuss in order to reach an agreement. The controls marked with (1) and (2) in Fig. 2 are parts of this tool. Typically, a player begins the group naming by making a proposal and the discussion then starts. The discussion finishes when the group members have agreed on the name. Then, the main user inserts the agreed group name in the designated area (marked with (3) in Fig. 2). The rest of the players must indicate on their windows if they accept or reject the group name. The normal users have a similar but not identical user interface than the one of the main user. The normal user window does not have the button marked with (4) in Fig. 2, but they have two other buttons to accept or reject the proposed group name in the area (3). Once all participants have agreed the group name, the game can actually start. The main user will push the play button and automatically the user interface of the play scenario is shown to the participants (marked with (5) in Fig. 2). This is the front door of the game. A group is never forced to have a explicit working strategy before solving the labyrinth. It is expected the own players realize this need and use the negotiation table at will. All interactions will be done through text-based dialogs. Researchers in linguistics, pedagogy and artificial intelligence have argued that dialog may be best regarded as a type of joint activity [6, 7]. Participants derive explicitly or implicitly a common set of beliefs about the activity, and they drive towards mutual understanding of their intentions and actions -a process referred to as grounding [4]. As Paek and Horvitz mention, in a joint activity, it is not enough to just produce utterances; speakers must check that their utterances were attended to and that listeners are still engaged in the activity at hand [21]. In that sense, the negotiation table provides an environment that supports dialogs, discussions and interchange of ideas. This tool is available at any time by just doing a “click” at the play scenario. If the group members consider the defined strategy is not working, they can revise it or redefine it using the negotiation table.

Improving the Use of Strategies in Computer-Supported Collaborative Processes

253

On the other hand, discussion and other interaction activities are promoted or at least not punished by stopping the chronometer while the team is at the negotiation table. Thus, TeamQuest tries to promote the existence of active players working in the definition, maintenance and review of strategies to carry out collaborative activities. Bloom & Broder say the major difference between the successful and the nonsuccessful problem solvers in their extent of thought about a problem is in the degree to which their approach to the problem might be passive or active. A passive problem solver typically reads the problem, chooses one way to solve it and keeps trying this way even if it fails. These people are not good for collaborating. On the other hand, a more active problem solver re-analyzes frequent problems and backtracks to alternative solution paths in order to improve their strategy [19]. This strategy can only be partially set up at the outset of collaboration, it has to be negotiated and probably revised as work progresses. In this context, the negotiation table provides a mechanism to regulate the interactions.

Fig. 2. User interface of TeamQuest negotiation table (in Spanish)

As we mentioned at the beginning of this section, the Negotiation Table can be used at any time during the play. This option can be selected by any member of the group or by the facilitator. Whenever this option is selected, the person who choice it will be the main user and will decide the topic of the Negotiation Table. This person or the facilitator will also define how to reach the conclusions of the negotiation. 4.2

Monitoring Window

TeamQuest has, besides the four players, a fifth role called the wizard, e.g., Isenhart in Fig. 1. At the beginning of the game, this wizard tells the group a story before the labyrinth resolution as a motivation. An example of these stories is the kidnapping of

254

C.A. Collazos et al.

a princess who must be liberated by the group avoiding mortal traps and by killing a dragon (fantasy positive interdependency). During the play, this wizard gives tips and suggestions to the players. They see it then as an intelligent agent on their side. What game players do not know is that another person – a cognitive facilitator – can also be connected. This fifth “player” has a user interface similar to the other ones and can monitor everything that is happening in the session. The facilitator can also send messages to the whole group or to a player in particular. Therefore, the facilitator can to help the group to define, discuss or improve the strategy used to solve the problem. The group members typically think the wizard in fact sends the facilitator’s messages. One way of assessing the effectiveness of the groups is to monitor the members’ interactions as they work together. Observations allow to measure and to understand the quality of each group interaction and its progress on the assignment [10]. The facilitator not only can observe the interactions among members of the group, but also she can intervene anytime she considers it as necessary. In that way, the facilitator can become another member of the group. According to Johnson et al., one of the most important aspects of collaborative learning is to “monitor students’ learning and intervene within the groups to provide task assistance or to increase students’ interpersonal and group skills” [17]. A teacher systematically observes and collects data on each group as it works. When assistance is needed, the teacher intervenes to assist students in completing the task accurately and in working together effectively. A tutor is needed to structure the process, to give advice when needed and to promote deep understanding. If students and tutors are communicating mainly through a computerized learning environment, tutors have to learn new ways to support students. While observing students working with computer applications, teachers can see the choices students are making, ask questions regarding students’ learning goals and decision making, and make suggestions for revisions when needed. With this model, applications can be designed to provide a window on the ways in which students construct meaning -their misconceptions, conjectures, and the connections they make among ideas [11]. Teachers can use this information to revise and refine instruction. The cognitive facilitator proposed with TeamQuest can be a teacher or any person with experience in collaborative work. This facilitator has an important role as a stimulating agent in the process of group members’ incorporation of general behavior patterns. Some of these patterns are: definition of an initial strategy, and the periodic review of the obtained partial results. The facilitator’s influence is expected to be large on groups with little experience in collaborative work. If participants acquire these behavior patterns, the facilitator can decrease her influence. In such a case, this means the participants have learned how to collaborate. It also implies perhaps they will not need a facilitator to improve their strategies in a near future.

5 A New Experiment A new experiment was done with the same tool (TeamQuest). It includes one of the two widgets: the negotiation table. The participants were students from four schools from Popayán – Colombia: Politécnico Empresarial Andrés Bello, Comfacauca, Champagnat, and Empresarial del Cauca. Twenty students were selected from these th schools. All of them were high school seniors (4 grade) and were familiarized with

Improving the Use of Strategies in Computer-Supported Collaborative Processes

255

computer usage. The students selection took into account the previous groups and work settings in order to have comparable results. The experiment lasted three consecutive days, working three hours each day. Five 4-persons groups were assembled. One of the groups was a control group. The goal of the experiment was to check if groups using the negotiation table improved their abilities to adopt strategies to solve the labyrinth or not. These new groups were numbered from 11 to 14, while the control group received number 15. Groups No. 11 and 12 used TeamQuest with the widget, whereas groups No. 13 and 14 used standard TeamQuest. Groups No. 1-10 were the old groups, using the standard TeamQuest (results of their work were reported in Section 3 above). The performed activities are described below. 5.1

Experimentation Process

The experimentation process involved three stages: pre-test, test and post-test. There was no computer support for pre- and post-test. The test involved the use of computers and TeamQuest. The control group participated in the pre- and post-test. The work was done on February 14, 15 and 16, 2003, 8:00 AM-11:00 AM. The activities carried out in each stage are briefly described below. Stage 1 (Pre-test). The goal of this stage is to evaluate the participants’ abilities to carry out collaborative tasks. This basic knowledge helps the experimenters to improve their understanding of the results. The activities involved in this stage are the following:

Make an introduction (15 minutes). The experimenters introduced themselves and explained the goals of the experiment. Apply 16PF2 test to determine each participant’s personality characteristics (45 minutes) Define groups and distribute materials (10 minutes). Develop the collaborative activity. It was based on the “group investigation” technique [22]. This technique involves the following sub-activities: - Each group receives the same folder with information concerning the subject of investigation. Each group member is responsible of a part of the subject. The group must organize the available information within 20 minutes. Each group decides where to work: inside or outside a spacious room. - Each person must then study her assignment in 30 minutes. - Afterwards, the group meets again. Each member makes a presentation about her part of the subject to the rest of the members of the group (40 minutes). 2

The 16PF® Questionnaire is used by organizations and human resource professionals to assesses the 16 personality factors. The assessment measures levels of Warmth, Reasoning, Emotional Stability, Dominance, Liveliness, Rule-Consciousness, Social Boldness, Sensitivity, Vigilance, Abstractedness, Privacy, Apprehension, Openness to Change, Self-Reliance, Perfectionism and Tension. Five additional global factors are also measured: Extraversion, Anxiety, Tough-Mindedness, Independence, and Self-control.

256

C.A. Collazos et al.

-

Finally, a knowledge acquisition test on the subject is applied to all groups. A randomly chosen group member represents her group. Her grade will be the group grade (20 minutes). This evaluation method was explained during the introduction.

The evaluation process was done immediately before Stage 1 was concluded. The evaluators were the same people each time. The range for the final grade was from 0.0 (lowest) to 5.0 (highest). Stage 2. The second stage involves the test activity using TeamQuest for the groups described at the beginning of this section. A control group does not participate in this activity. The activities involved in this stage are the following tasks:

Define groups (30 minutes).

Do the collaborative activity TeamQuest (90 minutes).

Make a survey and ask for final comments (30 minutes).

Group members were distributed in two computer laboratories. Teaching assistants were available to help in case of any technical difficulty.

Stage 3. Finally, the post-test tries to assess if group members have improved their collaboration abilities through the use of TeamQuest, with and without the widget. The way in which this stage is evaluated is the same as for stage 1. The activities involved in this stage were the following ones:

Define groups, one of which is the control group (10 minutes).

Develop a “group “investigation” activity, following the same sequence presented while describing stage 1. The subject to be evaluated was changed in order to maintain similarities between both stages.

5.2

Results

Table 2 presents the results obtained by the groups of this experiment, during pre-test and post-test. Table 3, on the other hand, presents the results of the test; these results must be compared with the results of the previous experiment (see Section 3). Table 2. Results of the pre- and post-test stages 3

3

Group number

Pre-test score

Post-test score

11 12 13 14 15 (Control )

3.0 3.5 3.6 2.8 3.4

4.2 3.8 3.5 2.5 3.2

Lowest score is 0.0, highest score is 5.0, and minimal approval score is 3.0.

Improving the Use of Strategies in Computer-Supported Collaborative Processes

257

Table 3. Results during the test stage4. IC1: Use of Strategies; IC2:Intra-goup cooperation; IC3: Checking the success criteria; IC4: Monitoring; IC5: Performance Group

IC1

IC2

IC3

IC4

IC5

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14

0.69 0.31 0.68 0.48 0.71 0.75 0.71 0.47 0.27 0.28 0.48 0.70 0.68 0.48 0.48

0.69 0.71 0.62 0.61 0.74 0.84 0.72 0.80 0.75 0.75 0.80 0.80 0.80 0.62 0.64

0.20 0.20 0.20 0.50 0.80 1.00 1.00 0.20 0.20 0.20 0.20 0.80 0.80 0.20 0.20

0.75 0.80 0.80 0.74 0.78 0.86 0.85 0.80 0.82 0.81 0.83 0.83 0.82 0.74 0.75

0.65 0.57 0.69 0.63 0.66 0.61 0.52 0.53 0.54 0.54 0.53 0.60 0.59 0.64 0.65

Average St. Deviation

0.54 0.17

0.73 0.08

0.45 0.33

0.80 0.04

0.60 0.06

These results show Groups No. 11 and 12 obtained the best results. These groups had available the TeamQuest negotiation table feature. This would confirm our hypothesis. 5.3

Analysis of Results

The previous experiment did not include the monitoring option. This was because we did not want to influence the results of the collaborative process measured by the indicators (a facilitator would be involved). Nevertheless, we did some additional experimentation trying to have an idea on the usefulness of that widget. We could check that according to what we expected, the participants were not aware of the input provided by the facilitator. They thought they received suggestions from an intelligent agent (the wizard) and accepted them most of the time. This was natural, since the wizard does provide help on game actions and their consequences. The facilitator does not have to cheat on this: simply the facilitator’s role is similar to that of the wizard. Thus, their written sentences may be undistinguishable. Of course, this ambiguity implies facilitators have to follow strict rules concerning when to monitor and what actions to suggest. The role of the wizard and facilitator is to maintain the focus of the discussion, guiding students through the knowledge constructing process. The assumption is both the contents and the pattern of the sequence

4

Lowest score is 0.0 and highest score is 1.0.

258

C.A. Collazos et al.

of messages reflect the degree of collaborative learning. In this aspect, the idea is not to provide the right answer or say which person is right, but to perform a minimal pedagogical intervention (e.g., provide hints). This intervention is to redirect the group work in a productive direction or to monitor which members are left out of the interaction in order to define a strategy [14]. Participants selected for the new experiment were chosen as similar as possible to those of the previous experiment. They belong to schools with the same socioeconomic profile, they have similar knowledge background and are of the same age. Group definition was made in such a way to have members from all schools, without any previous acquaintance for each group. The group with best performance for most collaboration indicators from both experiments is Group No. 5. They are students from the same school and they work together since some time ago. It is then no surprise they have implicit strategies. The interesting conclusion is the very good results of groups using the negotiation table in the new experiment, which were composed of students who did not know each other beforehand. Another interesting conclusion appears when taking into account results from the 16PF test. As mentioned above, this test evaluates personality features and individual ability [2]. The student with the best score belongs to group No. 13. In fact, the groups with the best collaboration results did not include the best 16PF achievers. One concludes the only free variable when considering the new experiment is the use of the negotiation table. Of course a scientifically valid final conclusion should involve a larger number of groups and a statistical test. The way of stimulating strategy adoption presented in this paper could also be used in other collaborative environments requiring strategies for the achievement of a task or development of a product. Similar widgets could be created for this purpose.

6 Conclusions and Future Work As reported at the beginning of this paper, one of the deficiencies found in the analysis of the interactions among group members of the previous experiment was subjects’ inability to state, use and discussion of strategies. This was a key obstacle for effective and efficient collaborative work. The new similar experiment with a negotiation table and a monitoring window has presenting initial evidence that groups using these widgets have a better performance. Using monitoring mechanisms allows the teacher to guide the students about the development of strategic abilities to get a good collaboration process. The teacher’s role must be very clearly defined in these activities. A collaboration scenario must be defined; the teacher has to know when and how to intervene with the goal of improving the collaborative process. As Katz mentions, one of the main problems for a teacher in a collaborative environment is to determine when to intervene and what to say [18]. It is clear the following collaborative abilities at least should be stimulated: to give and to receive, to help, to receive feedback, to identify conflicts or disagreements. Our hypothesis stating good use, definition and adoption of strategies should imply good collaboration has proved to be true in our experiment. Further work is needed to definitely make a general conclusion applicable to Collaborative Learning with new

Improving the Use of Strategies in Computer-Supported Collaborative Processes

259

experiments. Meanwhile, the same type of stimulus and widgets could be developed for other collaborative scenarios. We defined our Negotiation Table as a mechanism intended for discussion. Any member of the group can select it during a break; the clock is the stopped so that the use of the Negotiation Table is not penalized in time. Additional experiments could be made to observe and measure the effect of time pressure on the negotiation process for strategy definition, since in our reported experiments the clock was stopped during the negotiation. Another feature of the Negotiation Table could be a mechanism for reviewing the plays performed during some previous period. The mechanism would display an animation of the game moves and the interchanged messages. This feature would also allow group members to learn from the good and bad news they made. Acknowledgments. This work was supported by Fondecyt (Chile) grant Nº 1030959 and graduate thesis scholarship No.49 from Departamento de Postgrado y Postitulos, Universidad de Chile (2002).

References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11]

[12] [13]

Adams, D. & Hamm, M., Cooperative Learning, Critical Thinking and Collaboration across the Curriculum. Second Edition, 1996 Cattell, R.B., Personality structure and the new fifth edition of the 16PF. Educational & Psychological Measurement, 55(6), 926–937, 1995 Clarck, H., & Schaefer, E., Contributing to discourse. Cognitive Science, Vol. 13, pp. 259–294, 1989 Clark, H., & Wilkes-Gibbs, D, Referring as a collaborative process. In Intentions in Communication, pp. 463–493, MIT Press, 1990 Clark, H., Managing problems in speaking. Speech communication, Vol. 15, pp. 243–250, 1994 Clark, H., Using language. Cambridge University Press, 1996 Cohen, P, Levesque, H., Preliminaries to a collaborative model of dialogue. Speech Communication, Vol. 15, pp. 265–274, 1994 Collazos, C., Guerrero, L., Pino, J., & Ochoa, S., Evaluating Collaborative Learning Processes. In J. Haake and J.A. Pino (Eds.): Groupware: Design, Implementation and Use. Lecture Notes in Computer Science 2440, 2002, pp. 203–221 Collazos, C., Guerrero, L., Pino, J., & Ochoa, S., A Method for Evaluating ComputerSupported Collaborative Learning Processes. International Journal of Computer Applications in Technology (IJCAT). To appear during 2003 Collazos, C., Guerrero, L., & Pino, J., A Computational Model to Support the Monitoring of the Collaborative Learning Process. Accepted for International Journal of Learning Technology (IJLT), 2003 Collins, A., The Role of Computer Technology in Restructuring Schools. In K. Sheingold & M. S. Tucker (Eds.), Restructuring for learning with technology. New York: Center for Technology in Education, Bank Street College of Education, and National Center on Education and the Economy, 1990 Dillenbourg, P., Baker, M., Blake, A. & O’Malley, C., The Evolution of Research on Collaborative Learning. In Spada, H. and Reimann, P. (editors), Learning in Humans and Machines, 1995 Dillenbourg, P., & Self, J., Designing human-computer collaborative learning. In C.E. O’Malley (Ed). Computer Supported Collaborative Learning. Hamburg: Springer-Verlag, 1995

260

C.A. Collazos et al.

[14] Dillenbourg, P., What do you mean by collaborative learning?. In P. Dillenbourg (Ed). Collaborative Learning: Cognitive and Computational Approaches. Pp. 1–19, Oxford:Elsevier, 1999 [15] Hoppe, U., Pinkwart, N., Lingnau, A., Hofmann, D., & Kuhn, M., Designing and Supporting Collaborative Modelling Activities in the Classroom. In: Information and Communication Technologies in Education Volume I, A. Dimitracopoulou (ed.), Proceedings rd of 3 HICTE, 26-29/9/2002, University of the Aegean, Rhodes, Greece, KASTANIOTIS Editions, Inter@ctive, pp.185–190 [16] Jarboe, S., Procedures for enhancing group decision making. In B. Hirokawa and M. Poole (Eds.), Communication and Group Decision Making, pp. 345–383, Thousand Oaks, CA:Sage Publications, 1996 th [17] Johnson, D., Johnson, R., & Holubec, E., Cooperation in the classroom, 7 edition, 1998 [18] Katz, S., & O’Donell, G., The cognitive skill of coaching collaboration. In C. Hoadley & J. Roschelle (Eds.), Proceedings of Computer Supported for Collaborative Learning (CSCL), pp. 291–299, Stanford, CA., 1999 [19] Lochhead, J., Teaching analytic reasoning skills through pair problem solving. In J.W. Segal, S.F. Chipman and R. Glaser Thinking and learning skills. Volume 1: Relating instruction to research. Lawrence Erlbaum, Hillsdale, NJ, pp.109–131, 1985 [20] Muhlenbrock, M., & Hoppe, U., Computer Supported Interaction Analysis of Group Problem Solving. In Hosadley & Roschelle (Eds.), Proc. of CSCL’99, pp.398–405, Dec. 1999 [21] Paek, T., & Horvitz, E., Uncertainty, utility and misunderstanding: A decision-theoretic perspective on grounding in conversational systems. In AAAI Fall Symposium on psychological model of communication in collaborative systems, Cape Cod, MA, Nov. 5–7, 1999 [22] Sharan, Y., & Sharan, S., Group Investigation in the cooperative classroom. In: Sharan, S. (Ed.).Handbook of Cooperative Learning, pp. 97–114. New Jersey: Greenwood Press. 1994 [23] Soller, A., Wiebe, J., & Lesgold, A., A machine learning approach to assesing knowledge sharing during collaborative learning activities. Proceedings of Computer Supported Collaborative Learning, Boulder, CO., pp.128–137, 2002 [24] Stahl, G., Groupware Goes to School. In J. Haake & J. Pino (Eds.) Groupware: Design, Implementation and Use, Lecture Notes in Computer Science 2440, 2002, pp. 1–24, 2002

Supporting Complex Decision Making Processes with Collaborative Applications – A Case Study 1

1

Patrick Brézillon , Frédéric Adam2, and Jean-Charles Pomerol 1

2

Laboratoire d’Informatique de Paris 6 (LIP6) Université Pierre et Marie Curie, Paris, France [email protected] [email protected] Department of Accounting, Finance and Information Systems University College Cork, Ireland [email protected]

Abstract. There has been much research on the design of Groupware, its potential benefits and the methods used to develop systems to support groups. However, in many real life cases, identifying tangible benefits and demonstrating improvements in the quality of decision making after introducing such systems has proven difficult. In this paper, we present the case study of a newspaper firm in order to analyse the impact of a recently introduced collaborative computer system, implemented to support the information search, storage, organisation and dissemination activities of organisational actors. We found that the implementation of the new groupware systems has revolutionised the process of creation of the newspapers and given more time and greater control to the Editorial team. We conclude that when collaborative systems are designed that are closely matched to the needs of the group they serve, tangible benefits should be clearly observable. However, the development of these systems may take much time as the idiosyncratic manner in which specialised groups operate can be very difficult to properly and completely analyse.

1 Introduction – Why Studying Groups and Why Groupware? Research on the way people behave when associated with others as against when on their own started as early as the 19th century when Gustave Lebon [1] described the psychology of the ‘Crowd’ where individuals lose their conscious personality and adopt and follow a sort of collective mind to form a new “living being”. Since these initial theories, more observations have shown that individual behaviour changes to conform to the norms of the group [2]. This tendency is greater when the size of the group increases, and in decentralised, rather than centralised organisations. The behaviour of individuals is also influenced by the composition of the group, its track record and the degree of identification of each member with the group as a whole. This can result in individuals feeling under such pressure to conform to the behaviour of other members that they will go against their own opinions and even the J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 261–276, 2003. © Springer-Verlag Berlin Heidelberg 2003

262

P. Brézillon, F. Adam, and J.-C. Pomerol

evidence of their senses in order to follow the group [3]. Further experiments by Milgram [4] showed that group members find it easier to defy authority together and that peer rebellion provides an example often followed. Furthermore, Janis [5] has coined the term groupthink to describe how groups sometimes suffer from an illusion of invulnerability and excessive optimism and reach decisions which none of them would have reached on their own (as in the Bay of pigs operation). Janis [5] concluded that groups have a tendency to rationalise away data that disprove the group’s assumptions and beliefs, to stereotype competitors as weak, evil and stupid, to apply pressure on members to obtain their agreement and to thrive on the illusion that decisions made are unanimous. Stoner [6] also found that groups systematically accept higher levels of risks than their members would have individually; the risky-shift phenomenon. These research results are quite fundamental given that most decision making processes within organisations are essentially group decision making processes. McGrath [7] concluded that groups are the instruments through which much work gets done (p. 5), but he distinguished different types of social aggregations some of which cannot be regarded as groups because groups are social aggregates that involve mutual awareness and potential mutual interaction. In particular, McGrath suggested that organisations are too large and dispersed for all members to know one another. However, this is a factor that new communication media can influence and the Internet, as a large scale communication medium can enable larger units to behave as groups because they increase the opportunity for interaction between members. As a result, some IS researchers have turned their attention to the support of activities that are carried out by groups of individuals and the investigation of processes which involve the collective action of groups as units of analysis. As IT evolves further and new ways to handle and share information are implemented in organisations, there will be more scope to support the work of managers and Greenberg's [8] vision of the field of CSCW is one of a discipline seeking to produce theories of how people work together, and how the computer and related technologies affect group behaviour (p. 1).

This vision has resulted in IS researchers looking at the work of other disciplines to provide some theoretical background for the study of group phenomena. The research conducted at Carnegie-Mellon University on Computer-Mediated Communication illustrates how critical group research is for information systems research [9, 10]. This research regards groups as the most suitable unit of analysis for the variety of interactions that take place in organisations. As a result, a number of researchers have studied groups and the effect of computer mediation on the pattern of interaction between individuals within groups [11, 12, 13, 14].

Supporting Complex Decision Making Processes with Collaborative Applications

263

2 Group Tasks and Group Performance The issue of group performance is interesting to managers, especially in commercial organisations where problems must be tackled and solved efficiently as well as effectively. The performance of group work can vary depending on a number of key parameters – such as the nature of the task – to the extent that when the design and structure of organisations are not suited to the tasks to be performed, conflict is more likely to emerge than cooperation between actors. Communication plays a key role in supporting the structuring of organisations so that higher degrees of collaboration result. Groupware systems, when they enable higher levels of communication can play a fundamental role in maintaining robust groups that operate well. 2.1

Classifying Group Tasks

A solid classification of group tasks is instrumental in explaining why some groups perform better than others. Shaw’s [15] survey of tasks used in small group research isolated six dimensions of group task, including (1) properties of the task itself, (2) properties of the group and (3) properties of the context in which the group tackles the task. Hackman [16, 17] concentrated on intellectual tasks, defined as tasks that yield a written product. His results showed that tasks can be categorised as production (when people have to generate ideas), discussion (when people are debating an issue) and problem solving (when people have to put together a plan of action). The nature of the task influences the performance of groupwork insofar as it affect how well the inputs of group members are integrated to produce an outcome. In Eureka type problems, if one person knows the answer, the group is bound to recognise that it is the right one and groups will consistently outperform individuals [7]. Other situations involve the inputs of group members being somehow averaged in the problem solving process [7, 18, 19]. McGrath [7] concluded that most group tasks are complex tasks requiring not so much a summing of members’ outputs as a complicated co-ordination of their efforts (p. 58). Based on this observation and a comprehensive synthesis of existing research, McGrath [7] proposed a model: the Group Task Circumplex (Figure 1). 2.2

Collaboration and Conflict

However, many authors have argued that real-life groups commonly know as many instances of conflicts as instances of co-operation [20]. Easterbrook [20] has even suggested that chaos and anarchy are more reliable models of human interaction than any other to provide a basis for the design of computer supported communication systems. Crozier and Friedberg [21] have described how the supervisory layer of the firm they studied was in conflict with the levels below (operators and maintenance specialists) and above (middle managers). The operators used their maintenance skills to put pressure on their supervisors who were as a result in a weak position vis a vis

264

P. Brézillon, F. Adam, and J.-C. Pomerol

their superiors. Supervisors were in charge of the efficient operation of the plant, but had no expertise to evaluate the time that mechanical repairs should take. They were, therefore, at the mercy of the maintenance crews who dictated their terms and openly threatened them with longer delays if they did not have their way. In such cases, cooperation within groups just does not take place.

Fig. 1. McGrath’s Group Task Circumplex [7]

2.3

Role and Impact of Communication

Seashore [22] has observed that individual behaviour is less likely to deviate from that of other group members when the group is very cohesive. This point has been generalised to individuals’ co-operative behaviour by a stream of research in human behaviour [23]. In particular, it was found that communication and the opportunity to communicate played a decisive role in the establishment of co-operation between people and therefore led to increased co-ordination of efforts [24]. Deutsch and Krauss's [25] experiments where two fictitious transportation companies could either collaborate or enter into conflict and take action to decrease the competitor’s profit demonstrated that communication which involved threats as opposed to communication oriented towards co-operation decreased the collaboration between the two companies instead of increasing it. Thus, not all kinds of communication are beneficial in fostering collaborative behaviour [26]. Organisational Communication and Group Characteristics Bossard [27] has identified that group size is important variable for the analysis of group communication because there is a drastic increase in the number of relationships group members must cope with when group size increases (25 relations for 4 members

Supporting Complex Decision Making Processes with Collaborative Applications

265

and 966 for 7 for instance). This communication overhead can decrease the time available for communication between any two individuals within the group as individuals have to maintain more complex sets of social relationships. Other organisational characteristics affect the communication that takes place amongst organisational actors. In particular, Porter and Roberts [28] noted that the total configuration of an organisation undoubtedly exerts a strong influence on the characteristics of communication within it (p. 1570); the configuration of an organisation being a result of (1) span of control, (2) hierarchical level, (3) organisational size, (4) sub-unit size and (5) administrative intensity [29]. The degree of centralisation of an organisation also has a potential effect on organisational communication. This is examined by looking at the level at which decisions are made and the extent to which subordinates are associated to the decision making process. This depends on the type of decision considered (eg, strategic or otherwise). Hage et al. [30] concluded from their empirical studies that if power is dispersed in an organisation, not only does volume of communication increase, but the flow of communications across departmental boundaries is also increased [30, p. 869]; and Mintzberg [31] noted that in the example of NASA information and decision processes flow flexibly (…) and this means overriding the chain of authority if need be (p.433). Such observations are critical for understanding how to support the decision making processes used by organizational actors. Formal and Emergent Organisational Networks In considering communication within firms, researchers have found useful to differentiate between the formal and emergent structures of organisations [32, 32, 34]. Jablin [29] found that both formal and emergent organisational networks shape organisational communication and Blau noted that [35] When people are thrown together, and before common goals or role expectations have crystallised amongst them, the advantages to be gained from entering into exchanges relations furnish incentives for social interaction, thus fostering the development of a network of social relations and a rudimentary group structure (p.92).

Thus, the prescribed network of an organisation represents the “official” vision of how it should operate. It is often guided by the missions and strategies set by top management [36]. By contrast, the emergent network arises out of every day interaction between actors [34]. The parallel study of these two networks is required in order to explain and understand managerial decision making processes. For instance, in their study of executive information flows, Adam and Murphy [37] found that while emergent flows accounted for only 26% of the flows connecting superiors and subordinates in hierarchical relations, they accounted for 50% of all flows connecting peers (managers at the same level). Knoke and Kublinski [38] proposed a list of the most common types of network which have been investigated by researchers; however, they stated that the number and variability of networks types for potential investigation is probably unlimited and should be selected to fit the goals of the research closely.

266

P. Brézillon, F. Adam, and J.-C. Pomerol

Shape of the Organisational Networks Leavitt [39] and others [23] studied the effect of the shape of networks on group performance (Figure 2). The goal of the experiment was to determine the network shape that would enable members to reach the fastest and best solutions to a given problem and to verify whether centrality was a good explanatory variable for the differences in performance [39]. A

C

B

C

B B

D

D

C D E

A

A

E The circle

The Y

C

B

A

C

E The wheel

E The chain

B

D

D

A

E The comcon

Fig. 2. Network configurations investigated in previous research [40, 23]

The results show that the wheel and the Y networks are the fastest shapes as information is sent to the ‘centre’ of the network (node C) where a decision is made and sent to the outside, but the wheel network tends to be faster. The chain also functions by sending information towards the centre and sending the decision back towards the outside, but takes longer to establish itself. In the circle network, more errors are made and the number of messages required to reach a decision is the greatest of all shapes. However, the relative performance of the network designs varies considerably with the task assigned as described in the previous section [23]. All these research results taken together suggest that groups are the privileged vehicle for co-operation in organisations, but that reliance on groupwork requires much organisational and managerial skills, which IT could facilitate. In order to better understand the potential of IT in supporting the work of groups in organisations, we carried out a study of an organisation at the end of a long process of implementation of computer applications that, altogether added up to a finely tuned and highly customised CSCW application. The researchers were able to witness first hand how the organisation's key process took place and, furthermore, how the new information systems played a crucial role in helping organisational actors make better decisions. This also provided the opportunity to observe how information systems, decision making and groupwork are intertwined.

Supporting Complex Decision Making Processes with Collaborative Applications

267

3 Case Study Organisation and Objectives of the Study XYZ Publications Ltd (XYZ hereafter) is a news organisation which publishes two newspapers: a national morning paper and a local afternoon paper, both closely associated with one of Ireland’s major cities since the middle of the 18th century. In 1992, the business became unsustainable and XYZ underwent considerable change of both structural and commercial nature. The firm also faced a number of social crises, and the introduction of state-of-the-art IT has completely changed the balance of power and control in the company. These events have drastically reshaped the decision making processes of the firm. In XYZ, the researchers interviewed key actors in order to understand the changes undergone by the firm and analyse the group dimension of its decision making processes. Given the nature of XYZ’s products, the circulation of information and communication within the editorial team and supporting actors are at the core of the business. Also, XYZ provided an example of a company where linkages with the outside were numerous and where the diversity of information sources was essential, which made the networks of relations used for collecting and sharing information and knowledge complex and interesting. Given the extent of the tasks involved in the process of production of a newspaper, the XYZ case covers all areas of McGrath's [7] Group Task Circumplex (Figure 1) and spans across Hackman's [16, 17] 3 categories of tasks. This justified our focus on XYZ and its rich decision making processes. A case study protocol was put together [41] which focused on 3 main directions of research: (1) understanding the overall management of the organisation, (2) understanding how editorial decisions are made and how newspapers are created – i.e. how the editorial group organises itself to collect, store, organise and circulate information to create the newspapers and (3) analysing the impact of the implementation of the computerised editorial system on the group aspects of the production of the two newspaper titles. This case study is an intrinsic case study where the interest of the researchers is focused on a particular case because it is expected to possess certain interesting characteristics [42]. In total, 10 interviews were carried out with the Managing Director (MD), the Finance Manager, the Editor of the national newspaper title, the Human Resources Manager, the MIS Manager and some other staff members from the finance and IS departments. Seven visits to the site and the examination of important internal documents provided the opportunity to gather additional empirical data and to observe the operations of the company.

4 Findings of the Study at XYZ 4.1

Business Cycle at XYZ

Overall, XYZ’s management is characterised by its reliance on intense and open informal communication, such that the communication network of the firm is continu-

268

P. Brézillon, F. Adam, and J.-C. Pomerol

ously shape and re-shaped by current events. The MD communicates with everyone on the management committee on a daily basis. He said, The production of a newspaper is a team effort and, in a team game, the captain talks to the players.

According to him, this lack of formalism in communications amongst staff and with the outside is particularly essential in the news business because of the nature of the activity. Newspapers deal in news in real time and must acquire from a wide variety of sources in order to keep up to date. Interviewees at XYZ also described how the publication of two daily newspapers titles has major implications for the management of the organisation. One interviewee likened this situation to working for a company which must produce two new products every day; each of these products having a life span of 6 hours maximum! This cyclical process determines every aspect of work in the organisation as a large number of important decisions related to the information content of the papers and a number of key steps are repeated at very short intervals of a few hours following highly informal processes routinised by usage. In a mature organisation like XYZ, this happens naturally or else, as noted by the MD, . . . there is no newspaper in the street!

Thus, this organisation is characterised by much team effort and collaborative work, such that, whatever happens, the national title must be ready for 2.00 am while the local title must be ready by 12.00 pm and all the work is organised around these two daily deadlines. In contrast to other firms the authors studied, XYZ turned out to be an organisation where common goals could be readily identified and where all organisational actors strove to collaborate in their own way to produce the best possible newspaper. Leadership is provided by the editor-in-chief for the news part, the sales manager (in charge of selling the advertising space without which no newspaper can exist) and the MD. The finance department plays an arbitration role, reminding actors that maximising revenues is also a key factor in the success of the organisation (good newspapers can go bankrupt too!). This role is quite important, but particularly difficult when it comes to editorial decisions that are sometimes very costly and have an uncertain impact on the success of the paper. In fact, purchasing news represents close to 80% of the total budget of the firm. Thus, XYZ is organised around a number of loosely coupled clusters or groups of actors specialising in the different aspect of the business. 4.2

Editorial Decision Making at XYZ

Actors Involved The key feature of decision making at XYZ resides in the dominance of editorial decisions over any other managerial consideration. Only the content of the newspapers gets the full attention of the key organisational actors. This is illustrated by the core position of the editorial team at the centre of the organisational network. The production of a newspaper necessitates the availability of information and its selection in

Supporting Complex Decision Making Processes with Collaborative Applications

269

order to create an interesting and relevant end product, but it also requires a lot of discussion as the content of the papers is negotiated between the members of the editorial group and a few other key actors, such as the MD. Access to information, knowledge organisation and sharing, and negotiation are, therefore, fundamental factors in creating a good newspaper. There are also key internal linkages between the editors of the two newspaper titles and the manager for sales of advertising space (because the news can be used as an incentive for certain organisations to pay for special advertising features and, therefore can boost sales and revenues) and the finance manager (to establish whether the newspaper can afford certain high profile reports or interviews). These relationships extend the groupwork dimension of the newspaper outside the editorial area and reach into all the firm’s functional areas. The Editors explained that sources for information are plentiful, which is required in order to guarantee a continuous flow of news, pictures and opinion pieces. Thus, even though the newspaper employs only 300 people, XYZ is also connected to dozens of free lance journalists from whom special features, opinion pieces, reports and pictures are purchased. Similarly, foreign reports are purchased from international agencies or more often exchanged or purchased from local newspapers. In total, more than 500 people collaborate to produce the newspapers. Newspapers sell as much information as they buy and networking – creating webs of contacts in order to trade information – is the most fundamental aspect of the work of senior managers. The Editor of the national title provided an example of this intense networking: In 1997, news about Princess Diana had to be purchased from contacts in Parisian newspapers who had just bought information about Sophie Toscan du Plantier from XYZ only a few weeks earlier

This networking / teamwork aspect of XYZ’s business is illustrated by the area of dense information exchange between internal actors and the external groupings acting as sources of information represented in Figure 3. At the centre of the diagram, the editorial team (represented by the editors) makes all the key decisions required so the newspaper titles are published on time. A Complex and Intense Group Process The cycle of creation of the newspapers goes through a series of set steps involving key meetings and key deadlines. However, editorial decision making is also about strings of daily unstructured decisions that must be made regarding which items of news go in the paper and which do not. These decisions are made by the people who are responsible for the personality of the newspaper: the editors and sub-editors, free from interference from top management or the shareholders – and, apart from a template which prescribes the general layout of the paper (eg sections and ad pages), there is no set model as to how newspapers should be put together. Nevertheless, the process runs smoothly and efficiently. Thus, producing the newspapers is a mixture of formally organised processes and of a multitude of actions taken by actors who know each other very well and possess the crucial knowledge about the process of creation of the papers and about their readership. Having the proper mix of actors and ensuring that they work well as a team are the keys to XYZ’s success. This model of organisation means that knowledge is closely tied to individuals even though, since the imple-

270

P. Brézillon, F. Adam, and J.-C. Pomerol

mentation of the editorial application, information systems are used to help actors communicate, store and organise knowledge (see section 4.3).

Organisational Boundary

Zone of intense Information exchange activity

Fig. 3. Creation and Production processes at XYZ Note: icons in Fig. 3 represent clusters of actors, except the editorial team which is exploded

The production process revolves around the duty editor who, from 8.00 am to 1.00 am the following morning, is in charge of collecting the news and interfacing with all potential sources of information. The collaborative aspect of this process rests on a now electronic diary of current events that can be accessed and updated by everyone in the team. This diary is used to focus people’s attention on what is going on in the world and helps them get ideas for the contents of the paper. The events in the diary are also used as “hooks” on which to hang news items. This diary is really at the core of the editorial decision making process at XYZ and every evening before leaving the company, the Editor spends some time studying its content, inserting comments and allocating tasks to carry out, such as photos to obtain for the morning, requests to send a reporter to follow up on a radio interview heard during the day etc. The editor on duty will supervise the execution of these tasks. He will also send reporters out, buy information from Reuter and enter in contact with the foreign correspondents. Other reporters will contact him to provide interesting leads. Much unsolicited information also reaches the newsroom. Public relations organisations lobby the newspaper on an on-going basis either by phoning the executives of the company or by ringing reporters and editors they know to ask them to send someone to attend a seminar or a press conference. This overall process is reminiscent of the garbage can model of decision making put forward by Cohen et al. [43] where organi-

Supporting Complex Decision Making Processes with Collaborative Applications

271

sations are characterised by collections of ideas looking for problems, just as items of news all warrant potential inclusion into a paper. Amongst the editors, the news editor is particularly active and has considerable influence. He liases with all other editors in order to set priorities and allocate space. With him rests the decision to alter the template of the newspaper to give more pages to the Sports section, to international news or to local news. These decisions are made in a series of scheduled meetings taking place throughout the day. The first of these meetings takes place at 12.00 pm and aims to ascertain the volume of ads that must be accommodated. A first round-up of the stories of the day is also done. The second meeting takes place at 2.30 pm and involves selecting the cover story and the rest of items to go in each section of the newspaper. The diary is at the core of this intense group process where the editors attempt to guess what will be of most interest to the public. The final meeting, at 5.30 pm, is used to confirm decisions made earlier based on whether the pictures requested have arrived and whether reporters were successful in securing interviews. Occasionally, the news requires that the plan is changed totally, but in the general case, the decisions made at 2.30 stand. The last important task in the creation process is accomplished by the sub-editors who, under the supervision of the chief sub-editor, design each of the features in the newspaper, add and crop the pictures and integrate all the material in a coherent and attractive whole. This is now heavily supported by the computer system, which uses virtual “baskets” to hold data and classify them in terms of both relevance to the news and potential use in future issues of the newspaper. The sheer volume of data however means that a weekly purge of all items expire after a lifecycle of a week, with small on-the-spot conflicts between administrators and users, the latter always claiming that they wanted to hold on to some material now deleted from the system. Again, the job carried out by this small group of people is fundamental in giving the national title its identity and its appearance. There is no explicit model of how this is done in XYZ and the key task of the Editor is to oversee the production process by supervising the people involved in it. This explains that the computerisation of the editorial activities was not achieved overnight as is explained in the next section. Overall, editorial decision making is characterised by high levels of collaboration and virtually no conflict, at least inside the editorial team. This is likely to be due to the high level of cohesion in the group itself (as in [22]). However, in XYZ, individual actors own their sources. As such, the networking activity is primarily individual and contacts provide information to their usual source, not to anyone indiscriminately. There is collaboration in creating the newspaper, but not always in sharing linkages with key sources. The “address book” of each editor or assistant editor is their private asset to a certain extent and the management of this key organisational knowledge escapes any form of central control. In this case, the only way to manage the overall company’s address book is to get (and keep) the proper mix of people. Relationships with other sub-groups are now also free of conflict since the introduction of new technologies and the reduction of the dependence of the group on other groups of actors, as explained in the next section.

272

4.3

P. Brézillon, F. Adam, and J.-C. Pomerol

Revolutionising the Editorial Activities with IS

All managers at XYZ agree that the decision to purchase a leading edge computerised creation / production system for the newspapers has turned out to be crucial, even more than anyone had anticipated. This was a complex decision with many different. Issues of control over the production process, issues of flexibility of the process in terms of enabling differentiated editions of the newspaper and the fact that the old system was came in play. The major benefits expected from the implementation of the system included better usage of materials, better workflow, reduced staff, reduced skills requirement, better quality output, substantial time savings, better sales information and an abandonment of the reliance on out-dated production equipment. This extensive list of potential benefits illustrates why managers at XYZ were committed to the large spending this investment represented and there was a consensus that a substantial investment was required. However no one in the organisation had a clear picture of what was required as no one had done it in Ireland. There was an awareness of the English example where, in the mid 80s, R. Murdock used the technology available at that time to take on the powerful trade unions of the printing and newspaper industry, the NGA (National Graphics Association) and the NUJ (National Union of Journalists). This confrontation had resulted in the loss of close to a thousand jobs at Wapping mainly in the composition area [44]. However, knowledge of this precedent was not sufficient to either build or buy a new system. Thus, much research went into selecting a combination of systems that would meet XYZ’s requirements. The research process that followed took more than five years from 1989 to 1995. This decision process was long by any standard (cf. [45]) which is a consequence of the types of problems facing managers. This decision involved a radically new problem. Also, because of the size of the investment, managers perceived that their decision would not be reversible. These parameters explain why it took XYZ so long to commit to a solution [46]. The interviews revealed that the implementation of the system has shifted the attention of staff away from trivial production issues and blind respect of the deadlines onto new issues such as that of providing better customer service and providing a better quality news product. Production issues used to dominate the agenda and the limited attention of staff meant that there was little room for debate. The implementation of new solutions to the production problems means that managers and staff can now concentrate on the provision of better and new services to the customers. The collaborative computer system in which the newspapers are created acts as a formative mechanism and help the editorial team give a more consistent look to the paper. The impact of decisions made in relation to the contents and layout of the paper can be visualised before being committed to paper and this provides a much stronger basis for group decision making. The new system has also contributed to turning XYZ into a profitable organisation with a national distribution instead of simply local presence, using differentiated issues of the newspaper designed specifically for the newspaper’s home town, for Dublin and for other areas (which the previous production system never allowed).

Supporting Complex Decision Making Processes with Collaborative Applications

273

In addition, the new editorial system has reduced the time required to produce the paper by several hours and the time freed is used to work on the content of the newspaper. Staff in the newsroom can type in articles and save them in electronic spaces (which they call baskets) corresponding to the different areas of the paper and for the various issues in a given week. This constitutes a pool of material that can be used by the Editor once his mind is made up. But, IT systems also have a crucial role to play in providing better access to information for the editorial team. Over the last years, XYZ has been obtaining its pictures directly from satellite connections and much of the information comes in through its ISDN lines. This automation of the collection and presentation process is matched by a similar system to deal with the ads. Twenty teleads operators feed a continuous flow of ads into the Windows-based system. These ads come from a variety of sources including phone, fax, electronic mail and a dedicated web site. In addition, display ads (those that contain pictures) are brought in by a group of sales representatives who actively seek large advertisements from local businesses. All ads are automatically saved in a database which then organises them in pages. This important process used to be extremely time consuming as it involved a set of large pin-boards where ads were provisionally booked. The database now organises all ads in a matter of minutes. As briefly explained above, another key consequence of the implementation of the new system has been the shift in power and control over the process of production of the newspapers. Up to 1994, there was a group of 80 individuals – the compositors – whose unique expertise meant that they could decide on a daily basis whether the newspaper would be in the streets or not. This situation is reminiscent of Crozier and Friedberg’s [21] analysis of how a group possessing a unique and crucial expertise can create uncertainty for the people both below and above it in the hierarchy. In XYZ, the compositors were a strong, heavily unionised clique who negotiated fiercely its terms and conditions of employment. This resulted in high levels of pay and short promotion paths. The rift between compositors and other organisational actors was accentuated by the physical layout of the plant because this group was isolated from the other stages in one “composition” room. The power of the compositors stemmed from their being in a position to decide when the paper would be ready for publication and what it would look like. This weakened the editorial group and created uncertainty for top management. The change brought about by the new computerised system was simple: it eliminated the composition room. The newspaper can be composed directly in the computer package by the editorial team and, when ready, merely sent to the presses in electronic format. This eliminated the powerful group of compositors. Thus, the decision making power swung back to the editorial team and the focus shifted entirely to the creation of the product. The Editor who operated under both systems explained that his control over the production process has increased drastically as a result of the smaller number of people. He stated: Now, there are no middlemen involved in the process. All the people who work on the production of the paper work for me directly.

274

P. Brézillon, F. Adam, and J.-C. Pomerol

Thus, the computerisation of the production process has radically changed the way the products are created and has introduced higher levels of collaboration in the whole procedure as control is entirely in the hands of the very cohesive editorial team. IT has been used to increase communication, whilst reducing the opportunities for conflicts between the different groups that collaborate in creating the paper. The reliance on a smaller and more centralised group may have been a great help in achieving this. IT has also facilitated their access to a greater variety of sources of information such that more time is available for negotiation and discussion of the content of the papers and more material is available to prepare a better news product.

5 Conclusions As pointed out by XYZ’s MD, few companies would have been able to invest as much money as was involved in the modernising of the operations in a company that was losing money at that time. In this case, family pride made easier to take a hit on profit for 2 years rather than be restricted by insufficient funding.

The purchase of the computerised composition system studied in this paper alone amounted to £1.5 million and the overall investment in technology at XYZ has reached £11 million over the 12 year period prior to 1997. The figures are certainly high for a company with a £20 million turnover. Nevertheless, this investment has clearly paid off and the new computer-assisted newspaper production has had implications for every aspect of the work in the organisation as it has considerably facilitated a large number of important decisions that are repeated at very short intervals of a few hours. According to a recent audit of the organisation carried out by external consultancy in Total Quality Management, the process of producing the newspapers is XYZ's strongest asset. This process is the product of 150 years of a slow and subtle evolution which represents the sum of everything the organisation has learnt, but it has been revolutionised in the last two years in some respects by the introduction of technology in the production and composition activities. In the near future, business at XYZ is going to be further revolutionised by the use of the internet as a means to collect data about customers. As XYZ’s internet site develops, increasing numbers of customers will place their ads via the internet therefore making it much easier to capture vital information about them and their habits (the burden of data entry being shifted out to the customer). Thus, IT and IT staff can play a leading role of enabler of knowledge creation and knowledge management and the groupware element of XYZ's business is going to extend further, reaching outside the company as well to the furthest reaches of what can be called the extended network of XYZ [47]. As the number and the complexity of systems increase in XYZ, the volume of information captured increases as well. Opportunities for an enlargement of the role of IS in supporting the emergent sharing of information and communication between actors will increase as well such that XYZ will increasingly depend on IT for its core processes. Groupware will then come to play a core role.

Supporting Complex Decision Making Processes with Collaborative Applications

275

References 1. Le Bon, G. (1896), The Crowd – A Study of the Popular Mind, Fisher Unwin, London 2. Huczynski, A. and Buchanan, D. (1985) Organisational Behaviour, Prentice Hall international, Kidlington, Oxon, second edition 3. Asch, S.E. (1951) Effect of group pressure upon the formation and modification of judgements, in H.Guetzkow (Ed.), Groups, Leadership and Men, Carnegie Press, New York, 177–190 4. Milgram, S. (1974) Obedience to Authority, Tavistock, London 5. Janis, I. (1972), Victims of Groupthink, Houghton Mifflin Comp, USA 6. Stoner, J.A. (1961) A comparison of groups and individual decisions involving risk, quoted in R. Brown (1965), Social Psychology, the Free Press, New York 7. McGrath, J. E (1984), Groups – Interaction and Performance, (1st Edition), Prentice-Hall, Englewood Cliffs, N.J. 8. Greenberg S. (1991) Computer-Supported Co-operative Work and Groupware, in Greenberg (Ed.) Computer-Supported Co-operative Work, the Computer and People Series, 1–7 9. Kiesler S. Siegel J. and McGuire T. W. (1984) Social psychological aspects of computermediated communication, American Psychologist, 39, 1123–1134 10. Sproull L. and Kiesler S. (1986) Reducing social context cues: Electronic mail in organisational communication, Management Science, 32(11), 1492–1512 11. Williams F. and Rice R. (1983) Communication research and the new media technologies, Communication Review and Commentaries, Chapter 7 12. Hiltz S. and Turoff M. (1985) Structuring computer-mediated communication systems to avoid information overload, Communications of the ACM, 28(7), 680–689 13. Nunamaker, J. F. (1989) Group Decision Support Systems (GDSS): Present and Future, IEEE Transactions on Engineering Management, 0073-1129, 6–17 14. Hiltz S. and Johnson K. (1990) User satisfaction with computer-mediated communication systems, Management Science, 36(6), 739–764 15. Shaw, M.E. (1973) Scaling group tasks: a method for dimensional analysis, JSAS Catalogue of Selected Documents in Psychology, 3, 8 16. Hackman, J.R. (1976) Group influences on individuals, in Dunnette (Ed.), Handbook of Industrial and Organisational Psychology, Rand McNally, Chicago: IL 17. Hackman, J.R. (1968) Effects of task characteristics on group products, Journal of Experimental Social Psychology, 4, 162–187 18. Steiner, I. D. (1972), Group Processes and Productivity, Academic Press, New York 19. Steiner, I.D. (1966) Models for inferring relationships between group size and potential group productivity, Behavioural Science, 11, 273–283 20. Easterbrook, (1991) CSCW: Co-operation or Conflict, Spring Verlag, New York 21. Crozier, M. & Friedberg, E. (1977) L’acteur et le système. Edition du Seuil, Paris 22. Seashore, S.E. (1954) Group Cohesiveness in the Industrial Work Group, Survey Research Centre, University of Michigan, Ann Arbor, Michigan 23. Baron, R.A. and D. Byrne (1977) Social Psychology Understanding Human Interaction, Second Edition, Allyn and Bacon Inc, Boston 24. Wichman, H. (1970) Effects of isolation and communication on co-operation in a twoperson game, Journal of Personality and Social Psychology, 16, 114–120 25. Deutsch, N and Krauss, R.M. (1960) The effect of threat upon interpersonal bargaining, Journal of Abnormal and Social Psychology, 61, 181–189

276

P. Brézillon, F. Adam, and J.-C. Pomerol

26. Swingle, P.G. and Santi, A. (1972) Communication in non-zero-sum games, Journal of Personality and Social Psychology, 23, 54–63 27. Bossard, J. (1945) Law of family interaction, American Journal of Sociology, 50, 292–294 28. Porter, L.W. and Roberts, Karlene H. (1976) Communication in organisations, Dunnette (Ed.) Handbook of Industrial and Organisational Psychology, Rand McNally College Publishing Company, Chicago, 1953–1589 29. Jablin, F. (1987) Formal organisational structure, in Jablin, Putnam, Roberts and Porter (Eds) Handbook Of Organisational Communication: An Interdisciplinary Perspective, Sage Publications, London, 389–419 30. Hage, J., Aiken, M. And Marrett, C. B. (1971) Organisational structure and communication, American Sociology Review, 36, 860–871 31. Mintzberg H. (1979) The Structuring of Organisations, Englewood Cliffs, N.J. : PrenticeHall 32. Lincoln, J.R. (1982) Intra (and inter) organisational networks, in Bacharach (Ed.) Research in the Sociology of Organisations, Greenwich, JAI Press, 1–38 33. McPhee, R.D. (1985) Formal structure and organisational communication, in McPhee and Tompkins (Eds), Organisational Communication: Traditional Themes and New Directions, Newbury Park, Sage, 149–178 34. Monge P. and Isenberg E. (1987) Emergent communication networks, in Jablin, Putnam, Roberts and Porter (Eds) Handbook of Organisational Communication: An Interdisciplinary Perspective, Sage Publication, London, 41–69 35. Blau, P. (1989) Exchange and Power in Social Life, Transaction Publishers, New Brunswick, NJ.Baron, R.A. and D. Byrne (1977) Social Psychology Understanding Human Interaction, Second Edition, Allyn and Bacon Inc, Boston 36. Chandler A.D. (1962), Strategy and Structure, MIT Press, Cambridge 37. Adam F. and Murphy C. (1995) Information flows amongst executives: their implications for systems development, Journal of Strategic Information Systems, 4(4), 341–356 38. Knoke, D. and Kuklinski J. (1982) Network Analysis, Sage Publications, Beverly Hills 39. Leavitt, H. J. (1951) Some effects of certain communication patterns on group performance, Journal of Abnormal Social Psychology, 46, 38–50 40. Bales, R. F. (1955) How People Interact in Conferences, Scientific America, 192(3), 31–35 41. Yin, R. (1994) Case Study Research – Design and Methods. Sage Publications, London 42. Stake, R.E. (1994): Case Studies. In Denzin & Lincoln (Eds.): Handbook of Qualitative Research, Sage Publications, London 43. Cohen, D., March, J.G. & Olsen, J.P. (1972): A Garbage Can Model of Organisational Choice. Administrative Science Quarterly, 17, 1–25 44. Tunstall, J. (1990) Newspaper Power : the New National Press in Britain, Oxford: Clarendon Press 45. Eisenhardt K. M. (1989) Making fast decisions in high velocity environments, Academy of Management Journal, 32(3), 543–576 46. Adam, F. (1996): Experimentation with Organisation Analyser, a Tool for the Study of Decision Making Networks in Organisations. In P. Humphreys, L. Bannon, A.McCosh, P. Migliarese & J-C Pomerol (Eds.): Implementing Systems for Supporting Management Decisions, Chapman and Hall, London, 1– 20 47. Adam, F. and Pomerol, J. C. (1998) Context Sensitive Decision Making Analysis Based on the Investigation of Organisational Information Networks, in Berkeley et al. (Eds.) Context Sensitive Decision Support Systems, Chapman & Hall, London, 122–145

An Architecture for Supporting Disconnected Operation in Workflow: An XML-Based Approach Pedro Arroyo-Sandoval, Ana I. Martinez-Garcia, and Cristina Ramirez-Fernandez Centro de Investigacion Cientifica y de Educacion Superior de Ensenada Km. 107 Carretera Tijuana-Ensenada Ensenada, B.C., Mexico. {parroyo,martinea,cramirez}@cicese.mx

Abstract. Nowadays, there exist few options to support workflow and cooperation among mobile users using non-traditional computing platforms such as Personal Digital Assistants (PDAs). Considering the growing need for mobility and the more frequent use of mobile devices, it is necessary to provide support for the integration of these to the work environments. In this work, we present the development of the SysCoor Workflow Management System (WFMS) architecture, which provides support for the semi-automatic generation of Webbased workflow systems and disconnected workflow through the use of models described in the eXtensible Markup Language (XML) and also considers the use of image, video and multimedia presentations as part of the workflow information entities. We present a scenario that illustrates a disconnected process and how it could benefit by this approach. We establish the requirements for supporting disconnected workflow and discuss the architecture of the system that is based in the use of XML for the specification of the workflow systems and disconnected operations. The workflow systems’ specification is generated in XML to enable interoperability with other WFMS engines. The development of the disconnection mechanism is presented in terms of a lightweight architecture for PDA devices developed using the SuperWaba programming language, however, the architecture described can be implemented using other programming tools.

1 Introduction A Workflow Management System (WFMS) is a system that automates flows of information and control in a business process by managing the sequence of work activities within the process and the invocation of human or/and Information Technology (IT) resources [1]. Thus, agents (people involved) in a process within an organization focus only in the execution of their tasks, letting the WFMS handle the flow and control of the work. Traditional workflow systems have been developed under architectural and design considerations that propose the implementation of client-server architectures. Under this approach, the workflow system definition and control, is kept in a centralized structure [2]. This approach requires users to keep a continuous connection to the

J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 277–292, 2003. © Springer-Verlag Berlin Heidelberg 2003

278

P. Arroyo-Sandoval, A.I. Martinez-Garcia, and C. Ramirez-Fernandez

network, where the workflow systems reside, if they want to participate in the coordinated execution of their work. This makes the control of the workflow activities easier with the tradeoff of reduced possibilities for mobility. Newer approaches like the Web-based systems have increased the accessibility of those workflow applications to geographical distributed users [3]. Thus, augmenting the possibilities for users to be distributed along several geographical places and still continue with the coordinated execution of their tasks. However, this approach still requires the permanent existence of a network connection to a central server in order to participate in a workflow activity. In contrast, organizations are now moving forward to environments where the mobility is required. In recent years we have seen the spread of computer technologies beyond the traditional desktop environment [4] towards the use of new technologies like Personal Digital Assistants (PDAs). However, few options exist to support the workflow among mobile agents using non-traditional computing platforms such as smart phones and PDAs [3]. It is important to point out that mobility should not be a limitation to keep the regular flows of work nor to be a barrier on organizational collaboration, and neither to break with concepts like workgroup collaboration [5]. Considering the more frequent use that organizations make of mobile devices, it is necessary to provide support for the integration of those devices to the work environments. These kinds of devices observe special characteristics like intermittent network connections and limited storage space. Due to the first characteristic, we need to look for options that enable process agents to continue with their work and keep coordinated interactions in their work environments in cases where network connections are not available. Due to its nature, disconnected operation, defined as the disconnection from services provided by a server [6], appears as the direct option to support mobile workflow agents. The disconnected operation is quite useful in environments where network connections exist intermittently or do not exist at all. This mode of operation enables users to continue with their work, even when they are not physically connected to the network where they normally perform their tasks. To explore the potential of this approach, we have developed SysCoor, a WFMS which architecture provides support for the semi-automatic generation of Web-based workflow systems and also enable the generation of disconnected workflow systems making use of processes models described in the eXtensible Markup Language (XML). On the other hand, WFMS is a fast evolving technology, which is increasingly being exploited by businesses in a variety of industries. This fact has been pointed out and has given place to a new opportunity, the development of options for achieving interoperability among different WFMSs. As an example of this effort, the Workflow Management Coalition (WFMC) has proposed a reference model [1] to achieve interoperability between workflow products. This reference model is a set of interfaces and data interchange formats between such components. Also, the WFMC proposed a process definition language [7] described in XML to make feasible the migration of process definitions between tools. Therefore, we devise in the use of XML an excellent opportunity to enable interoperability among WFMSs. In this paper, we focus on the disconnected workflow paradigm as a means of extending collaborative work among users even when a communication network is not present. At first, we discuss the concept of disconnected workflow, the work that has been done and the future work literature reports on the area. We follow by pointing out the requirements that previous work has established and the requirements we

An Architecture for Supporting Disconnected Operation in Workflow

279

found through the realization of two case studies. Then, we describe the SysCoor architecture and how it supports the disconnected workflow paradigm. We finish the paper presenting our conclusions and future work.

2 Disconnected Workflow Disconnected operation is the ability of a client to continue his/her work operations when and where network connections are not present and therefore access to the central main data repository is not possible [8]. With the development of mechanisms to support the disconnected operations, users within an organization can work independently of the main computer facility [9]. Clearly, the combination of workflow and disconnected operation concepts, offers a wide range of application in current workflow scenarios. By combining the two concepts, we found the concept of disconnected workflow as the availability of services provided by a WFMS in a disconnected state. Most of the efforts to support a reliable performance on disconnected operation have been made in file systems and showed that supporting disconnected operation was very effective in the fundamental level of services such as file operations [8]. But at the application level, like workflow execution, not much work has been done in depth [2, 10]. In this section, we briefly review four of the most important works that have been done to support disconnection in workflow. The Exotica/FMDC project [2], represents the first reported research on the area of disconnected workflow. In this work, the authors propose a series of mechanisms that enable the FlowMark [2] workflow architecture, to support disconnected clients. One of the main contributions is the pointing out of the impact of disconnected clients on WFMS. The system proposed feasible mechanisms related with handling relevant data, like the notation of locked activities and the user’s commitment to eventually execute them. Magi [3] implements an architecture in terms of a HTTP server (micro-Apache). This implementation makes use of server-primitives to enable the management, synchronization and archiving of online information. However, Magi was designed to specifically address the paper-based workflow [3] and it represents a heavy-weighted in terms of the HTTP server needed to support disconnection. The ICU/COWS architecture [10], analyzes task models using the concept of the type and scope of service when providing disconnection. By type they refer to the set of activities involved in a process (roles and activities), and by scope, the whole range of targets where the services are performed (information entities). Based on this analysis they identify four important considerations for supporting disconnected operation in WFMSs: task classification, data and application handling, and emulating task state transition. This last work [10], provides a good review of the aspects that should be generally considered to support disconnection in WFMS. Finally, the server-based software Domino Everyplace Enterprise [11] provides a platform for the development of mobile applications that integrate with the workflow architecture of Domino [11]. It implements the use of XML for the definition of application. However it lacks from a global integration of tasks and does not provide evaluation of the task disconnection feasibility.

280

P. Arroyo-Sandoval, A.I. Martinez-Garcia, and C. Ramirez-Fernandez

In general, the proposed future work found in the literature in the area is concerning the following challenges: develop interoperability with XML, mobility supported with software autonomous agents and concurrency control handling [10][12]. In this sense, the contribution of our proposal will be to explore the use of XML as a means of extending compatibility and integration to existing tools. To give a clearer understanding of how the disconnected operation in workflow systems can keep the coordination and still accomplish the enactment of an organizational process, we present a workflow scenario taken from a case study that was developed in a winery company. Our scenario presents the sales process in this company. The scenario presented applies to almost any traditional sales scenario where the visits to clients are a necessity and where each link in the sales chain - the client, the salesman, the warehouse, - acts independently according to its function. 2.1

A Disconnected Workflow Scenario

Most of the time, salesmen face the need to visit clients in their locations, sometimes out of town, in order to perform a sale. These visits frequently require the salesman to be away from the office for long periods of time, which can go from a complete day to several days. During these visits, a salesman requires to collect information about costumers’ product inventory and fill out invoices among other activities. To collect an invoice, he needs to have detailed information about a costumer’s previous purchases and their debit and credit status in order to take a decision and perform a good sale for both parties. Some of the most important visits are those made to potential clients for the company, called promotional visits. In these, the salesman needs to carry graphical material such as pictures of the vineyards and of the production facility, and, when the customer has multimedia equipment, the salesman can also give a multimedia presentation, all of the above, with the purpose to give the client a more complete view of the company and its installations. Normally, a salesman prepares his daily activities during the mornings; he schedules his visits and prepares all the information and graphical material he needs to carry for those visits. If during a visit a need for information rises, for example to clarify details of the costumer’s credit or about product inventory in the company’s warehouse, the salesman needs to call the office and ask for help to solve the issue. The salesman always relies on the availability of an office clerk to solve the problem. This situation delays the sales process, which affects the customer service quality damaging the external perception of the company. At the end of his day, the salesman usually returns to his office with the information collected during the visits. This information is needed to schedule the next day’s visits, to update customer’s credit and debit records and to process product deliveries. Since the collected information is in paper, when the salesman returns to the workplace he still needs to input this information into the current information system and transcribe the invoices collected. These duties are not performed until next morning, delaying the following process tasks such as delivering and billing until the next day. By integrating the disconnected workflow schema to the above scenario the streamline of the process can be achieved. During the mornings when a salesman prepares his visits, he uploads to the PDA the previously defined tasks related to the sale process. This includes information such as debit and credit status of the client, inventory product information and invoice forms. With the above data available, the

An Architecture for Supporting Disconnected Operation in Workflow

281

salesmen can proceed to solve the problems mentioned before, without having to consult the office in cases where information needs arise. When the salesman returns to his workplace, he reconnects his PDA device and reintegrates to the workflow. He might decide to download the information collected and/or disconnect the next tasks he needs to perform. When he downloads the collected information, this information is integrated to complete the workflow of the sales process; the invoices are routed to the warehouse where the delivery is prepared and the sales information is sent to the accountant clerk to update the credit and debit client status. Whenever is possible, the salesman can reconnect temporarily to the central server, he can download the information collected and receive the following tasks and the necessary data to perform those tasks. The scenario goes further from a simple data collection when gives the salesman all the necessary information to take a decision to perform a sale, and when enables the salesman to reconnect and receive the following tasks and feedback from the central workflow system. In the case of a promotional visit, the salesman could upload to the PDA the previously defined tasks related to this process and the required information which includes pictures, video and multimedia presentations. This PDA must have multimedia capabilities that will enable the salesman to give to a potential client, a complete presentation of the company, in spite of the technological resources available in the site. In the following section, we present the necessary requirements to support disconnection in WFMS. 2.2

Requirements for Disconnected Operation

In order to develop mechanisms to support the disconnection of workflow, we identified the requirements already established in the literature on disconnected operation. Furthermore, we developed two small case studies that enabled us to observe real scenarios where people switch from a connected to a disconnected work environment. The scenario described in the previous section belongs to one of these case studies, from which we analyze the forms the work is performed in these kinds of environments. These scenarios were not technological equipped, so we had the opportunity to observe only the human aspects of work and contrast the literature requirements with the requirements obtained from the case studies. Besides requirements obtained from literature and from our case studies, a third kind of requirements needed to be considered, we refer to the SysCoor architecture structure and its requirements. Requirements from Cases Studies a) Coordination among process agents must be kept in spite of disconnection b) A mobile agent should be able to execute from 1 to n roles while in disconnection c)

Role execution requires an information input that must be present at the time disconnection occurs.

282

P. Arroyo-Sandoval, A.I. Martinez-Garcia, and C. Ramirez-Fernandez

Requirements from the Literature Review a) To allow clients to work on a disconnected mode, they must have their own storage and access to the necessary information to be able to proceed without consulting a centralized data structure [2]. b) Clients must have autonomy, this means, a central server must ensure there are no conflicts between the different disconnected clients [2]. c)

When providing information prior to disconnection, no out-of-date input information should be used [12].

d) When reconnecting to WFMS, there must exist the handling of output information to ensure data consistency [12]. e)

There must exist, the task classification in order to decide if a task can be executed in the mode of disconnection, and it should consider the task type and task relevant data [10].

f)

There must exist the handling of task state, related applications and relevant task data served during disconnection [10].

Requirements from SysCoor Design a) XML should be used to support interoperability, to enable the execution of the developed workflow models though a simple transformation of the XML definitions in other XML-based workflow machines. b) The centralized control of the process state must be kept by a Global Process Administrator. c)

Users should be allowed to visualize the state of their processes at any time.

d) There must exist multimedia data support. Summarizing, we classified all of the previous requirements in four main areas that need to be considered when supporting disconnection: evaluation of the task (role) disconnection feasibility [10], information hoarding previous to disconnection [2,10,12], synchronization to the workplace after disconnection [12] and control of coordination during disconnection [2]. At this point, we need to distinguish between the two existing types of disconnection [10]: involuntary and voluntary. Involuntary disconnection occurs when a remote failure impedes users to continue with their work, while voluntary disconnection happens when a user explicitly takes all her tasks offline. We limit our work only to voluntary disconnections. In the next section, we describe the architecture of SysCoor and how it fulfills the four classification areas just mentioned.

3 SysCoor SysCoor is a WFMS with an architecture intended to facilitate the generation of workflow systems through the use of process models captured using diagrammatic techniques [13] and represented in XML. In SysCoor, the definition of the workflow system starts with the definition of the organizational process we aim to automate. To

An Architecture for Supporting Disconnected Operation in Workflow

283

do so, we capture a process using Role-Activity Diagrams (RAD)1, State Transition Diagrams (STD) and defining the information entities used in every task of the process as well as those that are exchanged during the execution of the process tasks.

Process

Rol-Activity Diagram

Information entities used in process execution

State Transition Diagrams

RAD Base Model (XML)

STD Base Model (XML)

IE Base Model (XML)

SysCoor

WF Base Model (XML)

DWF Base Model (XML) XML

Workflow System

Disconnected Workflow System

Agent

Mobile Agent

Agent

Mobile Agent

Process Enactment

Fig. 1. Process flow for generating a Workflow System The three models are formally represented in XML and validated using a Document Type Definition (DTD) for each model. The XML documents for the RAD, STD and information entities (IE) are known as the RAD, STD and IE base models, respectively [13]. Figure 1 describes the flow in which a workflow system is generated. First, we develop the RAD base model to identify roles, interactions, states and activities of the process. Then, the STD base model is constructed for each of the roles defined in the RAD. Finally, the information entities that participate in every process task have to be identified and properly defined (IE base model). The RAD, STD and IE base models are parsed and then transformed into a Workflow System base model (WF base model). This model defines the elements of an executable workflow system in XML. This WF base model is then used to create a new model specification called the Disconnected Workflow base model (DWF base model). This new model contains the special considerations for devices such as PDAs. 1

The Role Activity Diagrams (RAD) are among the most useful modeling techniques for process representation [14]. These diagrams map or capture the tasks, objectives and people (agents) involved in a process into roles, activities, decisions and interactions [15,16].

284

3.1

P. Arroyo-Sandoval, A.I. Martinez-Garcia, and C. Ramirez-Fernandez

Architecture of SysCoor

The architecture of SysCoor consists of five components (figure 2): a workflow system generator, a data repository to store models and workflow systems’ definitions, a coordination engine, an operation disconnection module and a lightweight client architecture intended for PDA devices (A). The workflow system generator has two sub modules: the model generator and the code generator. The model generator is responsible of reading the RAD, STD and the IE base models, and creates the WF and the DWF base model. The code generator creates the base role structure that includes: an activity handler, an information entity handler, an operation handler, an application handler and a state handler. Finally, the coordination engine is the responsible of maintaining the collaboration, communication, coordination and process information interchange. Since, for the disconnected operation, our target technology is a PDA device with still limited operational resources, the client side proposal is a lightweight architecture with minimal mechanisms. This lightweight architecture is made up of four main components: a local coordinator (LC), a graphical user interface (GUI) generator (IG), a local data repository (DR) and a base role (BR) that handles all the elements that build a role such as the internal activities, states, information entities, operations involved and external applications used during execution. Motivated by the differences of GUIs between desktop computers (original target platform of SysCoor) and PDAs devices, we implement a Code Translator (CT) as part of the Code Generator, for making the code adjustments in the generation of the GUI when creating the DWF base model. The Operation Disconnection Module consists of three mechanisms: the Determination of Disconnection, XML Document Transfer and Synchronization Mechanism. At this point, it is necessary to explain the approach in SysCoor for the generation of an executable Web-based workflow system. Based on the WF base model, serialized java objects are generated. These objects are later called and executed within predefined html basic page layouts that help to display a graphical user interface. Each serialized object has an html page layout associated. With the information stored within those objects, workflow functionality is achieved. These basic layouts fairly cover the most common workflow scenarios, such as, submit an information entity, wait for an answer, etc. Due to the graphical display limitations in PDA devices, the predefined html pages cannot be used in the new disconnected schema. Due to this fact, we redefined the existing html pages layout, into traditional GUI interfaces defined through an XML document; we called it the GUI base model and it is general for all the DWF base models. This document enables interoperability among different PDAs platforms. Figure 3 shows the DTD (a) and an example of this document (b). In contrast with the serialized objects approach, that gives functionality to the workflow systems, the DWF base model stays as a pure XML document. This XML document is formed with information obtained from the GUI Base Model and the WF Base Model. The DWF base model specification is validated with a DTD which also includes the definition of data types, data contents and relationships between data and GUI interfaces as illustrated in part of the DTD shown in figure 5. The DWF base model contains sufficient information so that, once it is parsed it provides enough functionality to the definition of the disconnected operation in a workflow system.

An Architecture for Supporting Disconnected Operation in Workflow

285

(A)

Local Coordinator

Code

Base Role Interface Generator

Data

Disconnection Determination Mechanism XML Documents Transfer Mechanism Synchronization Mechanism

DB

Workflow Systems Generator Model Generator

Coordination Engine Global Process Administrator Models and WF systems Repository

Code Generator Code Translator

Roles Coordinator

Operation Disconnection Module Base Role Operation handler Application handler

Activity handler Information Entity handler

State handler

Fig. 2. SysCoor WFMS Architecture

The DWF base model is sent to the PDA device before disconnection occurs and, once it is stored on the local repository, it can be accessed by request of the local coordinator and parsed locally. The information obtained after parsing is processed by the handlers inside the base role and by the GUI Interface Generator. (a)

<elementgui type="ItemButton" text="Submit" x="10" y="5"/> <elementgui type="InputBox" text="Enter Amount" x="10" y="5" value="56"/> <elementgui type="CheckBox" text="Yes/No" x="10" y="5" value="yes"/> .

(b)

Fig. 3. The DTD for the GUI base model and an example of a XML document that represents a simple input window

286

3.2

P. Arroyo-Sandoval, A.I. Martinez-Garcia, and C. Ramirez-Fernandez

Evaluation of Role Disconnection Feasibility

Prior to disconnection, and after the DWF base model was created, the next task to be performed is to examine this base model and evaluate the activities that are candidates for disconnection; this task is executed under request of a role disconnection by a process agent. To do so, we need to know the information entities used by every task and the state (locked-unlocked, available-no-available) of these entities in a given moment. This information already exists in the data repository. Later, we will use this information to successfully execute the data hoarding prior to disconnection. Also, we need to know the interactions that exist between tasks. In other words, we must know if a task relates to other tasks within other process role. In this regard, we parse the DWF base model and create a data structure that holds the interactions of every task with other tasks in other roles. This data structure is queried every time a disconnection is requested. Information about interactions among tasks, along with information about information entities used in each of those tasks and the states of the latter, help us to determine the information dependencies in a process role to be disconnected. By establishing the information dependencies, we answer questions like, what information is received?, what information is produced? and what information is sent during the process execution? Having defined what information is received is a quite important step prior to disconnection, because if this information is not available at the time the disconnection is required, the role cannot be disconnected. On the other hand, the answer to what information is sent during the process helps us in the reconnection phase, since it gives us enough detail about what information needs to be sent back to the central data repository. The activity of retrieving and analyzing the interactions in a given role and the information entities used by the role is executed by the Determination of Disconnection

:DisconnectionModule

:DeterminationMechanism

DataRepository

GlobalProcessAdministrator disconnectRole(roleId) checkDisconnection(roleId) retrieveUsedIEInfo(roleID) return list retrieveIEStat(ieID) return stat

answer:=checkIDStat()

return answer

*[For each IE used in Role]

Fig. 4. Sequence diagram of the evaluation of role disconnection feasibility process

An Architecture for Supporting Disconnected Operation in Workflow

287

Mechanism (DM). In figure 4 we present a sequence diagram that shows the sequence in which the evaluation of role disconnection feasibility is executed. As shown, the Global Process Administrator (GPA) makes a request of disconnection to the Operation Disconnection Module; this requests the DM to check if a disconnection is feasible, then the DM, based upon the DFW base model information, retrieves from the data repository the state of each of all the information entities used by the role that requests disconnection. It returns an answer to the Operation Disconnection Module, based upon de availability of the information entities. If it is a negative answer, it sends a message to the GPA explaining the reason why the disconnection is not possible. If it is a positive answer, the code generator is requested to retrieve from the DWF base model, the definition of the tasks to be disconnected. Then, the data hoarding phase starts, in this phase, the contents of the information entities used by the role requesting disconnection and specified in the DFW base model, need to be retrieved and added to description of the roles that will be disconnected.

3.3

XML Data Specification

The workflow relevant data represents the information entities used during workflow execution. This data is created and used within each process instance during process execution. It is made available to activities or applications executed during the workflow and may be used to pass persistent information or intermediate results between activities and/or for evaluation in conditional expressions such as in transitions or participant assignment [7]. SysCoor includes in the IE base model definition of various basic data types, (including integer, string, etc.) and also documents (spreadsheets, presentations, etc). The IE base model also defines basic operation over basic data types, such us, addition, subtraction, division, multiplication, and also, the references to the location of the multimedia data used in the tasks. Currently SysCoor enables users to use Microsoft Office Documents as a part of the information entities handled during workflow execution. These documents can be accessed and edited on a Web browser. However, the IE base model only defines the structure of the relevant data but not the data itself. The current workflow relevant data is stored on the data repository. If disconnection is required we need to transfer not only the workflow logic and GUI representation, but also the information entities needed for the execution of the workflow system. We use the DWF DTD (figure 5) that helps to describe information entities, their types, their contents and their display characteristics. The Code Translator uses this DTD to generate the structure of the relevant data information, not the content, needed in the DWF base model when is generated. The data content is retrieved and added to the DWF base model later, when disconnection has been determined to be feasible, and only for those roles that will be disconnected. The main purpose of this new document is to extend the information stored in the IE base model. In the case of Microsoft Office Documents currently supported on SysCoor we make an exception due to compatibility among platforms issues and we do not consider them in our initial prototype.

288

P. Arroyo-Sandoval, A.I. Martinez-Garcia, and C. Ramirez-Fernandez

(a)

(b)

Fig. 5. Part of the DWF DTD for the data definition and an example of part of a XML document that illustrates data specification

3.4

Data Hoarding Phase

During this phase two important activities are executed: loading and locking activities and information entities. The Operation Disconnection Module triggers this phase once it has received a positive answer from the DM signaling the feasible disconnection of a role. The loading phase involves two steps; first, retrieve the XML Data Document and add the information about data content, required only for the activities to be disconnected, to the DWF base model. In the locking phase, all information transferred to the PDA device is communicated to the GPA that is in charge of handling the locking and unlocking of tasks and information entities. In figure 6 we present a sequence diagram that shows the data hoarding process. As mention earlier, the Operation Disconnection Module consists of three mechanisms: the Determination of Disconnection, XML Document Transfer and Synchronization Mechanism. We already developed on the Determination Mechanism, now, we will describe the two remaining mechanism. XML Document Transfer Mechanism (TF) Upon request of the Disconnection Module, the TF retrieves, from the workflow systems’ repository the XML document that defines the modified workflow system definition (DWF base model). The TF then transfers this document to the Local Coordinator (LC) in the PDA. In the case of those tasks using multimedia data, this type of data is retrieved and sent to the PDA devices using a raw binary file transfer mode.

An Architecture for Supporting Disconnected Operation in Workflow

:TransferMechanism

:DataRepository

:SincronizationMechanism

289

:GPA

DisconnectionModule transferRole(roleId)

retrieveXMLDataDoc(roleID) return list notify(ieID)

lock(ieID)

return

return

*[For each IE used in Role] retrieveDFWModel(roleID) return list

notify(actID) return *[For each activity in Role]

lock(actID)

retrieveGUIModel(roleID)

return

return

Fig. 6. Sequence diagram of the data hoarding process The TF is also responsible of receiving the changes generated during disconnection. These changes are also described through the use of a XML document. It receives the documents and passes the information received to the Synchronization Mechanism (SM). Synchronization Mechanism (SM) Basically the SM performs two actions that take place prior to disconnection and when disconnection ends. Prior and post disconnection, it notifies the GPA about the activities and the information entities that were successfully transferred both ways so the GPA can update the process state. The SM also receives the information updated during disconnection and access the data repository to perform the necessary updates on data. 3.5

Client Architecture

Due to limitations on PDA devices, we define a lightweight architecture on the client side. As depicted on figure 2 (section A), we have four components: a local coordinator, a GUI interface generator, a base role and a data repository.

290

P. Arroyo-Sandoval, A.I. Martinez-Garcia, and C. Ramirez-Fernandez

Local Coordinator (LC) In essence, the LC component is a micro version of the GPA. Its first task is to receive, from the TF, the DWF base model that defines the workflow system and stores it in a local repository. Similar to the GPA, it shows the available roles in the PDA and once the user has chosen a role to be executed, it controls its display and execution. The display of the workflow system is achieved through the GUI Interfaces Generator (IG), and the execution through the Base Role (BR). It keeps the coordination if more than one role resides in the device. Base Role (BR) The RB is a component inside the LC that parses the DWF base model, interprets the XML information and converts it to logic instructions that enable the execution of the workflow representation. It parses and retrieves from de DWF base model the different definitions of the elements that build a role, the activities, the states, the information entities used, the operations involved and the external applications used during the execution of the workflow. GUI Interface Generator (IG) This component retrieves from the local repository the DWF base model and uses it to build de GUI. Basically, this component is a XML parser with instructions to interpret the definition in the base model, and display the GUI elements. The disconnection components, except from the data repository, have been developed using the SuperWaba programming language and tested on the Palm operating system. The tool was chosen based upon the fact of its capability to run in PDAs with different operating systems. However, the architecture described above, can be implemented using other programming languages intended for pda devices.

4 Conclusions and Future Work WFMSs have provided support to the automated execution of work, enabling organizations to achieve a more coordinated and controlled work environment. However, today’s organizations require mobility, given place to the use of mobile computing that work, most of the time, in disconnected mode. In this paper, we presented the concept of disconnected workflow as a means of supporting the disconnected operations in a WFMS. We established requirements for supporting disconnected operations in WFMSs from: previous work reported in the literature, two case studies and WFMSs’ literature. Based on the requirements found during our literature review and through the realization of case studies, we established support for disconnected operation in workflow for the SysCoor WFMS architecture. Our proposal for disconnected operation is targeted to PDA devices as means to carry on workflow tasks. In this account, we designed the architecture in two parts, a centralized architecture, and lightweight client architecture, all of the above, through the use of XML to represent the workflow system and enable interoperability. Also, we have considered support to workflow processes where multimedia data is required.

An Architecture for Supporting Disconnected Operation in Workflow

291

We devise several benefits and advantages that can be obtained from the use of the SysCoor architecture and also from the implementation of disconnected operation. Some of these benefits are: 1. SysCoor represents and XML based architecture, this fact enables the possibility to transfer workflow definitions from other systems that implement the use of XML and also to transfer SysCoor XML documents to other XML- based workflow machines. 2. Since the client application is defined as a XML document, the client only needs an application capable of parsing those documents and some implementation that can implement the instructions defined in the documents. Therefore, this light-weighted architecture can be implemented in PDA devices with different processing capabilities. 3. The evaluation of the task disconnection feasibility enables an appropriated election of tasks to be disconnected in order to keep a coordinated workflow environment. We have explored the interoperability issue through the use of XML, however, in the future, we plan to do further work exploring aspects such as the integration of mobility supported with software autonomous agents, address the concurrency control handling issues and investigate mechanisms to support involuntary disconnections between others. Acknowledgments. This work was partially supported by CONACYT under grant C01-40799 and the scholarship 164716 provided to the first author.

References [1] [2]

[3] [4] [5] [6]

[7] [8]

Workflow Management Coalition. The Workflow Reference Model. Document number TC00-1003, January 19, 1995 Alonso G., Gunthor R., Kamath M., Agrawal D., El Abbadi A. and Mohan C. Exotica/FMDC: Handling Disconnected Clients in a Workflow Management System, IBM Almaden Research Center, In Proceedings of Third International Conference on Cooperative Information Systems, Vienna, May 1995 Bolcer G., Magi: Architecture for Mobile and Disconnected Workflow, IEEE Internet Computing. Vol. 4, No. 3, pages 46–54, June 2000 Greenberg S., Boyle M. and Laberge J. PDAs and Shared Public Displays: Making Personal Information Public, and Public Information Personal, Personal Technologies, March 1999 Grudin J. CSCW: History and Focus. Communications of the ACM. Vol 37, No 1, pages 92–105 Satyanarayanan M., Kistler J. J., Mummert L. B., Ebling M. R., Kumar P., and Lu Q. Experience with Disconnected Operation in a Mobile Computing Environment. In Proceedings of the 1993 USENIX Symposium on Mobile and Location-Independent Computing, Cambridge, MA, August 1993 Workflow Management Coalition. Workflow Process Definition Interface – XML process definition Language. Document number WfMC TC-1025, October 25, 2002. Kistler J., Disconnected Operation in a Distributed File System. PhD thesis. Department of Computer Science, Carnegie Mellon University, May 1993

292 [9] [10]

[11] [12] [13] [14] [15] [16]

P. Arroyo-Sandoval, A.I. Martinez-Garcia, and C. Ramirez-Fernandez Alonso G., Agrawal D., El Abbadi A. and Mohan C. Functionalities and Limitations of Current Workflow Management Systems, Research Report, IBM Almaden Research Center, 1997 Seungil L., Dongsoo H. and Dongman L. Supporting Voluntary Disconnection in WFMSs, Proceedings of the Third International Symposium on Cooperative Database Systems for Advanced Applications (CODAS 2001), pages 147–154, Beijing, April 23–24, 2001, China Pepin, C. and Kriger C., Creating a Lotus Notes application with Domino Everyplace Enterprise, The Technical Resource for Lotus Software, July 2002 Yung Y. Enabling Cost-effective Lightweight Disconnected Workflow for Web-based Teamwork Support, Journal of Applied Systems Studies, Cambridge, England, 2002. Garcia F., Ramirez C., Martinez A. and Rojas F. An Architecture for Generating Organizational Coordination Systems using Reusable Models in XML (Draft). CICESE Research Center, June 2002 Miers D. Use of Tools and Technology within a BPR Initiative in Business Process Reengineering, (Coulson-Thomas Colin ed.) Kogan Page Limited, pages 142–165, 1996 Rojas, F. and Martinez A. I., From Process Modeling to Enactment and Simulation. th Proceedings of the 12 European Simulation Multiconference, Manchester UK, pages 844–848, 1998 Ould, M. O. Business Process: Modeling and Analysis for Reengineering and Improvement. John Wiley and sons Inc, 1995

Interoperability of Workflow Engines Based on Agents Using Semantics Gabrielle D’Annunzio Cavalcanti and Pedro Porfírio Muniz Farias Department of Computer Science, University of Fortaleza-Unifor Fortaleza, Ceará, Brazil {gabrielle.mia,porfirio}@unifor.br

Abstract. Workflow environments produced by different manufacturers with different implementation characteristics do not share information regarding the control of the execution of process instances, except when developing specific applications. Although some manufacturers have adopted standards such as the Workflow Management Coalition – WFMC, there are still products of which the structure does not support such definitions, making information exchange between workflow engines a problem. A semantics-based approach enhances interaction between computer environments and is essential for an adequate understanding of the environment by the components involved. The present study presents a model for the process of interoperation between workflow engines applicable to the control of the execution of workflow instance processes on the internet. The model is based on agents, web services architecture and semantics for the handling of documents in the Wf-XML grammar standard.

1 Introduction The use of workflow technology is widely established within organizations. It is, however, not yet commonly applied to coordinating processes between organizations using the internet. Such coordination assumes the possible existence of differences between workflow engines used to communicate by established internet standards such as the XML, RDF and web services. In view of the need for interoperation between workflow engines, WFMC has outlined a workflow reference model [1,2] with 5 defined interfaces each of which presents a form of information exchange. Based on this reference model, WFMC has proposed a number of standards for the control of the execution of process instances between workflow systems, such as the Wf-XML standard [3] – an XML-based markup language intended for the exchange of requests and responses (synchronous and asynchronous). Some XML-based architectures and frameworks have been proposed [4,5,6,7] in order to make workflow system interoperation feasible. However, workflow system architectures using more recent internet standards, such as web services and semantic web, have not yet been fully established. Reference [9] presents the so-called DAML-S approach which is intended to make web services more semantic by integrating the ontology definition languages J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 293–299, 2003. © Springer-Verlag Berlin Heidelberg 2003

294

G. D’Annunzio Cavalcanti and P.P. Muniz Farias

(DAML+OIL) into the description layer of the web services, although this approach is not applied specifically to workflow systems. Agent technology is presently being used on the internet, especially for e-services, e-business and e-commerce. The characteristics of its architecture are well suited for the needs of the web in that it is both object-oriented and knowledge technologybased, a combination which makes it possible to transport code, data and knowledge. The semantic web is an extension of the current web and is intended to endow web page contents with meaning, thus defining an environment in which people and software agents can interact cooperatively [11]. In the scenario of agents being used on the web, the agents must be able to understand the meaning of the information exchanged in the environment in order to carry out their tasks. Reference [12] contains a semantic classification (implicit semantics, informal semantics, formal semantics for human processing and formal semantics for machine processing) which provides a definition of the niches of application at each level with an emphasis on the use of formal semantics for the processing of complex ontologies. Our study is centered on the development of a model for interoperating workflow environments in which the use of web services, semantic layers and agent-based technology is dealt with. The Wf-XML standard enables information exchange (operations of coordination, control, rules, etc.) between the work flows of workflow engine processes. Each engine offers access to its processes through web services and may access the processes of other engines through a semantic web services agent [10]. In section 2 we will describe the process of interoperation and in section 3 we will provide information regarding the progress of our work, the methodology applied and future perspectives.

2 The Process of Interoperation between Workflow Engines To make workflow engines interoperate it is essential to describe which processes will have an interface external to the workflow environment as well as to indicate the location of these processes. Web services architecture, DAML-S and the Wf-XML grammar specification will be used to describe the information required to connect the environments. It is therefore important to define an interface containing the information to be used during the process of interoperation. 2.1

The Interoperation Environment

The infrastructure to the process of interoperation, of which we will explore the communication, location and description layers, will be provided by web services (WS). We will use DAML-S to establish the semantic layer of the model, describing what the service can do, how the service works and how exactly the agent can access the service. DAML-S will be used as a layer to help automate web service tasks, such as discovery, execution, composition and interoperation, and execution monitoring [9].

Interoperability of Workflow Engines Based on Agents Using Semantics

295

The upper ontologies are defined in the DAML-S specification. They describe a set of specific classes and properties for the description of services. The upper class in the hierarchy of services is the Service which presents a ServiceProfile, is described by a ServiceModel and supports a ServiceGrounding. The ServiceProfile describes what the service does, providing the information required by the agent for determining whether the service meets the agent’s needs. The ServiceModel contains a description of how the service works when activated and may be used by a service-seeking agent for the monitoring of the execution of the service, for instance. The ServiceGrounding provides details of how the agent can access a service, such as the communication protocol and port number required to access that service [15]. The DAML-S proposal complementary involves the use of WSDL for the ServiceGrounding, establishing a correspondence so that the atomic DAML-S process corresponds to a WSDL operation, the input and output of the atomic process corresponds to the concept of input and output of a WSDL message, and the types of input and output of the atomic process correspond to the abstract-type extensive notion of WSDL [16]. The idea of this study is based on the use of a specific ontology for the interaction of workflow environments. As an example we have used the application of the Ceará State Government IT resources reserve, establishing the specifications of the names and terms appropriate for this domain. The essential function of workflow application is to register the request of a resource reserve (e.g.,datashow), to verify the availability of that resource and to inform the client on whether the request was successful. The information exchange between workflow environments is done with agent technology capable of interacting with web services. The language chosen for implementing the agent was Java because, among other things, Java is neutral, portable, object-oriented and harmonized with other standards (XML, DOM, etc.), and because it is by most computer professionals considered an adequate tool for the construction of agents. Figure 1 shows the interaction of a model in which the users of workflow environment #1 and workflow environment #2 execute activities within their own domains. When an activity within a process in a workflow engine requires information from another engine, a Java agent (or “Javagent”) activated by the process in the running engine effectuates the process of location, connection and information transfer between the web services. This process requires information on location, control and execution. Such information may be obtained either from the discovery/description layer of the web services or directly from within the workflow environment. Thus, the agent’s search mechanisms can make inquiries into external catalogues as well as into data bases within the agent’s own environment. The Wf-XML messages follow the operations which are defined within the basic groups for WFMC [3] interoperability. A request message is used to initiate an operation in a remote resource and/or provide input for this resource. On the other hand, a response message is used for transmitting the results of a request resource operation and thus constitutes output. The fact that the two types of message are complementary does not imply that every request must have a response. The following specific operations may be performed in the body of the message:

296

G. D’Annunzio Cavalcanti and P.P. Muniz Farias

1.

Request operations: CreateProcessInstanceState.Request, ChangeProcessInstanceData.Request, GetProcessInstanceData.Request and ProcessInstanceStateChanged.Request;

2.

Response operations: CreateProcessInstanceState.Response, ChangeProcessInstanceData.Response, GetProcessInstanceData.Response and ProcessInstanceStateChanged.Response.

A process is associated with specific data items within itself. These data may represent properties of the process instance or any data related to the invoking of applications during process execution. The process context is in the request message and the result in the response message. Reference [3] provides a complete description of the Wf-XML language.

Fig. 1. Interoperation Scenario

The “Javagent” is used in different workflow environments and their respective web services. It is designed so as to format request messages and read response messages, according to the Wf-XML specifications described above, and to deal with the requirements of web services and DAML-S. The requests transmitted by the “Javagent” are received by the web service which in turn sends them to the workflow engine of its own environment. If necessary, the web service will respond to the “Javagent” with a response message. In an IT resource reserve process the user executing a workflow application instance in environment #1 performs the procedure of reserving that resource which in turn interacts with the web service. At this point the agent is activated in order to locate the first environment which satisfies the condition and then sends on the request. Environment #2 deals with the request in its web service conveying it to the workflow engine. Confirmation messages are transmitted from environment to environment providing information on the progress of the request. Exceptions will be treated in accordance with the Wf-XML specification. Some workflow tool suppliers, such as IBM and Microsoft, apply web services architecture in order to provide an interface for their platforms. However, the web services of these suppliers may or may not use Wf-XML since they are not limited to integrating workflow engines.

Interoperability of Workflow Engines Based on Agents Using Semantics

2.2

297

The Use of DAML-S

The use of DAML-S complements the description of Web Services at application level, describing what the service can do and not just what it happens to be doing, and providing additional information for the agent’s decision making. DAML-S describes a specific set of properties and classes for the description of web services. Reference [9] offers detailed specifications and an example of the markup described upon the original release of DAML-S. We have used a variation of this example to illustrate our point. The DAML-S process model defines programs as an either atomic or composite process. As a complement, it also allows the notation of simple process used to describe the view, abstraction or instantiation of atomic and composite processes. The atomic process is executed a simple call which elicits a response, but it does not require a longer conversation between the program (agent) and the WS. In this context we could give the locateResource service as an example, with the resource’s name as an input and a position of availability (yes/no) as an output. A composite process consists of atomic processes or of other composite processes using control constructs, such as the if-then-else of programming language, and determines the order and conditions of process execution. An example of this would be the combination of the locateResource service and the reserveResource service, the latter depending on the former for its execution. Our approach consists of using Wf-XML request and response operations within the DAML-S process model and thus allows us to restrict ourselves to the use of atomic and composite processes.

3 Present Situation and Expected Results The contribution of the present study consists in describing a model for the process of interoperation between different workflow engines within the internet architecture, using web services, semantic web and agent technology. We have used the UML language for the designing of our model. We have now concluded the requirement analysis stage and are currently outlining the project. A web services infrastructure has been defined in the Linux environment using the java webservice developer pack - JWSDP. In this environment we will use an IBM

298

G. D’Annunzio Cavalcanti and P.P. Muniz Farias

workflow tool currently in use in our work domain. We will set up another web services infrastructure with a workflow environment on a platform different from the first one used. The coming steps: 1) the conclusion of the WS service descriptions, including the description of DAML-S; 2) implementation of Java agent classes; 3) environment setup for the validation of the model with the application of an IT resource reserve within the Ceará State domain. We expect to attain semantic web service interoperation for multiple workflow environments through the validation of the use of DAML-S together with definitions of web services and of Wf-XML operations.

References 1. Hollingsworth, David – The WorkFlow Reference Model – Document TC00-1003-WFMC – Workflow Management Coalition- january, 1995 – access 28/06/2002 http://www.wfmc.org/standards/docs/tc003v11.pdf 2. The WorkFlow Stardard Interoperability Abstract Specification – Document WFMC-TC1012 - WFMC – Workflow Management Coalition - november, 1999 – access 28/06/2002 http://www.wfmc.org/standards/docs/TC-1012_Nov_99.pdf 3. Workflow Stardard Interoperability Wf-XML binding - Document WFMC-TC-1023 – WFMC – Workflow Management Coalition – may, 2000 - access 28/06/2002 http://www.wfmc.org/standards/docs/Wf-XML-1.0.pdf 4. Muehlen, Michael zur: ”A Framework for XML-based Workflow Interoperability – The AfricaProject”, http://www.wi.unimuenster.de/is/mitarbeiter/ismizu/MIZU-AMCIS2000.pdf, 11/2001 5. Shegalov, German; Gillmann, Michael; Gerhard, Weikum: “XML-enabled Workflow Management for E-Services across Heterogeneous Platforms”, http://wwwdbs.cs.uni-sb.de/~gillmann/Publications/XML-TES.pdf, 11/2001 6. Chen, Qiming; Dayal, Umesh; Meichun, Hsu; Griss, Martin: “Dynamics-Agents, Workflow and XML for e-commerce Automation”, HP Labs, Hewlett-Packard; http://www.hpl.hp.com/org/stl/dmsd/publications/qchen_EC2000. pdf; 11/2001 7. Kumar, Akhil: “Workflow Support for Electronic Commerce Applications”, International Conference on Telecommunications and Electronic Commerce, Nashiville, TN, October 1998, http://shell.bpa.arizona.edu/~lzhao/DSS01-KZ-Accepted.pdf, 11/2001 8. M. Wooldridge and N.R. Jennings: “Intelligent Agents: Theory and Practice”, http://www.csc.liv.ac.uk/~mjw/pubs/Ker95.ps.gz 9. The DAML Services Coalition: “DAML-S: Semantic Markup for Web Services”, http://www.daml.org/services/daml-s/0.7/daml-s.pdf 10. McIlraith, Sheila A : “Semantic Web Services” , Stanford University, IEEE Intelligent Systems, march/april 2001 11. T. Berners-Lee, J. Hendler, O. Lassila: “The Semantic Web”, Scientific American, 2001, http://www.scientificamerican.com/2001/0501issue/0501bernerslee.html 12. M. Uschold, M. Gruninger: “Creating Semantically Integrated Communities on the www”, Semantic Web Workshop, 2002

Interoperability of Workflow Engines Based on Agents Using Semantics

299

13. Sollazzo, Tanja; Handschuh, Siegfried: “Semantic Web Service Architecture – Evolving Web Services Standards toward the Semantic Web”, http://www.aifb.unikarlsruhe.de/WBS/sst/Research/Publications/sub-flairs2002.pdf 14. Shegalov, German; Gillmann, Michael; Gerhard, Weikum: “ XML-enabled Workflow Management for E-Services across Heterogeneous Platforms ”, University of the Sharland, Department of Computer Science, DE; http://www-dbs.cs.uni-sb.de/~gillmann/Publications/XML-TES.pdf, 11/ 2001

15. DAML-S 0.7 Draft Release: http://www.daml.org/services/daml-s/0.7/ 16. DAML-S Coalition : “DAML-S: Web Service Description for the Semantic Web”, http://www.daml.org/services/ISWC2002-DAMLS.pdf 17. M. Wooldridge and N.R. Jennings : “Intelligent Agents: Theory and Practice”, http://www.csc.liv.ac.uk/~mjw/pubs/Ker95.ps.gz 18. Carlson, David; “Modeling XML Aplication With UML, Pratical e-Business plications”, Addison Wesley, USA, April 2001 19. Narayanan, Srini; McLiraith, Sheila A : “Simulation, Verification and Automated Composition of Web Services”; http://www.acm.org 20. Cabri, Giacomo; Leonardi, Letizia; Zambonelli, Franco: “XML Dataspaces for Mobile Agent Coordination”, Università di Modena e Reggio Emilia, Dipartimento di Scienze dell’Ingegneria, Modena, ITALY http://sirio.dsi.unimo.it/MOON/papers/ SAC00.pdf ; 11/2001 21. Lassila, Ora: “Serendipitous Interoperability”, Semantic Web Kick-off in Finland, may 19, 2002, http://www.lassila.org/publications/ 22. Larman, Craig: “Utilizando UML e Padrões “, Editora: Bookman ISBN : 8573076518

A Conceptual Framework for Analyzing the Use of Context in Groupware 1

2

2

Márcio G.P. Rosa , Marcos R.S. Borges , and Flavia M. Santoro 1

Departamento de Ciências da Computação/UFRJ Caixa Postal 2324, Rio de Janeiro, 20001-970, RJ, Brasil [email protected] 2 Departamento de Ciências da Computação and NCE/UFRJ Caixa Postal 2324, Rio de Janeiro, 20001-970, RJ, Brasil {mborges,flaviams}@nce.ufrj.br

Abstract. This article presents a conceptual framework for the identification and classification of contextual elements included in groupware applications. Contextual elements store information that helps group members to characterize and to understand the interaction and its associate information. The conceptual framework can be used not only to guide the development of new groupware applications but also to analyze existing groupware. We illustrate the use of the framework in the analysis of three groupware tools.

1

Introduction

The groupware support to cooperative groups aims at generating better results than when team members work together without computational support. Fast communication channels for distributed teams and computerized memory are only two examples of where technology may enhance the group’s interaction. However, technology also gives rise to problems, which are hard to overcome, making existing complex tasks even harder to accomplish. One of the most important aspects in supporting cooperation is the context upon which interaction occurs among group members. Perhaps because in face to face interactions this aspect is almost taken for granted, many groupware tools have almost completely neglected the presentation of contextual information. Another reason may be due to the complexity of dealing with many kinds of context. Whichever is the case, however, the absence of support to contextual elements may reduce the value of the groupware and in some cases jeopardize its benefits. Contextual elements can be about group members, the group itself, the scheduled and the completed tasks, the interaction that led to the concluded task and about the environment where the interaction took place. This information helps group members to know each other and be aware of their goals and the issues that influence them. With this information at hand, the group should be able to increase their level of awareness and cooperation. This paper addresses the identification and the representation of contextual elements aimed at increasing the level of cooperation among group members. By explicitly defining contextual elements, we believe we can help groupware designers in J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 300–313, 2003. © Springer-Verlag Berlin Heidelberg 2003

A Conceptual Framework for Analyzing the Use of Context in Groupware

301

including these elements in their systems. Another possibility is to include them as components in groupware toolkits, as proposed by David and Borges [8]. The need for the framework is justified because groupware designers do not usually provide contextual information. When analyzing some groupware systems we can notice that contextual information is neither explicitly dealt with nor, when present, well thought of. By analyzing the groupware system by using the framework we can show what may be missing in order to create a more complete tool. We believe this framework proposal is a first step towards the building of a library of contextual elements, which can be used by groupware designers in building their applications. To present our framework we first present a review of the main concepts behind context and groupware. Next we describe the proposed framework that consists of five types of context related to the group’s interactions. We then apply the framework to identify the contextual elements present in three sample groupware applications. Finally, we conclude the paper with a discussion of the utility of the framework and the next steps of our work.

2

Context and Groupware

The issue of context has been an important area of research in recent years, although, there is no consensus as yet about what context really means, what its implications are and how it can be generalized [15]. Several domains have already elaborated their own working definition of context. In a human-machine interaction, a context is a set of information that could be used to define and interpret a situation in which interact agents [4]. In the context-aware applications community, the context consists of a set of information for characterizing the situation, which interact humans, applications and the immediate environment [9]. In artificial intelligence, the context does not intervene directly in problem solving but constrains it [5]. When we use the term context we should always refer it to something. There is no definition of context out of a context [4]. We can reference the context of a dissertation, a computer science course, a football game, etc. In this article, for example, the context of our work is groupware systems and applications. Brézillon and Pomerol [6] proposed a classification for differentiating the contextual elements related to task performing. The set of contextual elements that are relevant to the task realization is called contextual knowledge. The knowledge that is shared by all people involved but is not used to perform a task is called external knowledge. During the execution of a task, a portion of the contextual knowledge is actually employed. This portion is called proceduralized context (Figure 1). In the area of CSCW Araújo, Dias and Borges proposed a conceptual framework for the understanding of group support in collaborative projects [1]. Gutwin, Stark and Greenberg developed a framework for the categorization of awareness in cooperative learning [13]. Groupware usability in shared workspaces was the theme of a conceptual framework developed by Gutwin and Greenberg [12]. Other relevant work in the CSCW area is The Denver Model for Groupware Design, a nested collection of models describing the generic elements of any groupwareapplication. The first model consists of three sub models describing three aspects of

302

M.G.P. Rosa, M.R.S. Borges, and F.M. Santoro

Fig.1. Three types of context

constructing and reviewing groupware applications: requirements, design and technology. According to the design’s sub model, groupware applications can be characterized as five categories related to: people, artifacts, tasks and activities, interactive situations and social protocols (Figure 2) [18].

Fig. 2. The Denver Model for Groupware Design

In real life a context is a complex description of shared knowledge about physical, social, historical, or other circumstances within which an action or an event occurs. In order to fully understand many actions or events, it is necessary to have access to relevant contextual information [2]. A common drawback of many groupware tools is the lack of support to contextual information, making the cooperation hard to achieve. When people work cooperatively as a team, the knowledge about the contextual elements related to the interactions is very relevant to achieving a high level of coop-

A Conceptual Framework for Analyzing the Use of Context in Groupware

303

eration. The context of the group is not simply the union of all individual contexts. It consists of information about the group, such as its composition, social protocols, goals, strategies, etc. Another important aspect is the proceduralization of the context by the group. Again, this proceduralization should occur in addition to the individual process [2].

3

A Conceptual Framework

According to Greenberg [11], a context is a dynamic construction that can be viewed in five dimensions: (1) time, (2) usage episodes, (3) social interactions, (4) internal goals, and (5) local influences. Although the contextual elements in some situations are very stable, understandable and predictable, there are some situations when this does not occur. Situations with apparently the same context can differ from each other. Several aspects of these situations can explain this case. Among them, we can select the previous experience of the group, the task’s characteristics, and the social and the technical facets of the interactions. This diversity and unpredictability of the aspects are factors that have a negative influence on the identification and the representation of the contextual elements related to group interactions. In order to reduce this impact, we propose the use of a conceptual framework aimed to identify and classify the contextual elements most common in groupware tools. Conceptual frames will represent this framework. The goal of the framework is to supply guidelines for research and development in the area of groupware and context [19]. Several proposals have been presented to classify context in particular domains. In the area of Intelligent Tutoring Systems (ITS), a framework for the classification of context has been divided into three groups: Interactional context, Environmental context and Objectival contexts [15]. In context-aware applications, the contextual information has been classified in four categories: identity, location, status (or activity) and time [9]. The conceptual framework proposed in this work considers the relevant elements for the analysis of the use of context in groupware applications. The contextual information is clustered in five main categories: (1) information about people and groups, (2) information about scheduled tasks, (3) information about the relationship between people and tasks, (4) information about the environment where the interaction takes place and (5) information about tasks and activities already concluded. The clusters were derived from the Denver Model [18], and in each cluster we try to identify the most relevant aspects of the interaction that influence the performing of group tasks. In groupware synchronous environments, group members need to work simultaneously, but in asynchronous environments, there might be a time lag between the interactions. The needs of each type of environment are different, especially in relation to contextual information and the awareness required in each situation [16]. This justifies why in our framework we analyze each situation differently. The framework proposed is a generic classification of contextual elements. It neither covers the particularities of a specific domain nor applies to a particular type of groupware. This generic framework can be seen as a starting point to a more specific

304

M.G.P. Rosa, M.R.S. Borges, and F.M. Santoro

classification of contextual elements in particular domains, where new contextual elements may be considered relevant. In the next sub-sections we will describe seven types of contextual information grouped into the five categories. According to McCarthy [14], the size of the contextual dimension is infinite. Therefore, we will consider only the contextual elements, which we believe are the most relevant to task oriented groups; the contextual knowledge and the proceduralized context [3]. 3.1

Information about Individuals

This is information about the individuals and the groups they belong to. The knowledge about the group’s composition and its characteristics is important for the understanding of the potential ways the project or task will be developed. The knowledge about the characteristics of individuals and the group as a whole encourages the interaction and the cooperation [16]. The type of interaction - synchronous or asynchronous, does not influence this aspect of the context. In other words, the knowledge about individuals and groups is required independent of the timing aspect of the interaction. We divided this category into 2 types of context.

• Individual Context: Information about the individual who is a member of a group. It includes information about his/her abilities, interests, location, previous experience personal data and working hours, among others • Group Context: Information about the characteristics of the team. The data is similar to the aforementioned, but related to the group. They include the composition of the team, its abilities and previous experience as a group, the organizational structure, e.g. the group’s coordination, location, and working hours. 3.2

Information about Scheduled Tasks

This type of information tries to characterize the tasks to be performed by the group. The interaction may be synchronous or asynchronous, but it does not influence the contextual elements. In other words, independent of how the interaction occurs, the group members need to be acquainted with task characteristics. Task context is the name given to this context.

• Task Context: It stores the information about a task. Its goal is to identify tasks through its relevant characteristics. Among these characteristics, we can select the task name, its description and goals, the deadline, the predicted effort, the technology and other requirements and pre-conditions. 3.3

Relationship between People and Tasks

This type of information aims to represent the relationship between the members of the group and the scheduled tasks. Its goal is to relate the action of each group member and the interaction they are involved in, with the tasks and their corresponding

A Conceptual Framework for Analyzing the Use of Context in Groupware

305

activities, which are being developed. In the scope of this work, the interaction developed among group members begins with an execution plan and terminates when the task concludes, passing through a sequence of actions required for carrying out the plan. In some situations the interaction may be interrupted before the task is concluded. The reason for this premature termination is also part of the context and is relevant to the understanding of what justified the interruption. For this group of information we also identified two types of contexts:

• Interaction Context: It consists of information that represents the actions, which took place during the task completing. It depends on the type of interaction. According to Pinheiro et al [16], when the interaction is synchronous, it is very important to be aware of the details of the activity at the time it occurs, while in asynchronous interactions it is more important to provide an overview of the activities instead of details, at least at the first level of awareness. In the case of synchronous groupware, the interaction context includes detailed information about on-going tasks. This includes step-by-step details of activities performed towards the conclusion of the task. • Planning Context: It consists of information about the project execution plan. This information can be generated at two different points. In the case of ad-hoc tasks, they appear as a result of the interaction, which decided about it. For the scheduled tasks, they are generated at the time of the plan, i.e., when the tasks are defined and the roles associated with them. They include rules, goals, deadline strategies, coordination activities, etc. 3.4

Information about the Environment

This type of information represents the aspects of the environment where the interaction takes place. It covers both the organizational issues and the technological environment. In other words, all information outside the project but within the organization that can affect the way the tasks are performed.

• Environment Context: It consists of information that characterizes the environment where the interaction takes place and that influences the task completion. The environment gives some additional indications to group members about how the interaction will occur. For example, the quality control patterns are part of this context. Strategy rules, policies, financial restrictions and institutional deadlines are other examples of this context. 3.5

Information about Concluded Tasks

This information tries to characterize the interactions that have already occurred. Its goal is to provide background information about the experiences learned either from the same group or similar tasks performed by other groups. It should include all contextual information about previous projects, which can be useful to future projects.

306

M.G.P. Rosa, M.R.S. Borges, and F.M. Santoro Table 1. Conceptual framework for the analysis of context in groupware applications

Information type

Group Members

Associated Contexts Individual (Synchronous & Asynchronous) Group (Synchronous & Asynchronous)

Scheduled Tasks

Relationship between people and tasks

Task (Synchronous & Asynchronous)

Goals

Examples of contextual elements

To identify the participants through the representation of their personal data and profiles.

• • • •

To identify the group through the representation of its characteristics

• • • • • • • • • •

To identify the tasks through the representation of its characteristics.

Name Qualifications Interests Academics Education Name Members Roles Abilities Name Description Goals Deadlines Group in-charge Messages exchanged Presence Awareness

Interaction (Synchronous)

To represent in detail the activities performed during the task completing.

Interaction (Asynchronous)

To represent an overview of the activities performed during the task completing.

• Group in-charge • Artifacts generated • Versions

To represent the Execution Plan of the task to be performed

• Roles in the interaction • Rules • Aim • Quality patterns • Rules • Policies • Institutional deadlines • Task Name • Activities • Author • Goal • Justification • Date

Planning (Synchronous & Asynchronous)

Setting

Environment (Synchronous & Asynchronous)

Completed Tasks

Historical (Synchronous & Asynchronous)

To represent the environment where the interaction occurs; i.e., characteristics that influence task execution. To provide understanding about tasks completed in the past and their associated contexts.

•

• • • •

Previous experience Location Working hours Web page

• • • • • • • • • •

Previous experience Organizational Structure Location Working hours Estimated effort Activities Restrictions Workflow Gesture awareness Concluded Activities • Author • Goal • Report • Activities completed • Author • Goal • Report • Timestamp

• • • • • • • •

Responsibilities Strategies Coordination Procedures Working Plan Organizational structure Financial constraints Standard procedures Standard strategies

• Versions of the artifacts • Contextual elements used to carry out the task • Working Plan • Task Goals

At the end of a project all contextual information generated and used should be selected, clustered and stored for future retrieval. The type of interaction - synchronous or asynchronous - in this case part of the information is stored, but it does not influence the context itself. We called this set of information ´historical context´.

• Historical Context: It consists of information about projects and tasks already concluded. This information is important for the understanding of errors and successful approaches in previous projects to be used in current tasks. It can also be used out of the context of a project to provide insight into working practices and team cooperation. The tool should not only store the information concerned with the current project but also provide support for the selected retrieval of past projects. The appropriate selection and the granularity of the information are key factors for the use of this context. Granularities, which are too coarse or too fine, may not provide the necessary aid for group members.

A Conceptual Framework for Analyzing the Use of Context in Groupware

3.6

307

A Summary of the Framework

After identifying the seven types of contexts we can group them in a framework table shown in Table 1. In this table we present a summary of each context and provide some examples of information that can influence the interactions in the group.

4

Applying the Framework

In order to provide the first test for the framework, we analyzed three groupware tools in relation to their treatment to contextual elements. The three tools selected were the BSCW – Basic Support for Cooperative Work [7], the FLE3 – Future Learning Environment [10], and the Quickplace 3 [17]. The result is reproduced in two tables. Table 2 lists the contextual elements identified in each tool. Table 3 describes how each tool would fit into the seven contexts of the framework. At the end of the section we discuss the application of the framework. BSCW. The BSCW Shared Workspace System is a groupware application, developed at the GMD - German National Research Center for Information Technology. The BSCW runs on the Web and supports both synchronous and asynchronous interactions among group members. The system’s central metaphor is the shared workspace. The workspace contains several types of objects, such as documents, pictures, discussion lists, tables, spreadsheets, and so forth. Group members asynchronously access the shared workspace to carry out their tasks. The support to synchronous interaction is provided by two mechanisms: a meeting support tool and a Java applet, called JMonitor. FLE3. The FLE3 is a collaborative learning environment based on the Internet. It consists of three learning aid tools: 1. The WebTop can be used by learners and instructors to store and share several types of documents related to the object of study. The documents can be organized into folders associated to each course. The two other tools share these folders. 2. The Knowledge Building is a discussion forum where most of the group’s knowledge is actually built. The messages exchanged during a discussion can be classified according to an attribute named “knowledge type”, which identifies the type of knowledge assumed by its author for each message presented. 3. Jamming is a shared workspace for the cooperative building of multimedia artifacts (photos, audio, video, etc). The Jamming allows the preservation of an object’s data by storing the versions generated during its lifetime. Quickplace 3. The QuickPlace 3 is a groupware system based on the Web. The central metaphor is the shared workspace, similar to the BSCW. The workspace can store any type of document, such as spreadsheets, discussions, workflows, and so on. The Quickplace 3 allows the publication and the sharing of any type of information relevant to the collaborative project. Besides this basic functionality, the system supports group discussions, agenda, chats, event notification and the evolution of the documents stored in the workspace.

308

M.G.P. Rosa, M.R.S. Borges, and F.M. Santoro Table 2. Contextual elements identifyed in each tool

Contexts Individual (Synchronous & Asynchronous) Group (Synchronous & Asynchronous) Task (Synchronous & Asynchronous)

Interaction (Synchronous)

Interaction (Asynchronous) Planning (Synchronous & Asynchronous) Environment (Synchronous & Asynchronous)

Historical (Synchronous & Asynchronous)

4.1

Examples of contextual elements Name Abilities Interests Academic background Experience Name Components Roles Abilities Interests Name Description

B

F

Q

Ok X X X X Ok Ok Ok X X Ok Ok

Ok X Ok X Ok X X X X X X X

Ok X X X X Ok Ok X X X Ok Ok

Goal Deadline Requirements Assigned group

X X X Ok

X X X X

X X X Ok

Presence Notion Messages exchanged Gestures

Ok Ok X

X X X

Ok Ok X

Assigned group

Ok

Ok

Ok

Actions performed Author of each action Goal of each action Roles in the task Plan rules

Ok Ok X Ok X

Ok Ok X X X

Ok Ok X X X

Goals Responsibilities Quality patterns Rules

X X X X

X X X X

X X X X

Procedures Strategies Task name Task description Task Goals

X X Ok Ok X

X X Ok Ok X

X X Ok Ok X

Implementation plan Tasks performed

Ok Ok

X Ok

Ok Ok

Examples of contextual elements Organization Location Working hours Personal data Personal Web Page Experience Organizational structure Location Working hours

B

F

Q

X X X Ok Ok X X X X

Ok X X Ok Ok X X X X

X X X Ok X X X X X

X X

X X

X X

X X

X X

X X

Actions to be performed Author of each action Goal of each action Justification for the action Justification for the action Artifact version Working period

Ok

X

Ok

Ok X X

X X X

Ok X X

X

X

X

Ok Ok

Ok Ok

Ok Ok

Strategies Coordination Procedures Implementation plan

X X

X X

X X

Ok

X

Ok

X X

X X

X X

X X Ok X X

X X Ok X X

X X Ok X X

Ok Ok

Ok Ok

Ok Ok

Estimated effort Actions to be performed Restrictions Technology

Institutional deadlines Organizational structures Policies Financial restrictions Author of each action Goal of each action Justification for the action Working period Information about other contexts used in the task

Using the Framework to Analyze the Tools

Table 2 presents the evaluation of the contextual elements identified in each of these three tools using the framework. In Table 2 the B refers to BSBW, the F refers to FLE3 and the Q refers to Quickplace. The Ok means the groupware tool supplies this contextual information, while the X means the absence of context. Figure 3 shows the way the BSCW deals with the team contextual information. Figure 4 reproduces the context interaction support in FLE3. The task context provided by

A Conceptual Framework for Analyzing the Use of Context in Groupware

Fig. 3. Team context in BSCW

Fig. 4. Interaction Support in FLE3

309

310

M.G.P. Rosa, M.R.S. Borges, and F.M. Santoro

Fig. 5. Task context in Quickplace 3

Fig. 6. Planning context in Quickplace 3

Quickplace is reproduced in Figure 5. Figure 6 illustrates the planning of activities also in Quickplace 3. Based on the contextual elements identified in the tools we can then use the framework to provide a simple comparison of how the three tools deal with contextual information. This comparison is provided in Table 3. 4.2

Discussion

We can conclude at this point that the framework achieved its main objective, i.e., to be a first step towards the understanding of how contextual information is represented in groupware tools. We noticed a close relationship between the framework classification and the treatment given to contextual information by groupware tools. In the application of the framework we identified some contextual elements in which specificity did not fit into our classification. An interesting example is the “type of knowledge” information in FLE3, a contextual element relevant to cooperative learning domains. In these cases, it is important to check if it corresponds to a more generic class in the framework, which was the interaction context.

A Conceptual Framework for Analyzing the Use of Context in Groupware

311

Table 3. Conditions to deal with contextual information Contexts Individual (Sync & Async) Group (Sync & Async) Task (Sync & Async)

Interaction (Synchronous)

Interaction (Asynchronous)

Planning (Sync & Async)

Environment (Sync & Async)

History (Sync & Async)

BSCW

FLE3

Quickplace

Very comprehensive about the identification, but it does not characterize him/her. It adopts the team’s concept, but it does not describe the group’s characteristics. It defines task explicitly. It allows the definition of tasks, but it does not provide additional details. It supports only message exchange. It associates messages with their authors. It provides the notion of presence. It does not support the definition of goals and their justifications. It identifies the tasks in operation listing their authors and dates. It does not support the definition of goals and justifications. It is represented through a calendaring function that stores part of the execution plan and the role of each member in the plan. The application does not support the representation of information about the environment supported by the application. All relevant information about past tasks are stored and a simple retrieval mechanism is provided.

Very comprehensive. It provides information about his/her experience and its role. There is no group concept implemented.

Little information about the individual. It is not possible to characterize him/her. It adopts the team’s concept, but it does not describe the group’s characteristics. It defines task explicitly. It allows the definition of tasks, but it does not provide additional details. It supports only message exchange. It associates messages to its authors. It provides the notion of presence. It does not support the definition of goals and their justifications. It identifies the tasks in operation listing their authors and dates. It does not support the definition of goals and justifications. It is represented through a calendaring function that stores part of the execution plan.

It does not define task explicitly. The task definition is done without system support. It does not support synchronous interaction.

It identifies the tasks in operation listing their authors and dates. It does not support the definition of goals and justifications. There is no support to planning context.

The application does not support the representation of information about the environment supported by the application. All relevant information about past tasks are stored and a simple retrieval mechanism is provided.

The application does not support the representation of information about the environment supported by the application. All relevant information about past tasks are stored and a simple retrieval mechanism is provided.

On the other hand, some contextual elements may not be relevant to certain application domains. Its absence in the groupware tool does not represent a negative aspect. For example, the organizational structure may not be relevant to CSCL applications. Therefore, when applying the framework we should take into consideration the aim of each application. An important aspect observed in our study is that not all contextual elements can be embedded in a groupware system. However, this fact doesn’t mean that they are not implemented into the work practices of the team. The group, in some cases, can implement these elements by other means. The analysis of the groupware tools using the framework showed they have similar characteristics in relation to contextual information. Other conclusions worth mentioning are: 1. All three groupware partially cover the individual, group, task and interaction contexts; 2. The environmental context is not addressed by any of these tools, indicating that this type of context is not calling the attention of groupware designers;

312

M.G.P. Rosa, M.R.S. Borges, and F.M. Santoro

3. The contextual elements available in all three tools identify the cooperative actions, but they are not able to answer why certain action was carried out. In other words, there is no concern for the justification of actions; 4. In the three tools there is no separation between the historical and the other contexts. All contexts are stored, but there is not a clear division between contexts, which are current and those, which have become historical.

5

Conclusions

This article presented a framework for the classification of the various types of context, which comprises the interaction among group members supported by a groupware tool. The framework classified the context, which embodies the interactions in a groupware application into five main categories: (1) information about the group and its members – individual and team contexts; (2) information about the scheduled tasks – task context; (3) information about the relationship between group members and tasks – interaction context and planning context; (4) information about completed tasks – historical context; and (5) information about the environment where the tasks are performed – environment context. For each type of context, we described its definition and some examples of information that is normally associated with this context. We also listed some applications, which already represent this context in some way. Then, we applied the framework in the identification of contextual elements present in the three groupware tools. The use of the framework for analyzing current groupware applications confirmed what we expected; that few contextual elements are supported by these tools. Although, some sort of support is always provided, they are seldom treated as an important aspect of the groupware tool. We firmly believe there is a clear need for explicit support of context in groupware tools. The framework is considered as the first step towards offering assistance to groupware designers wanting to include contextual elements in their tools. The framework needs to be further evaluated by applying two approaches. Firstly, we need to test its comprehensiveness, that is, to check if the framework covers all contextual elements relevant to groupware applications. Secondly, we would like to verify the correlation between each contextual element and the change in the level of cooperation among group members who make use of the tool. Acknowledgement. Márcio G.P. Rosa is sponsored by NCE (Master Thesis Scholarship). Flávia Santoro is sponsored by FAPERJ (process #E-26/152.116/2001).

References 1. Araujo, R.M., Dias, M.S., Borges, M.R.S., “A Framework for the Classification of Computer-Supported Collaborative Design Approaches”, Third CYTED-RITOS International Workshop on Groupware, pp. 91–100, El Escorial, Spain, September 1997 2. Borges, M.R.S., Brézillon, P., Pino, J. A. and Pomerol, J.-Ch., “Context and Awareness in Group Work”, Article submitted for publication

A Conceptual Framework for Analyzing the Use of Context in Groupware

313

3. Brézillon, P. “Individual and team contexts in a design process”. Proceedings of the 36th Hawaii International Conference on Systems Sciences, HICSS-36, Track "Collaboration Systems and Technology", R.H. Sprague (Ed.), IEEE, Los Alamitos, January 2003, In CD-ROM 4. Brézillon P. “Making context explicit in communicating objects”. In Communicating Objects, C. Kintzig, G. Poulain, G. Privat, P.-N. Favennec (Eds.), Hermes Science Editions, Lavoisier, 2002 5. Brézillon P., “Context in problem solving: A survey”. The Knowledge Engineering Review, vol. 14, n°1, 1999, pp. 1–34 6. Brézillon P. e Pomerol J.-Ch. “Contextual knowledge sharing and cooperation in intelligent assistant systems”. Le Travail Humain, 62 (3), PUF, Paris, 1999, pp.223–246 7. http://bscw.gmd.de/ 8. David, J.M.N. & Borges, M.R.S., “Supporting Context-Awareness in Web-based Groupware Development”, Article submitted for publication, 2003 9. Dey, A.K., Salber, D. Abowd, G.D. “A Conceptual Framework and a Toolkit for Supporting the Rapid Prototyping of Context-Aware Applications”, anchor article of a special issue on Context-Aware Computing, Human-Computer Interaction (HCI) Journal, Vol. 16(2–4), 2001, pp. 97–166 10. http://fle3.uiah.fi/ 11. Greenberg, S., “Context as a Dynamic Construct”. Human-Computer Interaction, 16 (2–4), Lawrence Erlbaum Associates Inc., 2001, pp. 257–268 12. Gutwin, C. e Greenberg, S., “The Mechanics of Collaboration: Developing Low Cost Usability Evaluation Methods for Shared Workspaces”. IEEE 9th International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises (WET-ICE'00). June 14–16, held at NIST, Gaithersburg, MD USA 13. Gutwin,. C., Stark, G. e Greenberg, S. “Support for Workspace Awareness in Educational Groupware”, CSCL '95 Proceedings 1 September 1995 th 14. McCarthy, J., "Notes on formalizing context", Proceedings of the 13 IJCAI, 1993, Vol. 1, pp 555–560 15. Patel A, Russell D, Kinshuk, Oppermann R and Rashev R (1998) “An initial framework of contexts for designing usable intelligent tutoring systems”, Information Services and Use, 18 (1,2), IOS Press, Amsterdam, 1998, pp. 65–76 16. Pinheiro, M.K., Lima, J.V., Borges, M.R.S.,"Awareness em Sistemas de Groupware", In Proc. of the IDEAS 2001, San Jose, Costa Rica, April 2001, pp. 323–335 17. http://lotus.com/products/qplace.nsf/homepage/$first 18. Salvador, T., Scholtz, J., Larson, J. “The Denver Model for Groupware Design”, SIGCHI Bulletin Vol.28, No. 1, January 1996 19. Santoro, F.M., Borges, M.R.S., Santos, N. “Um framework para estudo de ambientes de suporte à aprendizagem cooperativa”, Revista Brasileira de Informática na Educação, n. 04, April 1999, pp. 51–68 (in Portuguese)

Application Design Based on Work Ontology and an Agent Based Awareness Server Rosa Alarcón and David A. Fuller Pontificia Universidad Católica de Chile, Computer Science Department Vicuña Mackenna 4860, 6904411, Santiago, Chile {ralarcon,dfuller}@ing.puc.cl

Abstract. Collaborative Systems support user groups enabling a shared environment and informing of its state and changes through a mechanism called awareness. We believe that these changes and their consequences can be understood from an interpretation context, this approach allows us to infer the relevance of the awareness information and control its delivery trough different channels. The mechanism is enabled through a Multi-Agent System (MAS). We built a collaborative scheduler to test these ideas and we present a case study based on its use. We found that those ideas significantly ease the construction of different interfaces for the same problem while application usability is not impacted.

1 Introduction Collaborative systems allow groups of users to share software artifacts, objects and self-representations enabling for them a virtual shared environment whose state and changes are presented through a mechanism called Awareness [1,2,3]. Users must explore the environment in order to discover any change made, or they can be notified automatically with the risk to be flooded (if every change is notified). To avoid this risk the current approach consists in choosing a set of interesting events to be informed about, but when the environment is dynamically constructed, those objects are created on the fly, so the notification can even be nonexistent. We believe that based on their semantics, every action that occurs in the shared environment can be automatically notified to users. That is we need to understand the context where those actions occur (situational context [4]). Context is described from the user perspective: user availability preferences and the interaction capabilities of user’s devices (user context) and from the shared perspective: the organization of people, activities and resources (work context). Both contexts allow us to infer the user willingness to be exposed to awareness information given the actual device interaction capabilities, the user preferences and the relevance of actions. In a very abstract level, actions can be seen as simple, generic operations that transform the state of context: add, update, delete (add person, delete person, etc) In this way, actions that occur in the shared environment are described trough those operations and any attempt to change the state of an element of the shared environ J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 314–329, 2003. © Springer-Verlag Berlin Heidelberg 2003

Application Design Based on Work Ontology and an Agent Based Awareness Server

315

ment (e.g. delete an activity) causes a relevance and consequences estimation based on the work context and are informed to the users based on each user context. Due to the distributed and personalized nature of our awareness proposal we choose to implement the awareness mechanism as a Multi-Agent System (MAS). An agent is a software process that controls its own actions (autonomy), perceives its environment (react) and can take the initiative to perform an action (proactively) in order to accomplish tasks on behalf of its user [5]. A MAS system can be seen as a collection of possibly heterogeneous agents. The proposed awareness server (AwServer) is a MAS that conforms to the standards defined by FIPA (Foundation for Intelligent Physical Agents) [6]. Every user has associated a pair of agents, one of them estimates the relevance of events perceived in the shared environment (based on the work context) and the other schedules the awareness delivery (based on the user context). Both tasks are implemented as rule-based inference processes. We have built AwServer as an independent functionality layer, where a java component allows the shared environment to propagate actions to the AwServer (e.g. e.g. update user location, update designer team, add activity A, etc.), to listen for notifications from the server (e.g. john logs in the application, john has been removed from the designers team, john’s activity A finished and reach its goals, etc.) and to perform specific queries to the agents (e.g. where is the user?) (fig1). We have built a prototype system that uses AwServer to create a collaborative scheduler (CScheduler). The scheduler has three interfaces: a web application, an email-based application, and an SMS application. In this paper we present a case study that allow us to have an insight of the impact of the approach in the construction and design of collaborative software as well as the users interaction trough the system, users satisfaction, application usability, support for the task at hand (to negotiate meetings) and interface features (AwServer awareness information delivery). We found that the use of AwServer can help designers to obtain an abstract definition of the activities that describe the task at hand (a task context). This abstraction makes possible to easily build different interfaces for the same application: a servlet based web pages, a java application, an email notification system or a SMS notification system. All of them only implement interfaces, but the “plumbing” that implements the task context is made once. The result suggests that application usability is not significantly impacted with the use of different channels of communication; the user seems to perceive and evaluated them all as separated channels. Additionally we realized that it is possible to take advantage of agent technology to foster collaboration trough a previous agent collaboration that reduces users work burden. We plan to implement a full version that tests these features. Section 2 presents the principal characteristics of the architecture that must be taken into consideration when building applications based on AwServer, complementary information can be obtained in [7]. Section 3 describes the process of creating an application based on AwServer. Section 4 presents our findings when building such application. Section 5 describes a case study we conducted using the application and finally, section 6 presents our conclusions.

316

R. Alarcón and D.A. Fuller

2 MAS Server Architecture AwServer manages the delivery of awareness information among a shared application and a group of users, trough a set of devices previously defined for each one. The AwServer is a multi-agent system that conform FIPA specification and comprehends three kinds of agents: a Proxy Agent (PA) a Work Context Agent (WCA) and a User Context Agent (UCA). A pair of WCA-UCA agents is associated to each user with the goal of manage his or her awareness information (fig 1), from the user perspective; they behave as a unity, an agency that provides a service.

Fig. 1. AwServer architecture. WCA agent infers the relevance of events occurred within a shared application (the oval in the middle of the figure) based on the work context. UCA agent infers the user availability to perceive this information. PA agent propagates the events occurred in the shared applications to the WCA-UCA pairs trough an interface called AgentListener denoted by the shadow boxes in the border of the oval

Each action performed within a shared application is propagated to the proxy agent (PA), which in turn broadcasts a message to every pair WCA-UCA informing the event. A unique PA can manage all the messages or there can be a PA for each user because this kind of agent does not perform reasoning tasks and behaves more like a dumb robot. It is possible also to have a PA agent in a small portable device like a palm. Both agents, WCA and UCA, behave cooperatively to interpret the message received from PA and to determine when and where (through which device) the user they represent will receive a notification informing about the event. Agents’ knowledge implementation (knowledge base and reasoning engine) has been designed separately from agents behavior, this approach allow us to refine or change the inference strategy without making any change to the agents’ code. The next sections present the agents’ knowledge and behavior respectively.

Application Design Based on Work Ontology and an Agent Based Awareness Server

2.1

317

Agents’ Knowledge

In AwServer agents were designed as autonomous entities that communicate among them through messages in order to accomplish a specific task. Messages are written in ACL, which is a FIPA standard for agent communication. Based on the semantic of the messages agents execute different behaviors (fig 3) (e.g. one agent can reply a query that asks for user location). Nevertheless, based on its knowledge an agent can infer that a behavior must be performed. So, WCA infers user actions’ relevance based on its knowledge of work context which is represented as work ontology. An ontology is an explicit formal specification of the terms in a particular domain and the relationships among them [8]. User actions can be generic (add, update, delete an ontology element) or specific (register local vocabulary, inform that an activity has been added, etc.) (fig 2.a)

Fig. 2. Agent’s knowledge represented through ontologies. Both ontologies comprise a set of concepts, operations to be performed over those concepts and agents actions. WCA knowledge is represented through a work context ontology (a), UCA knowledge is represented trough a user context ontology (b).

When WCA determines the relevance of an event, it asks UCA to inform the user about the event. Similarly, based on knowledge collected from the user, UCA infers the time and logic device (email, cellular phone, the shared application interface, etc.) where to deliver a notification informing the event occurrence. Work context ontology considers concepts related to people, activities and group resources as well as the relationships among them. Notice that work activities have associated an “ExecutionBody” representing the ongoing execution of an activity. Similarly user context ontology comprehends concepts that describe the situation of a user when he or she interacts with a shared application. This situation is described in terms of the interaction capabilities that the devices through which users contact shared environments offer. Devices are considered as electronic or virtual places (e_Place) where users reside and can be contacted (a cellular phone, an email account, a shared application, etc.)

318

2.2

R. Alarcón and D.A. Fuller

Agents’ Behavior

Agents interact following social conventions; their communication is based on messages. Messages content can be predicates, concepts or actions to be performed over elements of the work context ontology for WCA agents and user context ontology for UCA agents (fig 2). When PA requests WCA or UCA to execute a generic operation (add, update, delete) they must acknowledge the request, informing if the operation could be accomplished. If an agent does not understand a message, it informs that event to the requester. An operation execution consists of updating agents knowledge (e.g. add a person, update a team, etc) and asserting the result (success/failure) in its own knowledge base (fig. 3 A, F) Other actions cause agents to execute different behaviors, for example the action “Set User Location” causes UCA agent to change its knowledge about where the user resides currently (that is which e_Place) or which e_Place has abandoned (fig. 3 G). UCA receives a request to perform the Notify action from WCA agents whenever WCA determines that an event occurred in the shared environment must be notified and infers its relevance (fig. 3 E, J). WCA agents can be asked to restore its knowledge from a log file in case of server breakdowns (fig. 3 A) and to remind the assertions or facts of its knowledge bases, which makes possible for end users to inspect agents reasoning (fig. 3 D, I). It is possible also to wait for user acknowledgment, PA implements a Waiting behavior, which is an execution suspension until a responding message arrives.

Fig. 3. Each agent can react to a message performing a specific behavior (A, B, C, F, G, H). WCA and UCA interact with an inference engine also and react to those inference processes by executing a behavior (D, E, I, J). PA implements the sensor (input) and effector (output) functions of the agency

When agents receive the request of register the “Local Vocabulary” and the set of user “e_Places”, they simply registers them as dictionaries extending in this way the concepts and predicates they can understand to include the shared application itself as well as the effective user places where they can be contacted.

Application Design Based on Work Ontology and an Agent Based Awareness Server

319

The consequences of these actions are extremely important as we describe in the next section. But previously we will describe how AwServer treats work activities. 2.3

Work Ontology: Activities

We conceptualized work activities based on the enterprise ontology of [8]. An activity is a concept or a class that has a name, must be executed during a time interval (start time and end time), is part of a project plan (which implies that it must be executed while the project plan is running), must be performed by a doer, has preconditions to fulfill in order to start its execution, causes some effects when executed, has goals to achieve and can be executed (fig. 4). Its execution can require some parameters and has an effectivity criterion that makes possible to measure its efficiency.

Fig. 4. Work context activity definition. An activity is described by a name, a length time (Tbegin, Tend), forms part of a project plan, is executed by a doer, has preconditions to fulfill, effects generated, goals to achieve, an effectivity measure a validity (valid) criteria and an execution body (execute) which can require parameters

Finally an activity has different states, when it is added through an “AddActivity” event (fig. 3 A), its validity is verified, that is, WCA checks if its starting and ending time falls between the running time interval of the project plan where the activity belongs to and if it is a viable time interval (the interval has not already passed or is an empty interval). If it is not valid then the “AddActivity” operation is considered as a failure and the fact is notified to the users, otherwise the activity’s preconditions are tested, again if the preconditions are not met, the AddActivity operation fails. If preconditions are satisfied WCA executes the activity (fig. 3 C) and waits until it reach the activity’s ending time. When this occurs, the agent tests the effects, goals definitions and effectivity criterion; again if goals are not met it is considered a failure. Even though we did not implement a complex activity execution it is possible to execute activities in a sequential, parallel or cyclic fashion. The benefit of having WCA agents executing activities is that activities can be complex enough to request agents to execute behaviors specific to the shared application without the burden of implementing a separate agents’ environment that with agents that understands and communicate among them based on these ontologies. WCA supports the execution of work activities that are defined in the Local Vocabulary by describing those activities in terms of logical preconditions and conse-

320

R. Alarcón and D.A. Fuller

quences (ExecutionActivity behavior). The approach allows us to implement contingent actions in order to facilitate the collaborative process (the activity execution) as the agents can engage in a FIPA Contract Net protocol to facilitate the preconditions and effects achievement. Of course, an activity can have an empty execution body; in this case activities preconditions and goals are also verified at the starting and ending time.

3 Work Ontology Based Application Design As we can see, work context ontology is a very abstract representation of work. It includes persons, teams, organizations, activities, project plans and resources or artifacts. Those concepts and the relationships among them describe work practice in a very high level, so it must be grounded according to the needs of every shared environment. Applications based on work context must define a grounded instance of work context ontology or “Local Vocabulary”. This vocabulary consists of concepts, predicates and work activities definitions and represents an ontology that defines the semantics of the application itself. In order to test our ideas we designed a collaborative scheduler application (CScheduler) (fig. 5) [9]. CScheduler is a groupware application that aims to support the negotiation of a fitting time-interval for appointments of engineering project groups. Users of CScheduler work on projects that have defined some milestones to achieve so they must negotiate work appointments that must be held before the milestone date has reached. The attendants of those meetings can be the whole group, a part of them or can include people that belong to others groups (for example consultants). CScheduler users can also define private meetings (preset meetings) where the attendant is himself or herself and possibly an outsider (for example a dentist). It is also desirable to define alerts that remind teammates (inviters and invitees) the nearness of an appointment. When a teammate receives a meeting invitation, he or she must answer the inviter accepting, refusing or requesting a new date for the appointment. Inviters can cancel an appointment, otherwise appointments remains in a pending (no any answer was received) or an expired state (the time has run out). So the local vocabulary comprises nine principal activities as well as their execution body: fix appointments, answer appointments and modify those answers, set alerts, set milestones, add groups and modify them, add teammates and modify them (two section hexagons of fig. 5, where the upper part correspond to the activity name and the lower part the execution body name). FixAppointment activity precondition is that inviter and invitees must be free (that is without an appointment accepted for any of them), so that it is necessary to declare and implement Free(Person, TimeInterval) predicate in order to allow the agents to determine if the activity can be executed (that is to run the Execution class) (fig. 6a).

Application Design Based on Work Ontology and an Agent Based Awareness Server

321

Fig. 5. Work ontology based CScheduler design. Activities are represented by a divided hexagon where the upper part is the activity name and the lower part the execution body name. Concepts are represented by rounded rectangles and predicates by rectangles. Concepts name appears in the upper part of the rounded rectangle and their slots or attributes are listed below. Predicates names are presented in the upper part of the rectangles and their parameters appears below

If the precondition is met, WCA agent executes the activity and once it has ended (Tend) goals are evaluated, that is, the predicate Busy (Person, TimeInterval) is executed. Finally, the execution of the activity takes as a parameter the appointment, it can be denoted like: FixAppointmentExecution (Appointment). The precondition of AnswerApp activity is quite simpler; it is only necessary to have the appointment not canceled (by the inviter). Similarly, the goal here is to change the status of the appointment from pending (not answered yet) to another one (refused, accepted, etc) (fig. 6b). The ModifyAnswer activity requires that the answer already exist and the consequences of executing this activity are similar to the AnswerApp activity (fig.6d). SetAlert activity’s precondition is to have the appointment not canceled (fig.6c). The objectives of an alert are two: to remind the inviter and invitees of a meeting nearness and to remind invitees that they must answer the invitation, so they accept, refuse or request a new date for the appointment. The first objective has the goal of having the user aware of the nearness of a meeting, which we cannot determine (an alert can be sent to a cellular phone forgot at home) and the second objective is achieved when invitees changes the status of their invitations so this remains as not pending.

322

R. Alarcón and D.A. Fuller

Fig. 6. CScheduler activities definition. CScheduler main activities are to fix an appointment, to answer invitations, to set alerts and to define milestones

An alert becomes its activity 24 hrs before the meeting has been fixed, and is sent every day from starting, the last day is sent 18 and 8 hrs before the meeting takes place. Once the second goal is reached, the alert is sent 2 hrs before the meeting fixed time. SetMilestones activity has the precondition of having the milestone not previously fixed and the goal is simply to fix a milestone (fig.6e). As we can see, Milestones are project plans that form part of a General project plan. The latter plan has a length of weeks or months within all Milestones must be fitted. Milestones have a starting and ending time and activities must be accomplished within this time interval. Additionally, Milestones can be modified and this action impacts in every activity already running. AddGroup and AddTeammate activities has the precondition of not having exist previously the group or teammate respectively, it goal is very simple to have them exist. The time length for accomplish these activities is similar to the AnswerApp activity time interval. ModifyGroup and ModifyTeammate activities are also similar to ModifyAnswer activity, they only require that the group or teammate already exist and the conse-

Application Design Based on Work Ontology and an Agent Based Awareness Server

323

quences of executing these activities are similar to AddGroup and AddTeammate activities. Activities have defined also doers, which are the responsible of performing the activities, the owner of the activities in some way. In the case of FixAppointment activity, this action must be performed by the inviter, which means that he or she will be notified if the activity creation fails (precondition, execution or goals fails). AnswerApp and ModifyAnswer activities are of responsibility of each invitee, SetAlert activity is responsibility of inviter or invitees respectively, and the responsibility of SetMilestones is assigned to the whole group. As we observe those activities requires the definition of seven concepts: appointment, answer, alert, milestone, group, teammate and time interval (rounded rectangles of fig. 5) and seven predicates: Busy (Person, TimeInterval), Free (Person, TimeInterval), NotCanceled (Appointment), NotPending (Appointment), Exist (Answer), Exist (Milestone) and NotExist (Milestone) (rectangles of fig. 5). When invitee WCA agent receives an invitation to make an appointment, it determines if the user is free or has an appointment already made for that date, in the latter case, the agent creates a list of suggestions based on the nearest slot of time available and sends its proposals to the inviter WCA agent. Once the inviter WCA agent has collected all proposals, it determines the closest date that fits all users agendas (where everybody is Free) and sends these suggestions to the user asking he or she to pickup a final date. If the inviter chooses one of them, his or her WCA agent sends an acknowledge message to every invitee agents, which in turn fix the appointment for their users and mark its status as pending. In this way we take advantage of having an activity executed by agents that conforms FIPA standard: they had predefined complex protocols of interaction like FIPA Contract Net Protocol that we can use in order to foster collaboration among users. Activities are currently implemented as classes that contain attributes and get/set methods as well as the code that implements the Execution behavior and is loaded lately for the AwServer, this feature is optional. Of course is possible to automate the activities definition even to implement a graphical interface that will help collaborative application designers to devise the task context easily. User context must also be grounded for use; it is necessary to create instances of specific e_Places for each user as well as to define their availability preferences. We present those e_Places in the next section.

4 Building an Application In order to test our ideas we built a reduced version of CScheduler that implements the core functionality; we also conducted a case study that is described in section 5. AwServer was built over JADE, a java-based agent development environment, so that the local vocabulary was also designed in java according to the jade content language and ontology support features defined in JADE. Agents in JADE run in a container called JVM (java virtual machine) and the shared environment or CScheduler can run in another JVM (a java application, an applet or a servlet) or can be a completely different application (such as a php web site).

324

R. Alarcón and D.A. Fuller

PA agent listens events in a java socket; shared applications send those events through a java-based component called Agency Listener (shadow boxes in fig. 1). The component implement a java socket that writes in PA’s socket and can receive messages from PA as well. Messages have ACL format and can be easily converted into java classes for facilitating their manipulation. For simplicity we built the application using servlet technology. Servlets are java application that run in the side of a web server and are able to generate dynamic web pages. It is possible to modify the component to include a second socket were a nonjava application can write and listen to or write an ad-hoc component as its functionality is simple. We used Apache 1.3.22 for the web server and Tomcat 4.1 which implements a JVM where servlets run and can be reached trough http protocol, we also used Mysql 3.23.38 for the database. As seen in fig. 3, WCA agents perform an Execute behavior that requires testing preconditions, executing the activity and evaluating activity goals. Agents’ behaviors are java threads and we exploited this characteristic to implement work activity management trough threads. That is, WCA agents evaluate preconditions if they are fulfilled a thread that executes the code defined by a descendant of the class ExecutionBody is created (the class is loaded and executed); additionally the agent waits until activity ending time to evaluate goals (the Execute thread is suspended and waits for the remaining time). Preconditions and Goals are implemented as monomials formulas (a^b^c…^n) from predicates that can be evaluated individually for values of true or false, for example: Free (inviter) and Free (invitee1) and …… Free (inviteeN)

(1)

The definition of a predicate requires also the construction of a method that allows agents to determine its value. Fig 7 shows the screenshot of CScheduler Status and Management functionality; we can see three sections or inboxes for messages of group members. The left table shows appointments already made (they are confirmed or are private meetings). The upper right table shows appointments requested for the user (in this case Gloria) to other members (in this case Francisco) the date and time of the appointment and the status of the meeting (red which means refused). The lower right table shows the invitations to meetings that user has received, 6 in this case, the inviter (David and Lucy) the subject of the meeting, its date and its status. Fig 8 shows a screenshot of Schedule function, we can see a calendar and a detail of the week currently selected, both of them are synchronized. The detail allows them to add a personal meeting and shows all the appointments the user has made and the invitations he or she has received as well as their status. Users e_Places were also built as java classes that defines e_Places and e Addresses for each user. Users that own cellular phones had an SMS e_Place where a method (delivery_method) that sends a message from web was implemented.

Application Design Based on Work Ontology and an Agent Based Awareness Server

325

Fig. 7. CScheduler screenshot: Status and management function.

Fig. 8. CScheduler screenshot: Schedule function.

We take a similar approach for email accounts and java based applications. As users used mainly a web page, which is based on pull technology, we did not implement a delivery _method for this place and additionally agents did not choose this place for communications in any case for the same reason.

5 Case Study In order to test our ideas we conducted an experimental study where the subjects were organized in groups to test the CScheduler version described in section 4. We designed the evaluation experience based on the classifications defined in [10] and [11].

326

R. Alarcón and D.A. Fuller

The objective of the experience was to have an insight of users interaction trough the system, users satisfaction, support for the task at hand (to negotiate meetings) and interface features (AwServer awareness information delivery). This is an evaluation prototype; the evaluation setting was naturalistic with minimal manipulation, we participate only to solve configuration or usage problems (some subjects asked how to perform functionality at the beginning of the experience). Participants should negotiate an amount of 8 meetings. Their communication was mainly asynchronous although they also engaged in a sort of synchronized communication protocol when each participant was able to make a meeting (they were aware that this protocol was currently taking place). This was a formative experience with the purpose of gaining insight in the construction of shared applications based on work ontology and AwServer and to learn from the impact of this technology in end users. We collected both quantitative and qualitative data and compare them in order to determine if what users declared (perceptions) were close with what effectively had happened. For quantitative data we took the Scheduler database and the logs written by agents. These logs include the messages agents send each other, the inferences they had, the actions they actually executed and a status trace log. For qualitative data we take usability tests as well as a perception test were we obtain information regarding users sense of group belonging, events occurred during the experience, sense of task progression and sense of users involvement. Subjects. Subjects were 14 undergraduate and graduate students of the same course at the Pontificia Universidad Católica de Chile. Students know each other but were not necessarily friends; most of them were Chilean but there were also foreigners. They were very familiar with email, SMS and web technologies and have different personal agendas to attend (they take different courses). Communicational Resources. Regarding participants communicational resources, 11 own a cellular phone; all of them have web and email access from campus laboratories and the majority from their home computers (13). 3 of them have a desktop computer assigned at the campus with a fixed IP number. From those who own a cellular phone, 8 have not enabled the SMS services, email or messages from the web. Those with a home computer have IP numbers randomly assigned; some of them have DNS service (3) while others did not. Procedure. Students were organized in three groups of 4 and 5 peer members, each member was chosen randomly. Two groups were assigned to use AwServer based CScheduler version (Group1 and Group2) and the third group use a web based version without AwServer (Group3). Groups were asked to negotiate 8 meetings during three weeks, at the end of which they were asked to take a questionnaire. There were no deadlines defined to reach consensual meetings (we did not define milestones).

Application Design Based on Work Ontology and an Agent Based Awareness Server

327

Results. Subjects using CScheduler qualified the web-based application as easy to use and understandable in general. We made direct and indirect questions about scheduler characteristics and all of them but one responded accurately (What kind of answers your invitees gave to you? What kind of states can have a message?). Users declared to be satisfied with the functionality of the scheduler although they required more control. We asked users to qualify the easiness of use of all functionality of the system and both kind of groups those who use the AwServer version and the simple web version without AwServer qualified the system functionality in a similar fashion (fig. 9a). Users tend to fixed meetings were a part of the group was invited not the whole because they has some task to perform that does not involve the group, they missed to notice that this was a general experiment and use the scheduler to negotiate appointments that they actually need (or make sense for them). Although they were informed that email system was used to deliver notifications some of them in fact answer these notifications. Nevertheless, some members of groups behave in a very passive fashion expecting appointment invitation in order to answer but without requesting them a meeting. We asked users to express how much active did they believe was their groups and themselves in the experience in a direct manner (asking him or her to rate themselves) and indirectly (asking him or her to report the number of meetings they requested, the number of meetings they responded as well as their status). In general users perceived themselves as having a poor activity (fig 9.b) while they were really more active and close to the goal (arrange 8 meetings) than they reported. In the case of groups that used the version that include AwServer, they received a bulk of almost 22 emails that informed about the actions that occurred in the shared environment: a precondition has met or failed, an activity has met or failed, a goal has accomplished or failed. Most users found this overwhelming and confusing because of the format of messages, they were too formal and without interpretation: We reported a “goal failure” instead of advising that “appointment x fixed for the date y having z, q, p attendants, was not confirmed by any”. On the other hand the control group reported a lack of acknowledge, they visited almost daily the site in order to find out what has happened. In this group only one member requested appointments from the others, the others remained always passive. Additionally they reported to be satisfied with the application and suggested minor changes that make the site more usable (arranging the menu disposition, the possibility of a more detailed description of the meeting purpose or the causes for rejection) while the other focused more in functional details (modify appointments, adding cyclic personal appointments, manipulate their directories in order to include other members, reduce the number of messages, presented in a better format, etc.) In the case of users that received acknowledge by cellular phone they reacted visiting the web site or trying to figure out what is the meaning of the message because they felt that something was wrong. In all three groups the sense of group was established in relation to those users who were more proactive and to users that already engaged in the task (by answering appointments requests). In relation to the number of meetings requested and invitations answered for each one, Groups 1 and 2 reported activity closer to the reality than Group3.

328

R. Alarcón and D.A. Fuller

(a)

(b)

Fig. 9. CScheduler screenshot: Schedule function

6 Conclusions and Further Research The information obtained from end users was important for us because it shows us that the use of different channels of communication is not necessarily a source of distraction or cognitive overload. The amount of information obscured, not interpreted can certainly overload users and can be a source of frustration. On the other hand, acknowledge from teammates can help users to notice the group activity only if this information arrives trough a channel close to the user (a cellular phone, an email alert, the application interface). When this information is sent to passive mediums like email, users expect it to be meaningful; otherwise they neglected them more as time passes. Nevertheless there are some notifications not important enough even to be notified about, and must be presented only when users explicitly request to examine the status of the application, then they are important as activity indicators. Finally, usability characteristics are related to each user interface users seams to perceive and evaluated them all separately. The experience was very instructive for us, because we realized that having a unique definition of activities that describe the task at hand, that is the local vocabulary, we were able to design easily different interfaces for the application: a servlet based generated web pages, a java application that fully implements the scheduler, a java application that only alerts of the arrival of a message, an email notification system and a SMS notification system. All of them implements only interfaces but the “plumbing” is made once. In the case of complex applications that uses push technology (a java based application for example) it is also possible to design the application in a reactive fashion, that is because we can determine unambiguously the semantics of a particular message, we can embed components in the application that react only to the messages they are interested for example, reloading the screen to present a new invitation if the user is currently watching the appointments status screen, updating the names of users that are already logged in the system, expiring appointments whose goals has failed, etc. Again the plumbing required is far less demanding. We plan to implement Cscheduler´s full functionality and to conduct again this experience in order to contrast our findings. A third evaluation will be realized with a version that includes the learning of user preferences.

Application Design Based on Work Ontology and an Agent Based Awareness Server

329

References 1.

Dourish, P., Belloti, V.: Awareness and coordination in shared workspaces. In Proceedings of CSCW '92 (1992) 107–114 2. Sohlenkamp, M.: Supporting Group Awareness in Multi-User Environments through Perceptualization. GMD Research Series; No. 6. (1999) 3. Fussell, S., Kraut, R., Lerch, F., Scherlis, W., McNally, N., Cadiz, J.: Coordination, overload and team performance: Effects of team communication strategies. In Proceedings of CSCW'98, (1998) 275–284 4. Schmidt, A., Implicit Human Computer Interaction Through Context Personal Technologies Volume 4 (2&3), June 2000. pp. 191–199 5. Maes, P.: Agents that reduce work and information overload. Communications of the ACM, 37 (7) (1994) 31–40 6. Burg, B.: Foundation for Intelligent Physical Agents. Official FIPA presentation, Lausanne, February 2002. See http://www.fipa.org for further details 7. Alarcón, R., Fuller, D.: Intelligent Awareness in Support of Collaborative Virtual Work Groups. Lecture Notes in Computer Science (Joerg M. Haake, Jose A. Pino, eds.), Vol. 2440, pp. 168–188, Springer-Verlag 2002 8. Gruber, T.R.: A translation approach to portable ontology specification. Knowledge Acquisition. Vol. 5 (1993) 199–220 9. Malone, T., Grant, K., Turbak, F., Brobst, S., Cohen, M.: Intelligent information-sharing systems. Communications of the ACM, 30 (5), 1987, 390–402 10. Pinelle, D., and Gutwin, C.: A Review of Groupware Evaluations. Proceedings of Ninth IEEE WETICE 2000 Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, Gaithersburg, Maryland, June 14–16 11. McGrath, J.E. Methodology Matters: Doing Research in the Behavioral and Social Sciences. In Readings in Human-Computer Interaction: Toward the Year 2000, 2nd Ed. Baecker, R.M., Grudin, J., Buxton, W.A.S., Greenberg, S.(eds.), Morgan Kaufman Publishers, San Francisco. 1995, 152–169

Supporting Context-Aware Collaboration in a Hospital: An Ethnographic Informed Design 1

2

1,3

Miguel A. Muñoz , Victor M. Gonzalez , Marcela Rodríguez , and Jesus Favela 1

1

Departamento de Ciencias de la Computación, CICESE, Ensenada, México {mimunoz,marcerod,favela}@cicese.mx 2 Universtity of California, Irvine, CA, USA [email protected] 3 Facultad de Ingeniería, UABC, Mexicali, México

Abstract. This paper reports the development of a context-aware messaging system to support the intensive and distributed nature which characterizes information management and collaboration in a hospital setting. Our design was based on a set of findings gathered during a workplace study conducted in a hospital. We identified that collaboration in the hospital is highly based on a set of contextual elements: (1) the location of people and devices, (2) the timing of messages to be delivered, (3) the role-oriented nature of the work and (4) the artifact-mediate nature of information gathering. Those elements were validated and their support analyzed with hospital's staff through a session where scenarios of use where created, refined, and evaluated. The results of this study allowed us to inform the design process of a context-aware architecture to support collaboration in a hospital setting. The architecture allows for the implementation of applications that respond in accordance to the context surrounding the activities performed at the hospital, thus enhancing information exchange, collaboration, and ultimately, decision making. In particular, we focus our attention on a context-aware messaging system developed on top of this architecture, and which allows health care workers to exchange messages that depend, for their delivery, on the status of people, resources and/or devices.

1 Introduction Information management and communication in a hospital setting is characterized by a high degree of collaborative work, mobility, and the integration of data from many devices or artifacts [10]. Exchanges of information are intense, and demands from participants to promptly extract from the artifact useful pieces of data to perform their job. In contrast with other settings such a control rooms [13], information in hospitals is not generally concentrated in a single place but distributed among a collection of artifacts in different locations. For instance, patients’ records are maintained and used in coordination with data on whiteboards, computers, or binders located in rooms, labs, common areas or offices. Following Bossen we might say that for practical purposes the whole hospital becomes the information space [3] and it is by "navigating" this space that hospital's staff can get the data to perform effectively. Given the high distribution of information together with the intensive nature of the work, it results clear that tremendous coordination efforts are required from all memJ. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 330–344, 2003. © Springer-Verlag Berlin Heidelberg 2003

Supporting Context-Aware Collaboration in a Hospital

331

bers of the hospital staff to properly manage the information to attend and take care of patients. The right information has to be in the right place, whenever it is needed by whoever needs it, in whatever format (representation) that they need it [11]. Hence the characteristics of artifacts containing information play a fundamental role to achieve this coordination. For instance, patient’s records are easily moved from place to place and filled, checked, read and consulted in many locations like nurses' room, analysis labs, or the actual bed where the patient is being attended; nurses, physicians and other workers interact with those records and use them to support their work or to transmit instructions to be followed by others. To have the patient's records at the right place is what in part makes them successful to support coordination, as well as the fact that the information contained in them is clear, complete, accurate, and updated. Unfortunately those conditions are not always achieved. Documents get lost, instructions are not clear, or the data is not complete to support decisions. We therefore need to understand how each information item gets integrated successfully into artifacts to support the coordination required in hospitals. From this understanding we can derive adequate information technology. We believe that to provide adequate support for managing information in hospital settings we need technological designs that are based on a proper assimilation of the context where the hospital's staff performs their job. We can assimilate the context of work done at a hospital by an active engagement of researchers in daily work through which we can capture the routines, procedures, and working practices of individuals. Consequently our approach is based on workplace studies to achieve those understandings. Drawing from the understanding of how work gets done at hospitals we shaped our technological designs to directly address those contextual elements which characterize the management of information in hospital settings: (1) the location of people and devices, (2) the timing of messages to be delivered, (3) the role-oriented nature of the work and (4) the artifact-mediated nature of information gathering. In this paper we present a context-aware architecture to support the management of information at hospital settings. The architecture allows for the implementation of applications that respond in accordance to the context surrounding the activities performed at the hospital, thus enhancing information exchange, collaboration, and ultimately, decision making. In particular, we focus our attention on a contextaware messaging system developed on top of this architecture, and which allows hospital's staff to exchange messages that depend, for their delivery, on the status of people, resources and/or devices. The rest of this paper is organized in the following way. Section 2 briefly reviews how information management in a hospital setting has been understood and what has been done to support it. Section 3 describes a workplace study performed to understand the contextual elements supporting the management of information at a hospital. Section 4 presents the findings that resulted from this study. Section 5 presents two scenarios derived from the study that guided the design of the contextaware messaging system. In Section 6 we describe the concept of context-aware communication, present the architecture and design of the context-aware messaging system, and illustrate its functionality. Finally, Section 7 presents our conclusions and future work.

332

M.A. Muñoz et al.

2 Management of Information in a Hospital Setting Hospital settings have been a subject of study by many researchers in recent years [3,10,11]. Those studies have identified the intensity of the information exchange and its distributed nature. Members of hospital’s staff might be distributed in space (i.e. different location within the settings) or time (i.e. working different shifts). Such conditions are clearly not likely to change and are absolutely essential to provide full time coverage for patients. Consequently given that many people can interact with a patient across the day, all those individuals have to rely on artifacts that serve as containers of relevant patient’s data, as well as a channel of communication with other individuals. In her study of a hospital ward, Bossen identified some characteristic artifacts which resulted to be central for the coordination of staff’s actions [3]. Elements such as whiteboards hanged on walls, helped to communicate information regarding patients’ conditions and locations. Other mobile artifacts such as clipboards with individual patient’s records provided more details of patients such as the medicine and doses that was administered to each of them. Bossen also emphasizes the importance of having the information in the right place: "Another aspect of physical space is that of making the right artifacts available at the right place. Thus, the medicine scheme, which is part of the patient’s records, is frequently needed at the medicine cabinet when medicine is poured into unit doses.... Patient’s records and care-plans are needed in the teamroom whenever the staff needs to check them for information or get an overview of a patient’s present condition. All these artifacts are thus distributed on the ward and have their usual place " [3]. The effectiveness of information artifacts is highly dependent on their location but also on being able to provide adequate information to the reader. It has been pointed out that due to their different professional background, hospital’s personal is likely to experience communication problems or to define and agree on what is the most useful way to represent information contained in artifacts [11]. For instance, physicians and nurses can pull different bits of data from a patient’s record in order to do their work (e.g. a diagnostic vs. the administration of medications). Therefore in order to be effective an information artifact has to be elastic enough to provide with different levels of representations for each possible reader in such a way that it results meaningful for all of them. Limited work has been done to directly address the information management needs of hospitals with context-aware technologies that support contextual variables such as where the artifact is located, who reads it, when it is read and for what purposes it is read. Previous efforts have focused on supporting communication among individuals working in hospitals by using video conference [9] or 2-way pagers [6]. Unfortunately those designs do not contemplate that tasks in hospitals are usually handed among people working different shifts [3] and the fact that even when people are collocated they often rely on information artifacts to transmit data to other members instead of contacting them directly minimizing with this articulation efforts. Other design efforts have intended to support the mobility inherent in many of the information artifacts used in a hospital. For example the Ward-in-Hand system is a handheld system that provides access to patient’s records, hospital information and communication with other patients through a wireless infrastructure [1]. In spite that this solution seems to be pointing to the right direction we believe that it is limited

Supporting Context-Aware Collaboration in a Hospital

333

because it conceives information artifacts as being personal devices, which is clearly not the case. Information artifacts in hospitals are in essence shared by many people and consequently we must focus or design on supporting the roles that individuals play and not the individuals themselves. With the aim of acquiring a robust understanding of what are the essential contextual elements that support the management of information in a hospital setting and how they interact with each other, we conducted a workplace study and a complementary scenario-based evaluation exercise which are described in the following sections.

3 User Study In order to design the context-aware architecture and the messaging system we started our research with the purpose of getting a good and solid understanding of the work practices emerging in the hospital where we worked. Our approach was to use qualitative methodologies to gain understandings beyond requirements gathering and understand how routine and non-routine work is performed in a daily basis. In this section we describe how qualitative methodologies were applied for the particular conditions of our study. 3.1

The Setting

We conducted a workplace study at the General Hospital (H.G.Z. IV. No.8) in the city of Ensenada, Mexico. This is a public health institution providing medical services for a potential population of 175,000 inhabitants. Around 800 persons work in this location. Every year they have an average of 302,000 medical consults, 92,000 urgent services, 3000 births and 600,000 lab studies. With more than 130 beds, the hospital covers the demands of around 82% of the population in the area. For the General Hospital of Ensenada the most strategic service is the area of urgencies from where more that 70% of the patients enter to the hospital. They also cover other medical specialties such as pediatric, gynecology, cardiology, and oncology among other areas. 3.2

Workplace Study

For a period of three months using participant observation and interviews two researchers studied the areas of Hospitalization (Internal Medicine), Urgencies and Lab analysis. Every day an average of two hours were spend following and observing nurses, physicians, lab staff, and social workers while doing their work. We spread our visits across different days and work shifts so we could have a full understanding of how work is done at different times of the day. We were allowed to talk with any member of the staff who was available to talk with us and move around the hospital by ourselves or following a physician or a nurse. In this way we conducted many informal interviews that let us to become familiar with the setting, people and their practices. At the end of each visit or the next day after it, the two researchers shared

334

M.A. Muñoz et al.

notes and discussed observations. In many cases the two researchers were present at the same location, but some times we decided to look at different things or talk with different people. Having two researchers facilitated and enhanced the experience. Once we identified a group of key informants we requested them to be interviewed. Twenty (20) informants were interviewed including physicians, nurses, social workers, assistants, chemist, and lab staff. We covered people with different roles, years of experience and levels of expertise. In total nine (9) persons were interviewed in the area of Internal Medicine; nine (9) people were interviewed in the area of Urgencies, and two (2) people in the Lab area. Of those interviews 17 were audio taped. Three informants were uncomfortable with being tape recorded. Given the nature of their work we had to restrict the time of the interviews to one (1) hour with each informant. Together, observations and interviews were used to construct an understanding of the effects of contextual elements on managing information in the General Hospital of Ensenada. We analyzed the transcripts of the interviews and notes and came out with a grounded representation of the work that let us to synthesize the particular characteristics that context-aware technologies ought to support. 3.3

Evaluation of Scenarios

We decided to use scenarios as a way to frame our understanding of hospital’s work practices and also to project our vision of how their work could be augmented with context-aware tools. We used a scenario-based approach [4] to frame our findings from the study into specific vignettes that offer a new vision of how context aware tools can operate into the current work practices. As other researchers have expressed scenarios are a convenient approach to evaluate novel technologies [7]. Our approach was to conduct a session with personal from the General Hospital of Ensenada where we could generate, evaluate and analyze scenarios. Five (5) people from the Hospital participated in a session which lasted around 2 hours. In the first part of the session we asked the participants to envision how information management could be better supported in their workplace, in specific with respect to the hospitalization areas, and frame this vision into specific scenarios. They worked individually for some time, then in couples and then they discussed their results as a group. From this exercise we refined our understanding of their work by making questions and clarifying issues. In the second part of the session we used two scenarios that emerged from our observations and depicted a vision of how a context-aware messaging system might be incorporated in the workplace. Animated presentations were used to illustrate them. Our informants then provided their feedback with respect to the usefulness of such technologies and their effects in their normal practices. From our scenario evaluation, we learned more details of the practices in the hospital. By envisioning future scenarios we were feed with information that only our informants knew. For instance we realized that regulations regarding paper-based formats and signatures on them are changing and will allow for a higher level of automation in such processes. We also learned that it is only by confronting people with a "picture" depicting their work that they can provide further details that enhance the insights gathered during observations.

Supporting Context-Aware Collaboration in a Hospital

335

4 Findings from the Study We group the findings from our stuffy into four different aspects that let us to understand the fundamental contextual elements that have to be considered to support the management of information and coordination of activities 4.1

Location of People and Devices

We noticed that the location of hospital’s staff is useful to determine the type of information that they might require. Access to patient’s medical records is most relevant when the doctor or nurse is with that particular patient. It is in the context of the patient's bed when detailed information should be revealed to the adequate person. For instance a nurse might notice that a particular medicine has to be administered to a patient and she must know the appropriate doses to apply to the patient. Location then becomes relevant when considering what information to deliver. This information should be sent to the place where it will be useful rather than to a particular person. We conclude that an approach that emphasizes the role of location and integrates it into its design will protect against overloading the hospital’s staff with information which is neither useful nor relevant at that particular location. 4.2

Timing for the Delivery of Information

Communication exchanges in an intensive working environment such as a hospital tend to be time-sensitive. There is a period of time during which a message is relevant to be delivered. For instance, a doctor might wish to leave a message providing recommendations for the treatment of a patient, to any nurse of the next shift. The message might not be relevant if delivered before the next shift since not enough time has passed to evaluate the evolution of the patient’s symptoms, nor will it be relevant the following morning. We conclude that an approach that lets users specify the time where messages are delivered will facilitate the coordination of activities in a hospital where services are provided 24 hours a day, 7 days a week. 4.3

Role-Oriented Nature of Work

Communication needs to be established between parties that might not know each other a-priori or which rarely meet. For instance, we noticed that due to the workshifts and the constant turnover of personal, a single patient might be attended by two different physicians and three different nurses in the same day. In such conditions communication of messages is not addressed to particular individuals but to the nurse in the afternoon shift, the next doctor to visit the patient, etc. There is not certainty about who will be that person, only about the role that he/she will play in the attention of the patient. Therefore information is often sent to roles and not particular individuals. We conclude that an approach that complements communication with specific role-based support will be more appropriate for hospital work.

336

4.4

M.A. Muñoz et al.

Artifact Oriented Nature of Information Gathering

Awareness of the state of an artifact (e.g. patients’ records) facilitates the communication among coworkers and reduces the chances of misunderstandings. For instance, the state of devices (temperature reading) and documents (availability of lab results) can be important triggers for information exchanges. The sudden availability of a bed could trigger the transfer of a patient waiting in the corridor of the emergency room to the next bed to be freed. Medical staff might need to communicate directly with documents and/or devices. For instance, a doctor might wish for the patient’s lab analysis to be shown on the large display of his office as soon as they become available. We conclude that through the monitoring of relevant artifacts we can support the timely delivery of pertinent information to hospital workers.

5 Scenarios of Use for Context-Aware Collaboration In this section we present two of the scenarios that were conceived from the users’ study. They depict the kind of contextual support necessary for hospital's work and how the healthcare practice could be enhanced with the type of support we have envisioned. These scenarios were used to shape the characteristics of both the architecture and the messaging application derived from it and which are presented in the following section. Scenario 1: Rita is a doctor in a local hospital. As she makes her final round, she notices that a patient, Theresa, is not responding well to her medication. Rita wishes to leave a note to the doctor who will be reviewing Theresa in the afternoon shift. She doesn’t know who that will be, so she writes a message to the first doctor to check the patient after her. Scenario 2: While Dr. Diaz is checking the status of a patient (on bed number 1 of room 222), he realizes the needs to request an ordinary laboratory study for her. Through his PDA, he adds this request to the patient’s clinical record of the Hospital’s Information System. The chemist (responsible for taking the samples for the analysis) visits the internal medicine area every morning. His PDA informs him that inside room 222 there are three patients that require a medical analysis. When the chemist stands in front of the patient, his PDA shows him the samples that have to be taken and the type of analysis to be performed. He labels the samples and at the end of his round he takes them to the lab to perform the analyses. The results are added to the patient’s clinical record. When the doctor is about to finish his shift and while walking through the corridor, his PDA alerts him that the test results of the patient on bed number 1 in room 222 are available. Dr. Diaz goes back to the patient’s room and when he stands near the patient’s bed the results of the analysis are displayed on his PDA. At that point, the doctor revaluates the patient and based upon the results just received, decides to prepare him to be surgically intervened.

Supporting Context-Aware Collaboration in a Hospital

337

6 Supporting Context-Aware Messaging in a Hospital Setting In this section we present the design of a context-aware collaboration system based on the instant messaging paradigm. Thus, we first introduce the concept of context-aware messaging, and present the system designed to support the scenarios described on the previous section. Context-aware computing has been closely associated to ubiquitous computing [5] Context-aware computing refers to an application’s ability to adapt to changing circumstances and respond based on the context of use. Mobile users are constantly changing their context, most notably their location. Additionally, context-awareness often requires the use of sensors and computing devices set in the environment in order to establish the context of use. As noted in the scenarios presented in Section 5 there are circumstances, in a hospital setting, that require the sending of messages to a person or device that might depend on contextual information (location, time, availability, etc.). For instance, the doctor in the first scenario described might wish to send the message to the first doctor to be at a particular location (around a patient’s bed) during the afternoon shift and once the results of his medical analyses have been reported. Another scenario might involve a doctor wishing to send the lab results to the first printer to become available or to be visualized in a public display for consultation with another doctor. Based on these scenarios we decided to use the Instant Messaging (IM) paradigm to support what we refer to as context-aware communication. In particular we look to support context-aware messaging. This concept extends the traditional instant messaging paradigm by allowing users to specify a set of circumstances that need to apply for a message to be delivered; we refer to this as context. For example, the sender can indicate that the message will be delivered to the specified recipient when she enters the emergency room; or for the message to be sent to the last person to leave the laboratory when the air conditioning is on. Some of the key computer-based components of the proposed scenarios can be envisioned as agents that have capabilities to make their own decisions about what activities to do, when to do them, what type of information should be communicated and to whom taking into account the situation’s context. Such capabilities have been identified as features highly related with autonomy [8]. We also observe in these scenarios, that a user could interact seamlessly with a range of different agents that can assist the user in his activities. These autonomous agents enrich context aware computing environments by introducing capabilities for negotiating services with other agents and wrapping complex system functionality. For instance, autonomous agents can monitor the medical information system in order to notify to a doctor when the results of a medical analyses are available; find out what is the nearest public display where a doctor may discuss the analyses results with a medical specialist; control and allow access to the hospital’s devices/services taking into account priorities or security restrictions; estimating users’ localization; and monitoring the environment to control the sending of contextual messages.

338

6.1

M.A. Muñoz et al.

System’s Architecture

The architecture and functionality of the context-aware messaging system is illustrated in Figure 1. The system includes the following components:

Fig. 1. Architecture of the Context-Aware Messaging System

A Terminal or Desktop Computer That Acts as an Access Point This computer is used to access both networked information and the handheld device. Wireless connectivity to the access point is increasingly a viable option with the proliferation of devices that support the Bluetooth and IEEE 802.11b standards. The access point runs an HTTP server to handle XML/HTML communication with the handheld. In addition, it stores the Agent Directory to which agents representing services and users will register. Instant Messaging Server We used the Jabber open source instant messaging (IM) sever (http://www.jabber.org). This server is used to notify the state of people and agents, and to handle the interaction between people, agents, and devices through XML messages. All communication between the Context-aware Client and the Context-aware

Supporting Context-Aware Collaboration in a Hospital

339

Agent will go through this server. The information in the user’s handheld is synchronized with the server every time the device is connected to a point of access. Context-Aware Client The context-aware messaging system uses a client-server architecture as a basis for its implementation. In traditional IM systems messages are sent as quickly as possible. In these cases, of course, the identity of the recipient is known a-priori. This won’t work for context-aware messaging where the recipient’s identity won’t be known until a specific state is achieved. One of the components of the Context-aware Client is a lightweight interface for users to compose the message and to easily specify the context of delivery, which is record by the Context component, also responsible for requesting the user’s location to the Location-estimation Agent. Given that the messages are not necessarily sent immediately after they are composed, the system should allow users to go back, consult the messages they have sent, and modify or delete them. From the perspective of the user that receives a context-aware message, it might be important to be aware of the context specified for message delivery, since this information could be useful for him to make sense of the message. For instance a message that states “medicate this patient when his analyses are completed” might not be fully understood if the user is not aware that the message was meant for delivery at a specific location, the patient in certain room in this case. Agents The context-aware messaging system consists of several agents that were developed with SALSA, a class framework for implementing autonomous agents that act on behalf of users, represent devices or wrap a system’s functionality [12]. SALSA agents might run in a user’s PDA, an access point or any other computer with connectivity to the access point. They can be launched explicitly by the user or automatically when certain conditions are met. A SALSA agent contains several components: a protocol to register it with an Agent Directory; an interface through which the agent acquires knowledge or information; a Jabber client through which users, user’s agents, and device’s agents interact by sending XML messages; and finally, the subsystem that implements the agent’s intelligence that includes components for perception, reasoning, and action. The perception module gathers knowledge from the environment’s sensors or directly from the users, other agents, or devices through the IM server. The reasoning subsystem governs the agent’s actions, including deciding what to perceive next. The context-aware messaging system includes the following Agents: - Context-aware Agent that supports the delivery of messages that are dependent on context. This is an entity to which all context-aware messages will be sent. The Context-aware Agent will monitor the environment to determine whether conditions are met for the delivery of the messages it retains. Its perception module registers the contextual information by monitoring the environment through the context interface. The context interface consists of a component to configure the environment (devices available, groups of users, map of the site, etc.) and mechanisms to detect changes in contextual information, such as, devices’ state, users’ position, etc. The reasoning component analyses the contextual information to determine if the conditions specified by messages it stores are met. If this is the case, the action module triggers the event specified by the user, which can consist of sending a

340

M.A. Muñoz et al.

message to any user with a specific role, or sending a message to a device in order to use its service or change its state. Thus, the Context aware Agent is a first class entity registered in the instant messaging server and with an IM roster that includes all people and devices of whose state it needs to be aware in order to deliver the messages it receives. - In the user’s PDA resides a Location-estimation Agent, which obtains the user’s position by triangulation of at least three 802.11b access points [2]. Its reasoning component wraps a back propagation neural network, previously trained to map the signal strength obtained through the agent perception module from each access point to the user’s location. Thus, the Context-aware Client updates its user’s position information by communicating with the Localization-estimation Agent. - The Hospital IS Agent provides access to, and monitors the state of, the Hospital’s Information System (IS). For instance, considering the second scenario of Section 4, when the agent detects that he IS has been updated with the results of the user’s laboratory analysis, the Hospital IS Agent notifies the doctor. It is also used to provide patient’s information to the medical staff, based on their role and location. - Agents as proxies of devices. Devices are appliances that offer services and are connected to the local network. Devices define possible states, the services they offer, and the protocol used to interact with them. Communication with a device is made through its agent, which runs as a daemon on a computing device with connectivity to an agent directory and a Jabber server. Agents provide a standard mechanism to initialize and register the agent with one or more agent directories, which contain information of all services offered in the environment. 6.2

A Sample Application

We illustrate the use of the context-aware messaging system revisiting the first scenario presented in Section 5. As Rita, the physician in turn checks her last patient, she decides to send a message to the doctor who will be reviewing the patient in the afternoon shift. She turns to her PDA showing the Context-aware client, which lists the staff and devices available in the hospital, to send a message to the first doctor to check the patient during the next shift. As illustrated in Figure 2a, this client is able not only to notify the status of other users (e.g. Online, Busy, Disconnected, Away, etc.), but also to show resources available in the vicinity (such as printers, air conditioning systems, etc.) and their status as well as the services they can provide to the user. In addition to the information provided by an instant messaging system, the Context-aware Client also shows the location of users and devices if known. This information is shown parenthesis after the user’s name as shown in Figure 2a. In contrast with traditional instant messages, when a context-aware message is created the sender needs to specify the circumstances that need to be met for the message to be delivered. Figure 2b shows the interface used by Rita to write the message and specify the context for its delivery. Rita writes the message and specifies that it should be sent to any doctor to be in Room 226, after 2pm, today. Through the interface shown in Figure 2b users can specify the following information to provide adequate context for the delivery of the message:

Supporting Context-Aware Collaboration in a Hospital

a)

b)

341

c)

Fig. 2. The User Interface of the System’s Context-Aware Client

Recipient. The user can send a message to a specific user; to all users that meet the additional criteria; or only to the first user that satisfies the criteria. In our current prototype the sender specifies the recipient’s identity by role (such as, a doctor, nurse, etc.) in the case of the scenario; Rita sends a message to any doctor in the next shift. Location. The sender specifies an area where the user needs to be located for the message to be delivered. For this purpose a sensitive hospital map is displayed for the user (Figure 2.c), where she selects the designated area, for instance, Rita selects the room where she is currently located, patient’s room 226. Time and Date. The sender can specify a lower and upper bound of time and date for message delivery. He could specify either one or both. The message won’t be sent before the minimum date indicated and will expire without delivery after the maximum time. As Doctor Rita wishes to send the message to the doctor in the next shift, she specifies the period of time of delivery to be after 2pm. State of a Device. This is another context variable that a user can specify. Devices define the set of all possible states in which they can be at a given time. This list of states for all registered devices is presented to the user if he wants to specify that the device needs to be at a given state as a constraint for message delivery. For instance, send the message if the lights are on; the printer is jammed; the camera has detected movement; etc. We have already integrated only two devices in the system, a laser printer, and remote-controlled video camera. Now that Rita has sent the message we describe how the components of the system’s architecture interact for its delivery. Figure 3 presents a sequence diagram illustrating this process.

342

M.A. Muñoz et al.

Fig. 3. Sequence Diagram of the Context-Aware Messaging System

Doctor Gómez, the physician in that afternoon’s shift, begins his daily routine by visiting each one of his patients. While he moves around the patient’s rooms, the Context-aware Client in his PDA communicates with the Location-estimation Agent, to constantly update his position. When his location changes the Context-aware Client sends, trough the IM server, the doctor’s presence to all users and agents who have him registered in their rosters When doctor Gómez enters Theresa’s room, the Context-aware Client updates his presence and notifies this to the Context-aware Agent. As the message’s delivery conditions match the new context, the Context-aware Agent sends doctor Gómez the message written by Rita. Figure 4 illustrates how the contextual message is displayed in the doctor’s PDA. The recipient of the message can also request the conditions that were defined for the message to be delivered which should provide him with additional context to understand the message received.

7 Conclusions This paper presents and describes a context-aware messaging system which was specifically designed to support the contextual elements defining information management and collaboration at hospital settings. Ethnographic methods (namely participant observation and interviews) and scenario evaluations were used to define and clarify how contextual elements shape artifacts and influence work practices at hospitals. We found that hospital workers are highly mobile, working at different locations and shifts. The intensive information exchange between hospital's workers and their interaction with artifacts is highly dependent on situational information, or context [5],

Supporting Context-Aware Collaboration in a Hospital

343

Fig. 4. Doctor’s Context-Aware Client Displaying a Message

which can change unexpectedly. The above issues were addressed with the design of a context-aware collaborative system based on the instant messaging paradigm, which has proven to be an efficient interface to support collaboration and opportunistic interaction. It provides an adequate balance between awareness, privacy and disturbance. The system we have presented allows mobile users to send contextual messages and access services by taking context into account. We used an agent-based architecture to facilitate the system’s implementation. These components are autonomous agents that wrap complex system functionality, such as calculating the user’s location, or deciding when to deliver a message; and introduce capabilities for negotiating services with other agents. Developers that wish to add a new device to the contextaware messaging system need only to program an interface to the device and define an XML document to specify the interaction with the services it provides. No changes are required to the Context-aware Client application used to interact with the environment. Furthermore, the states defined by these devices can also be used to specify the context required for message delivery. The context-aware messaging system could be easily adapted to support scenarios in other areas, such as, in an educational environment. The system provides configuration options that allow users to initialize and modify the contextual space in order to specify the roles defined for its users (teachers, students, etc), a map of the location (a library, a school department, etc), and the services relevant to the application domain. We believe that further research has to be conducted to understand how contextual elements could be supported in other settings and also to understand the evolving processes defining the relationships between those elements. Our future work will explore those issues. The work presented here is a first effort to understand those aspects within a hospital setting. However this initial work paves the way to define a robust technological architecture to support the contextual characteristics of work practice whenever it is conducted.

344

M.A. Muñoz et al.

Acknowledgments. We would like to thank the medical staff at IMSS General Hospital in Ensenada, Mexico, where the study was conducted, and in particular to Simitrio Rojas and Julia Mora for their support. We also thank Ana I. Martinez for her insights and comments.The work was partially funded by UCMexus-CONACYT under the grant No. CN-02-60, by CONACYT under grant U-40799, and by the graduate scholarships provided by COSNET, UCMexus, and CONACYT to the first three authors.

References 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.

Ancona, M., Dodero, G., Gianuzzi, V., Minuto, F., Guida, M.: Mobile Computing in a Hospital: the WARD-IN-HAND project. Proceedings of the 2000 ACM Symposium on Applied computing (2000) 554–556 Bahl, P. and Padmanabhan V.N.: RADAR: An In-Building RF-Based Location and Tracking System. In Proceedings of IEEE INFOCOM, Vol. 2, (2000) 775–784 Bossen, C. The Parameters of Common Information Spaces: the Heterogenity of Cooperative Work at a Hospital Ward. In Proceedings of ACM Conf. on Computer Supported Cooperative Work, CSCW, (2002) 176–185 Carroll, J. Making Use. MIT press, (2000) Dey, A.K.: Understanding and Using Context. Personal and Ubiquitous Computing, Springer-Verlag, London, UK; Vol. 5, No.1, (2001) 4–7 Eisenstadt, S.A., Wagner, M.M., Hogan, W.R., Pankaskie, M.C., Tsui, F.C., Wilbright, W.: Mobile workers in health care and their information needs: are 2-way pagers the answer? Proceedings of AMIA- American Medical Informatics Association (1998) Ikonen, V., Rentto, K.: Scenario Evaluations for Ubiquitous Computing – Stories Come True? Workshop on User-Centered Evaluation of Ubiquitous Computing Applications, Ubicomp 2002, Göteborg. Sweden (2002) Lesser V.: Cooperative Multiagent Systems: A Personal View of the State of the Art. IEEE Transactions on Knowledge and Data Engineering. Vol. 11, No. 1, (1999) 133–141 Mitchell, S., Spiteri, M.D., Bates, J., Coulouris, G.: Context-Aware Multimedia Computing in the Intelligent Hospital. Proceedings of the 9th ACM SIGOPS European Workshop (2000) 13–18 Reddy, M. and P. Dourish.. "A Finger on the Pulse: Temporal Rhythms and Information Seeking in Medical Work. In Proceedings of ACM Conf. on Computer Supported Cooperative Work, CSCW, (2002) 344–353 Reddy, M., Dourish, P., Pratt, W.: Coordinating Heterogeneous Work: Information and Representation in Medical Care, In Proc. of the European C onference on Computer Supported Cooperative Work, ECSCW, (2001) 239–258 Rodríguez, M., Favela, J.: Autonomous Agents to Support Interoperability and Physical Integration in Pervasive Environments. To appear in Proceedings of the Atlantic Web Intelligence Conference, AWIC 2003, Springer-Verlag (2003) Theureau, J., Filippi, G.: Analysing cooperative work in a urban traffic control room for the design of a coordination support system. In Workplace Studies: Recovering Work Practice and Informing System Design. Edited by Luff, P. et. al. Cambridge Press. (2000) 68–91

MADE – A Groupware Application to Support Real-Time Activities of Distributed and Cooperating Communities 1,2

2

2

2

2

Pekkola Samuli , Arto Rikalainen , Tero Toivonen , Saku Hujala , Niina Kaarilahti , 2 2 Risto Lintinen , and Pasi Pohjola 1

Department of Information Systems, Agder University College Serviceboks 422, 4604 Kristiansand, Norway 2 Department of Computer Science and Information Systems University of Jyväskylä, P.O.Box 35 (Agora) 40014 University of Jyväskylä, Finland {samuli,artturi,tptoivon,sphujala,nkkaaril,rislinti, ppohjola}@cc.jyu.fi

Abstract. Distributed work has increased during the last few years. Employees travelling around in different countries still need access to information and must be reachable by their colleagues. A variety of mobile devices have been utilised for this purpose. However, often, when using multiple devices, the information is available to the appropriate device only. Transferring data between the devices is not always an intuitive or easy thing to do – not while conversing at least. This paper presents a groupware application to support real-time actions of distributed communities. The problem of separate devices is addressed by combining multiple tools, media, into a platform independent aggregate. This allows users to utilise the medium according to their personal preferences or the work situation – regardless of the device they may have. Keywords: groupware, CSCW system, distributed and real-time group work, ad hoc communication, mobile communities

1

Introduction

During the last decade, there has been an increasing need to support organisational activities across distances. With globalisation, organisations have become multinational with offices and customers in numerous countries. Company employees travel between offices and their customers’ sites spending large amounts of their time in airplanes, airports and hotel rooms. Much of the work is done away from their offices [9,12]. Mobile devices are used to obtain different kinds of information and to communicate with other people. Portable computers, ‘laptops’, can be connected to a network and company intranets through wireless connections. Physical location can no longer prevent the access to information. Mobile phones have become very popular for J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 345–355, 2003. © Springer-Verlag Berlin Heidelberg 2003

346

P. Samuli et al.

communication, and lightweight PDAs (Personal Digital Assistants) provide a transferable tool for making notes and administering personal data and calendar. However, although all these devices are good for their own purpose: mobile phones for communication, PDAs for carrying small amounts of data around, and laptops for information processing, these devices are not interconnected. A person talking on a mobile phone does not have an access to information that is needed per se, but, in addition, she has to use a PDA, a laptop or a bunch of papers. From that perspective, the ‘office’ is neither very mobile nor convenient, since a person is forced to divide her attention between multiple devices, or documents, at once. Sherry and Salvador [16] made another significant observation about mobile work. They found that inability to co-ordinate easily with others and inability to engage in ad hoc communication and collaboration had considerable effects on mobile work. Being away from the resources at the office, the lack of connections with colleagues, and the sense of isolation had their impacts on mobile workers life. This isolation is not conducive to the feeling of being a member of a community. Consequently, mobile workers are often ‘pinging’ others. In other words, they keep checking whether everything is ‘ok’ by making brief phone calls or sending short messages. However, this activity requires active participation of all concerned parties, which further presents the problems of intrusions and interruptions. Therefore, passive background awareness, with multiple devices complementing each other, could provide a better starting point for designing systems to maintain the sense of community, as proposed in [2,16]. These findings, together with our previous experiences from developing groupware applications for supporting synchronous and distributed interactions in stationary PCs [11,15], directed the design and development of the MADE1 system that is presented in this paper. The system supports communication and co-operation, or generally, real-time interactions between geographically dispersed individuals. The objective is to support human activities regardless of the devices the users might be carrying, so that the absence of a certain type of device would not hamper the work processes. Also, since the aim is to create a computerised environment for distributed work, the issue of background awareness is taken for granted – whenever the users log in the system, they immediately receive awareness information about the others online thus lessening the feeling of isolation. The paper describes the MADE system, a groupware application that addresses the aforementioned problems with various terminals and devices, and the lack of awareness information. In the following chapter theoretical background is discussed. Then the MADE system architecture is presented. This is followed by a brief illustration of a use scenario, and brief comparison with another applications. Finally the summary and the conclusions are presented.

1

MADE = Meeting others Across Distances in virtual Environments.

MADE – A Groupware Application to Support Real-Time Activities

2

347

Theoretical Background

The development of the MADE system started with several notions from the studies on computer supported cooperative work (CSCW). These are summarised below and then discussed in greater detail. a)

Each medium (e.g. audio, video, text chat, shared whiteboard) has its affordances. A corollary to this is that a full collaborative system, by definition, should include multiple communication and co-operation media. b) Since work practices are constantly changing and unpredictable, any assumptions about the starting point or the medium or about their order of use cannot be made. c) Since awareness of others’ activities is crucial for much of peoples’ work, this awareness, whether backgrounded or foregrounded, needs to be constantly available/present. d) These notions are applicable regardless of the devices used. Studies show that work activities are different, inconstant and continually changing [1,3,13]. For example, in a study of corporate librarians, Ehrlich and Cash [3] observed that the subjects “regularly used printed reference material, CD-ROMs, company annual reports, analysts’ reports (print and on-line), the telephone, and on-line database – sometimes all within a single search” (pp.152–153). They used the tool, or a set of many tools, whichever happened to be the most appropriate for their current task. Workers also switched from medium to another if the other one became more appropriate. Each medium suits best for its own purposes, and helps a skilful person to combine information with information provided by different media. This is in line with the claim by Hollan and Stornetta [6] that each medium has its own affordances; some are better for a particular task at that particular moment, while others are better for other tasks or at other times. The corollary of this is that each unique medium needs to be included in a full groupware application so that the users can move seamlessly between the media – as they do in real-life. There is neither a fixed starting ‘point’ nor corresponding medium simply because it cannot be anticipated (see also [14]). Instead, any medium can serve as one. Another strong lesson of CSCW is the crucial role of awareness of co-workers and their work processes [4,5,7,17]. Having a peripheral and background awareness of others (visually, aurally) is essential for coordinated activities. Despite the findings that work practices involve both background and foreground communication woven into the fabric of ‘individual’ work practices, most applications address only one or the other. Mobile phones are suited for two-person communication and for providing foreground awareness about the other person. When documents are elaborated, a separate device or application is needed. Awareness information, if available, is then represented in that device. The lesson from CSCW to groupware design is that accessing and handling documents (or any shared material) and conversations in them need to be done simultaneously. In other words, they need to be seamlessly integrated so that awareness of others and their activities is constantly available regardless of the devices or media used at any particular moment.

348

P. Samuli et al.

These notions were derived from the CSCW. They are based on ethnographical studies of people performing their work practices. Findings are often independent of any specific technology, reflecting human behaviour. Thus, the principles of multiple media, awareness, and the independence of the starting point are also valid regardless of the technology ranging, for instance, from stationary PCs and portable laptops to PDAs and mobile phones. Our objective was, first, to overcome some of the obvious technical restrictions with mobile devices, and second, to provide a virtual work environment to support synchronous and distributed group work. We had an intention that the users should be aware of other users and their activities at all times, and that they could choose the media they found the most appropriate and move from one medium to another with the device (PC, PDA, mobile phone) they preferred or was available. Also we aimed to offer an environment which would ameliorate the sense of isolation from colleagues by showing the users online constantly, providing means to develop a community history, and supporting both formal and ad hoc interactions within distributed communities.

3

MADE Architecture

The aforementioned principles were concretised in the MADE system. Multiple media (audio, video, text chat, short messages (SMS), shared whiteboard (WB), file transfer and IRC connection2) are integrated into an aggregate so that the users are able to choose the medium or a set of many they prefer. There is no fixed starting media, but after the login, the users enter a ‘room’ (Fig. 1), where they get an overview of the activities within the workspace. The ‘room’ is just a small window, which is assumed to be operated continuously so that the users can get background awareness of other users and their activities. There (see Fig. 1) the users can see other users online (or offline), the media they are using or willing to use, and their availability or status [10] i.e. passive background awareness information is offered as outlined in the Introduction. By clicking the usernames, different media channels3 can be activated. Each medium, opened in its own window, shows awareness information within that particular medium. The rationale and the benefits of separating conversations from background awareness window are discussed later.

2

3

The difference between a text chat and an IRC (internet relay chat) can be explained by their intended use: a text chat is for private conversations while an IRC relies on public servers providing public ‘rooms’ for conversations. Also, text chat provides awareness of other users and their activities within that medium, a feature, which is missing from common IRC services. For each medium, users can launch multiple channels for private sessions. Channels can be joined only by an invitation from a person already in there. There are no limitations on the number or type of channels.

MADE – A Groupware Application to Support Real-Time Activities

Fig. 1. MADE user interfaces for a PC (top) and for Compaq IPAQ (below)

349

350

P. Samuli et al.

The MADE system connects people by showing the users online (i.e. it provides awareness of colleagues) and by offering some media for communication and collaboration. The users are arranged into groups to visualise (sub-)communities. As the system is assumed to be running continuously on the background, it is easy to enter an ad hoc communication. Community history development is supported by recording and retrieval of conversations and documents. Activities and interactions within every medium, except within audio and video communications, can be stored to a central database so that they can be studied and the sessions continued later. This allows users to build up a history of their activities. The MADE system, implemented in Java programming language, consists of several servers and numerous clients. All media (channels) are presented in separate windows, and dedicated servers handle activities for each medium: i.e. an audio server manages audio communication and a WB server shares the whiteboard. This separation allows better scalability: calculations and other loads can be distributed to multiple servers; and ‘unnecessary’ media, in terms of the performance capabilities of a device, can be removed from the clients. Also, although the total amount of network traffic generated by the MADE system is increased because of this distribution of tasks, replication of servers and direct point-to-point connections support scalability for larger populations of users and clients. Figure 2 illustrates the system architecture with some connections between clients and servers.

Fig. 2. The MADE system architecture

MADE – A Groupware Application to Support Real-Time Activities

351

Master Server is the central point for MADE. It connects together clients, media servers and other parts of the MADE system. It provides awareness of other services and servers, information about each client’s status and about users’ profiles and preferences retrieved from its database. PC clients and servers are continuously connected to Master Server, while other types of clients (PDA, mobile phones) send and request information as needed through appropriate servers. The role of Master Server can be thought of as the administrator of the system and all its activities. The system consists of numerous media servers each handling its own tasks, which include, for instance, whiteboard, text chat, and IRC. When a user wants to open a media channel (i.e. to interact with another user), a channel request is sent to the appropriate server. After the server has acknowledged the request, it is passed through the Master Server to the client concerned. If the user accepts the invitation, the user client joins the channel in the server. The server then will manage all the interactions on that particular channel. All media, with few exceptions, follow the same logic. Audio and video do not utilise any server if there are no mobile clients but use direct point-to-point connections instead. Short messages are sent through Master Server to receiver without utilisation of a server and without asking any permission from the user. File Server is designed for storing conversations and drawings, sketches, documents and other working materials elaborated during the work session. When the users are about to finish a conversation (session), before exiting a media channel they are given an option either to save the session locally or to File Server. This enables the session to be retrieved, analysed or continued later. It also supports the development of the history of a community, since not only the participants of the session but also other users can examine the recordings to gain understanding of the situation and the work performed. Since PDA clients utilise different session management schemes and different versions of Java from those of PCs clients and the rest of the MADE system, a PDA proxy is employed. It acts as a dedicated client toward Master Server, although, in fact, it just provides a gateway for PDA clients to connect to the system: the PDA proxy converts and forwards messages between PDAs and Master Server, and between PDAs and PC clients. The PDA proxy supports different network schemes preventing the devices with different capabilities from receiving redundant messages. This minimises the network traffic. WWW/WAP & GSM SMS gateways provide corresponding services to WWW or WAP users, or users with GSM mobile phone connections. For instance, if a user is not logged in to the MADE system, short messages can be redirected, if desired, to her mobile phone through Master Server and the GSM SMS gateway. The user can then reply to them, as usual, and the GSM SMS gateway forwards them to Master Server and to the appropriate user in the MADE system. The Audio server mixes point-to-point audio conversations together, while the Audio gateway provides a connection to a telephone network. People sharing an audio channel can invite others with telephone or mobile phone connections to join. In general, the integration of different media and multiple servers support scalability to a variety of platforms. There are no theoretical restrictions for using any combination of media or even all of the media together for work. However, for practical reasons, this is not possible. Small user interfaces, limited network bandwidth and

352

P. Samuli et al.

performance capabilities of PDAs and mobile phones prohibit the use of every possible combination (c.f. [8]). Because of this, synchronised use of audio and whiteboard is not possible with PDAs but one has to use whiteboard with text chat instead, for example. Also, as the system utilises multiple servers, scalability to a large number of clients is supported. All media servers and gateways can be replicated. The only potential bottleneck is the Master Server, which becomes critical since it handles all messages and requests. The interactions however take place elsewhere, i.e. in media servers. Master Server is utilised only when a media request is sent to the appropriate receiver. Otherwise, Master Server is merely aware of other users and their statuses, not considering where and how the interaction takes place. In this respect, even though the Master Server is critical, it does not, in practice, easily become a bottleneck, as the messages are both small in size, and can be quickly and efficiently handled. There is no central medium in the MADE system. The user interface is merely a small window (see Fig. 1) providing background awareness information. For interactions, some dedicated windows are opened. The utilisation of a small, rudimentary window does not require powerful devices, or interfere with individual users’ casual work practices, and most importantly, does not force them to concentrate their work around some particular medium.

4

A Use Scenario

The following scenario is based on a real life case and interviews (reported in [11]) showing how the system could be used. A person is travelling to a problematic paper machine located in a factory in Asia. Once there, he realises he needs to consult another expert. Previously he would have made a (number of) phone calls or sent (numerous) emails, but since he needs to share drawings and pictures, a call would be just as useless as an email, which might help but would not guarantee immediacy. He enters the MADE system and identifies a person (in Canada) who might know a solution. They collaborate by using audio and whiteboard, but they have to admit that they cannot find the solution. They then try and reach another expert in Europe, who joins the session by text chat on mobile phone, being in the train at the time. Experts in Asia and Canada are thus using audio, whiteboard and text chat, while the expert in Europe uses only text chat. However, together they manage to find a solution to the original problem. Then the text chat and whiteboard conversations are stored to the File Server for bookkeeping and for assisting in problem solving for similar cases in the future. The example illustrates typical nature of work: one can contact others no matter where they are through whatever medium they need, prefer or are able to use, and third persons may join the session with similar degrees of freedom.

MADE – A Groupware Application to Support Real-Time Activities

5

353

Related Systems

Nowadays there are numerous systems supporting real-time communication and collaboration. However, they often fail in supporting one or many of the features identified as essential earlier in this paper. Usually, there is a central medium, which is assumed to be used whether needed or not. For instance with videoconferencing systems, it is video, and with Interwise and WebEx (conferencing and presentation tools) users are forced to use a shared whiteboard. With virtual collaborative environments, it is the 3D environment. Examples are numerous, but it is common that there is a dominant user interface in which all activities take place. On the other hand, in some systems it is also assumed that group work sessions are set up in advance (e.g. in Groove, Microsoft Netmeeting, and Lotus Sametime), hence ad hoc communication is rarely supported. Instant messaging systems (e.g. ICQ, Yahoo! Messenger) address that, but in turn they do not adequately support multiple media. They force users to rely just on one or two media for communication and typically not for co-operation. Microsoft Messenger is an exception as it can be combined with Netmeeting. However, in this case awareness information across different applications is missing as with any case with multiple applications. Generally speaking, in most applications users are only aware of others logged in the system, but not of their activities within a single medium, or across the whole information space. Finally, the variety of devices is always limited to PCs only, not to PDAs or mobile phones. Even though there are few applications, which provide such connection, the functionalities are very limited. For instance, if short messages can be sent and received, whiteboard cannot be used, or vice versa. Full collaborative systems, as we have approached here, simply do not exist yet.

6

Summary, Conclusion, and Future Work

In this paper, we have presented a groupware application for real-time and distributed group work together with its design rationale. We have argued about the importance of multiple media and about users’ autonomy of selecting their tools according both to their own preferences and to the work situation. We believe that anticipating the use a priori and forcing users to use the application as given, does not meet the requirements set by a real work situation (c.f. [14]). This includes not only the users’ freedom to choose the medium, but also the freedom to work wherever they like or wherever they have to work, and whatever device they prefer or are able to use. Moreover, successful accomplishment of much work involves constant awareness, backgrounded and foregrounded, of other users and their activities. These features are implemented in the MADE system. At the client level, the system integrates multiple media into an aggregate. It distributes services across network to multiple servers for better scalability. Passive awareness information and ability to store conversations encourage community development, even though the members of the community are globally distributed. However, with the MADE system, we believe, cooperating communities are no longer dependent on physical locations but can

354

P. Samuli et al.

evolve towards resembling ‘ordinary’ communities with feelings of real membership of such entities. The system described here is fully implemented. We have now released the second version for the participating organisations to be used there as a part of daily work processes. However, at this stage, it is too early to report experiences from its usage. This, nevertheless, will form a dominant part of our future work. As the earlier empirical results from a similar system operating on stationary PCs were very positive (c.f. [11]), we believe the MADE system, providing device independent and more flexible working environment, will offer a user-friendly and adaptable tool to support work of distributed and co-operating communities.

References [1] Bücher, M., Gill, S., Mogensen, P. and Shapiro, D.: Landscapes of Practice: Bricolage as a Method for Situated Design. Computer Supported Cooperative Work: The Journal of Collaborative Computing, 10(1: 2001) 1–28 [2] Dourish, P., and Bly, S.: Portholes: Supporting Awareness in a Distributed Work Group. In: Proceedings of the Conference on Computer Supported Co-operative Work (CSCW’92). ACM Press (1992) 541–547 [3] Ehrlich, K. and Cash, D.: The Invisible World of Intermediaries: A Cautionary Tale. Computer Supported Cooperative Work: The Journal of Collaborative Computing, 8 (1999) 147–167 [4] Harper, R.: Inside the IMF: An Ethnography of Documents, Technology, and Organisational Action. San Diego: Academic Press (1998) [5] Heath, C. and Luff, P.: Convergent activities: Line control and passenger information on the London Underground. In: Y. Engeström and D. Middleton (Eds.), Communication and Cognition at Work. New York, Cambridge University Press (1996) 96–129 [6] Hollan, J. and Stornetta, S.: Beyond being there. In: P. Baversfeld, J. Bennett, and G.Lynch (Eds.) Proceedings of the Conference on Human Factors and Computing Systems (CHI '92). ACM Press (1992) 119–125 [7] Kovalainen, M., Robinson, M. and Auramäki, E.: Diaries at Work. In: Proceedings of the Conference on Computer Supported Cooperative Work (CSCW'98). ACM Press (1998) 49–58 [8] Mayers, B.: Using Handhelds and PCs together. Communications of the ACM, 44 (11: 2001), 34–41 [9] O’Hara, K., Perry, M., Sellen, A. and Brown, B.: Exploring the Relationship between Mobile Phone and Document Activity during Business Travel. In: B. Brown, N. Green and R. Harper (eds.) Wireless World: Social and Interactional Aspects of the Mobile Age. Springer (2002) 180–194 [10] Pekkola, S., Kaarilahti, N., and Pohjola, P.: Observations from the Introduction of an Awareness Tool into a Workplace, and from the Use of Its’ ‘Status’-field. To appear In: Proceedings of International Conference on Human-Computer Interaction. Crete, Greece. Elsevier Sciences (2003) [11] Pekkola, S.: Multiple media in Group Work: Emphasizing Individual Users in Distributed and Real-time CSCW Systems. University of Jyväskylä, Finland, Jyväskylä Studies in Computing 29 (2003) 212p. [12] Perry, M., O’Hara, K., Sellen, A., Brown, B. and Harper, R.: Dealing with Mobility: Understanding Access Anytime, Anywhere. ACM Transactions on Computer-Human Interaction, 8 (4: 2001) 323–347

MADE – A Groupware Application to Support Real-Time Activities

355

[13] Reder, S. and Schwab, R. G.: The temporal structure of cooperative activity. In: Proceedings of the Conference on Computer Supported Cooperative Work (CSCW’90). ACM Press (1990) 303–316 [14] Robinson, M.: Design for unanticipated use .... In: G. de Michelis, C. Simone, and K. Schmidt (Eds.): Proceedings of the Third European Conference on Computer Supported Cooperative Work (ECSCW'93). Kluwer Academic Publishers (1993) 187–202 [15] Robinson, M., Pekkola, S., Korhonen, J., Hujala, S., Toivonen, T., and M.-J. O. Saarinen: Extending the Limits of Collaborative Virtual Environments. In: Churchill, Snowdon and Munro (eds). Collaborative Virtual Environments. Springer-Verlag (2001) 21–42 [16] Sherry, J. and Salvador, T.: Running and Grimacing: The Struggle for Balance in Mobile Work. In: B. Brown, N. Green and R. Harper (eds.) Wireless World: Social and Interactional Aspects of the Mobile Age. Springer (2002) 108–120 [17] Thereau, J. and Filippi, G.: Analysing cooperative work in an urban traffic control room for the design of a coordination support system. In: P. Luff, J. Hindmarsh and C. Heath (Eds.) Workplace Studies: Recovering work practice and informing system design. Cambridge University Press (2000) 68–91

Collaborative Scenarios to Promote Positive Interdependence among Group Members César A. Collazos*, Luis A. Guerrero, José A. Pino, and Sergio F. Ochoa Department of Computer Science Universidad de Chile Blanco Encalada 2120, Santiago, Chile {ccollazo,luguerre,jpino,sochoa}@dcc.uchile.cl

Abstract. Positive interdependence is the heart of collaborative activities that define collaboration and transform group work into teamwork. To achieve positive interdependence among students, just putting them in group and telling them to work together may not be sufficient. Previously, several types of positive interdependencies have been identified for unsupported group activities. These kinds of interdependencies are now instantiated for the case of computersupported group learning. The examples we show in this paper are taken from computer games and other tools we have developed to set students in a scenario in which they must collaborate in order to succeed. This paper also presents diverse forms of structuring positive interdependence in software tools based on the interface design to ensure that students think we instead of me.

1 Introduction The success of one person is bound by with the success of others in collaborative learning activities. This is referred to as positive interdependence. Interdependence is meant to foster cooperation within the groups. Students need to have a reason for working together. Group tasks are collaborative when they structure positive interdependence among group members: a sink or swim together feeling and commitment to the group goal. Such a disposition is vital for successful teams, whether in sports, drama, business, hospital operating rooms or in academic pursuits. Positive interdependence is considered the key attribute of classroom cooperation [8]. It can take many forms. Successful democracies are by definition cooperative since the conflicts are resolved under the assumption that we are all working towards the good of the society as a whole even if we disagree, sometimes strongly, on the means to promote such good. Johnson & Johnson have posted the statistical results of over 575 experimental and 100 correlational studies that were conducted by many researchers over various decades with different age subjects, in several subject areas, and in different settings [12]. These studies clearly demonstrate the positive effect that cooperative learning has on student academic achievement and social development. One of the issues addressed by this research is the type of interaction patterns found in cooperative, competitive, *

On leave from FIET, Universidad del Cauca, Colombia.

J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 356–370, 2003. © Springer-Verlag Berlin Heidelberg 2003

Collaborative Scenarios to Promote Positive Interdependence among Group Members

357

and individualistic situations [12]. Positive interdependence creates promotive interaction. Promotive interaction occurs as individuals encourage and facilitate each other’s efforts to reach the group goals (such as maximizing each member’s learning). Negative interdependence typically results in oppositional interaction. Oppositional interaction occurs as individuals discourage and obstruct each other’s efforts to achieve something. Individuals focus both on increasing their own success and on preventing anyone else from being more successful than they are. No interaction exists when individuals work independently without any communication with each other. Individuals focus only on increasing their own success and consider the efforts of others as irrelevant. Each of these interaction patterns creates different outcomes. Positive interdependence is the heart of collaborative activities that define collaboration and transform group work into teamwork. It is a key feature that has been emphasized by scholars concerned primarily with promoting students’ academic achievement and cognitive development [18,12], as well as research concerned with students’ holistic development. Chickering [7] argues that, in its highest form, the development of autonomy does not simply involve the development of freedom to choose and act independently of outside influences, but it also involves the development of freedom that recognizes one’s dependence and obligations to others. As Johnson et al. [13] mention, the essence of a cooperative group is the development and maintenance of positive interdependence among team members. Being a member of a group is not sufficient to promote higher achievement; there has to exist positive interdependence among all the group members. In a cooperatively learning group, this means learners realize that they are connected to each other in a way where one cannot succeed unless everyone succeeds. Each one is dependent on the contribution of all the others within the group. Group goals and tasks, therefore, must be designed and communicated to students in ways that make them believe they sink or swim together. When positive interdependence is solidly structured, it highlights that (a) each group member's efforts are required for group success and (b) each group member has a unique contribution to make to the joint effort because of his or her resources and/or role and task responsibilities [5, 20]. Doing so creates a commitment to the success of group members as well as one’s own and is the heart of cooperative learning. If there is no positive interdependence, there is no cooperation [13]. In spite of the vast amount of suggestions on how to promote positive interdependence, there are no guidelines on how to structure collaborative scenarios that promote positive interdependence using software tools. The examples of software interfaces we developed are structured in a way intended to promote collaborative activities through several types of positive interdependences. This paper shows some collaborative scenarios we have designed and implemented in various software tools in order to promote this kind of interdependence. We point out the basic principles of positive interdependence, discussed through four simple game examples, where participants have to collaborate to reach a goal. In Section 2, we present some related works. Section 3 presents a set of software tools we have developed to support positive interdependences. Section 4 includes some examples on how to structure positive interdependences. Discussion about our work is done on Section 5, and finally we present some conclusions in Section 6.

358

C.A. Collazos et al.

2 Related Work There are many examples of techniques that promote positive interdependence such as: using only one piece of paper or just one set of materials for the group giving each member a separate job or role, giving all group members the same reward or giving each person only part of the information. Cuseo defines some single-step strategies that may be used to promote positive interdependence among students working in groups [6]. They are: (1) Redirect instructor-directed questions posed by individual students back to the students’ team; (2) have teams seek help from other teams before asking it to the instructor; (3) let the last team receiving help provide it to the next team requesting support, (4) have group members consistently use team responses (e.g., all teammates raise their hands before the instructor responds; teammates provide a choral response to instructor-posed questions; all teammates sign their names on completed group tasks); and (5) let students consistently use team language in the classroom ("we" and "our" vs. "I" "me" or "mine"), among others. Al-Saleh et al. have defined some cooperative learning/teaching strategies, taking into account group interdependence activities [1]: Prior to the initiation of the first class meeting, the room environment is structured to enhance cooperative learning activities. Tables are arranged to seat groups of three to four students. Walking space is provided between tables. The instructor has easy access to all students and is not pinned down to one location at the front of the class. Johnson et al. believe that group grades can be used fairly and appropriately. They say that making goals, resources, roles or rewards interdependent can create positive interdependence, the heart of cooperative learning. Because grades are the most common reward given in a classroom, they “are one of many ways in which students may be given the message, 'We sink or swim together.'” While the Johnsons never state that the use of group grades is essential to cooperative learning, they do offer a number of strategies for making grades interdependent, including: averaging members’ individual scores, dual academic and non-academic rewards, totaling members individual scores, individual score plus group bonus, group score on a single product, all members receive lowest member's score, bonus points based on lowest score, individual score plus group average, average of academic and collaborative performance score, randomly selecting one member's paper or exam to score [11]. Silberman proposes a structure designed to promote positive interdependence among group members called Card Sort [17]. This structure serves a class-building function because students circulate around the room and interact with other students in class. First, each student is given an index card that contains an illustration or example that fits within a general category (e.g., category of living things, food types, or media modalities). Students then move around the room and try to find other students whose cards contain examples relating to the same category as their own. When students think they have found all other classmates carrying cards with examples from the same category, they present themselves to the class as a team. (If the categories are relevant to the contents of the course, then this structure may also double as a learning exercise, in which case the instructor assesses the accuracy of students’ classifications and provides explanations or additional information if needed. Kagan proposes a structure that requires each team member to correctly paraphrase or restate the idea of the teammate who previously spoke before being allowed to

Collaborative Scenarios to Promote Positive Interdependence among Group Members

359

contribute his own idea [15]. This structure explicitly encourages interdependence by encouraging the individual to actively listen to and process the ideas of his teammates. It can also be slightly modified to create a different structure called "Affirmation Passport," whereby team members are expected to affirm something about the comment of the previous student (e.g., its clarity, creativity, or most powerful point) before contributing their own idea.

3 Software Tools In this section we are presenting some software tools we have developed in order to address the issue of promoting positive interdependence using explicit mechanisms. The subjects may be high school or college students. 3.1

Chase the Cheese

This game is played by four persons, each one with a computer. The computers are physically distant and the only communication allowed is computer-mediated.

Fig. 1. Chase the Cheese user interface (in Spanish)

Players are given very few details about the game. Participants while playing must discover the rest of the rules. They also have to develop shared strategies to succeed. The goal of the game is to move a mouse through a labyrinth to its cheese. The labyrinth is divided in four quadrants, and each quadrant has a coordinator -one of the players. The other participants can only help the coordinator sending their messages,

360

C.A. Collazos et al.

(see Figure 1). Each player has two predefined roles: coordinator (only one per quadrant and randomly assigned) or collaborator (the three remaining). These roles are switched during the collaborative activity. Most of the obstacles are invisible to the quadrant coordinator, but visible to one of the other players [2]. 3.2

MemoNet

This game is loosely based on the classic “Memorize Game”, which goal is to find the equal pair within several covered cards. This is repeated successively until there are no covered cards remaining. In the case of MemoNet, the idea is that four people try to find four equal cards from an initial set of ten different cards.

Fig. 2. MemoNet user interface (in Spanish)

All players have the same set of cards but ordered in different ways. A person draws one card each time. So, they need to collaborate in order to solve the problematic situation. The card is removed when the four players have found it. The game continues until all cards are uncovered. The game is played in a distributed fashion, with communication allowed through a chat tool [3]. Also it provides a space where the player places his name to be able to connect himself to the server (see Figure 2). 3.3

ColorWay

This game has a 6 x 4 board of colored squares with obstacles (see Figure 3). Each player can see her own obstacles (with her color). Each player has a token with her

Collaborative Scenarios to Promote Positive Interdependence among Group Members

361

color, and this token can progress from the lower row to a target located on the upper row. The player can move the token using the arrows and back buttons only through grey squares, which are not currently used by another token. Another restriction to do movements is given by the progress of the other tokens: no token can go to row n if there is a token in row n-2. In a similar way to MemoNet, this game provides communication through chat. The problem is there is only one way to arrange the tokens, therefore they need to communicate in order to win the game [3].

Fig. 3. ColorWay user interface (in Spanish)

3.4

CCCuento

This tool helps a group to collaboratively write stories. Four participants work four stories at the same time. Each story has four phases: introduction, body A, body B and conclusion. Each member must write a different section of every story. In a first stage every participant writes introduction of one of the stories. In a second stage every participant writes the first part of the development of a different story (body A) whom wrote the introduction. Then, they continue working until they finish all stories. The group members may edit the parts they were responsible at any time during project development (see Figure 4).

362

C.A. Collazos et al.

Fig. 4. CCCuento user interface (in Spanish)

3.5

TeamQuest

This game is another labyrinth with obstacles [4]. The players of a team must reach a goal by satisfying subgoals in each of the game stages. Each player is identified with a role image and name. The screen has three well-defined areas: game, communication and information (see Figure 5). The game area has four quadrants (each one assigned to a player who has the “doer” role; the other players are collaborators for that quadrant). In a quadrant, the doer must move an avatar from the initial position to the “cave” that allows entering the next quadrant. In the way, the doer must circumvent all obstacles and traps in the map (which are not visible to all players). Moreover, the doer must pick an item useful to reach the final destination. The user interface has many elements showing awareness: the doer’s icon, score bars, items which were picked up in each quadrant, etc. (see Figure 5).

4 Kinds of Positive Interdependences Johnson, et al. describe three levels in establishing positive interdependence [11]. The teacher first has to assign the group a clear, measurable task, then structure positive goal interdependence, and finally blend positive goal interdependence with other

Collaborative Scenarios to Promote Positive Interdependence among Group Members

363

types of positive interdependence. They mention positive interdependence as what distinguishes a cooperative learning group from a casually connected group. This aspect is intentionally planned so that all members must participate in order for the task to be completed. It is the "glue" that holds the members together. There are several different types of positive interdependence [11] which are described in the next sections.

Fig. 5. TeamQuest user interface

4.1

Positive Goal Interdependence

Students must perceive they can achieve their learning if and only if the other members in the group achieve their goals. The group is motivated to achieve a common goal so they must be concerned with how much each other learns, they must understand that they must sink or swim together. The teacher therefore has to structure a clear group goal such as having students learn the assigned material and ensuring that. Examples: In Chase the Cheese, MemoNet, ColorWay and TeamQuest, the software presents a strict goal positive interdependence because team members need each other to succeed. The only way to reach the goal is through the team collaboration where the participants can define, communicate and negotiate different strategies in order to solve the problematic situation. In CCCuento, the goal of the activity is to generate the stories. Of course, all participants are co-authors of all the stories. This goal cannot be reached unless all group members do their part. If there is failure, the blame is also shared.

364

4.2

C.A. Collazos et al.

Positive Celebration/Reward Independence

A joint reward is given for successful group work and members’ efforts to achieve it. When the group achieves its goals each member receives the same reward, sometimes teachers give students a group grade, an individual grade from a test and bonus points if all members achieve the set goals. Regular celebrations of group efforts and successes stimulate cooperation. Examples: In Chase the Cheese when starting to move the mouse, the coordinator has an individual score of 100 points. Whenever the mouse hits an obstacle, this score is decreased 10 points. When the mouse passes to another quadrant the individual score is added to the total score of the group. If any of the individual scores reaches a value below or equal to 0, the group loses the game. The goal of the game is to take the mouse to the cheese and do it with a high total score (the highest score is obviously 400 points). 4.3

Positive Resource Interdependence

Each member has only a portion of the information, resources, or materials needed for the task to be completed and the members' resources have to be combined in order for the group to achieve its goal. Unless the members combine their resources the group will not achieve its goals. The teacher may want to give students limited resources and emphasize the importance of sharing and cooperating in order for the group to succeed. Examples: In TeamQuest, as each member has only a portion of the information about traps- which is necessary for the task to be completed- the members’ information need to be shared in order for the group to achieve its goal. In Chase the Cheese, since each participant has a partial view of the labyrinth, she must interact with her peers to solve the problem. In MemoNet, each participant has a partial view of the game; therefore, the player must interact with her peers to solve the problem. ColorWay uses the same idea. 4.4

Positive Role Interdependence

Each member is assigned roles that are inter-connected and which give specific responsibilities that the group needs in order to complete the joint task. The teacher needs to assign complementary roles such as reader, recorder, checker of understanding, encourager of participation, and elaborator of knowledge. These assigned roles ensure high-quality learning. An example of the usefulness of these roles is the checker of understanding. The teacher cannot verify the understanding of every student at all times. However, a student can do this work for her by periodically asking each group member to explain what is being learned. Examples: In TeamQuest there are two predefined roles: Doer and Collaborators. Roles are switched during the collaborative activity. In Chase the cheese, the roles are coordinator (only one per quadrant and randomly assigned) or collaborator (the three remaining). The roles are also interchanged during the game.

Collaborative Scenarios to Promote Positive Interdependence among Group Members

4.5

365

Positive Identity Interdependence

Group members have to find and agree upon an identity, which can be a name, a motto, a slogan, a flag, or a song. Example: In TeamQuest, before playing it, a player creates a new game instance, according to her personal preference. Each player wishing to enter this new game must choose an avatar according to the type of game. In that way, group members define an identity within the game. In CCCuento this is achieved by choosing the group name and the story title, trying to find consensus. 4.6

Environmental Interdependence

Students are bound together by the physical environment in which they work. So the teacher has to find an environment that unifies students. Although there is not a common physical environment where members of the group can play, there is a virtual shared environment in which they can solve the problematic situation in a collaborative way. Examples: This interdependence applies to all software tools we have developed. The computers are distributed and the only communication allowed is computermediated. 4.7

Positive Fantasy Interdependence

The teacher gives students an imaginary task. Students have to come up with solutions for extreme situations such as endangered life or handling very powerful future technology. A typical example of this is a game including an imaginary environment, where the group members assume various kinds of imaginary roles. Examples: Chase the Cheese and TeamQuest include this feature. In TeamQuest group members can choose several environments. For example, they can pretend to be in the Middle Age, and according to that, different kinds of characters appear, as Paladin, Elfo, Bardo. They then need to use language to accomplish goals in their imaginary situations. 4.8

Positive Task Interdependence

Work has to be organized sequentially. Students have to divide the work and be linked with each other. As soon as a team accomplishes its portion of the task, the next team can proceed with its responsibility, and so on. Examples: In Chase the Cheese and TeamQuest, the fact that only one player has the control of the game, and that control is switched every time that a player passes through every cave or quadrant, provides sequentiality. For most tasks, one group member must complete her work before another person gets her turn.

366

4.9

C.A. Collazos et al.

Positive Outside Enemy Interdependence

Teacher puts groups in competition with each other. In this way, group members feel interdependent and do the best to win the competition and be above other groups [11]. This interdependence does not apply to collaborative learning in our examples. There are nine kinds of positive interdependences, and it could be difficult to try to define which is the most important one. However, the greater positive interdependence is structured within a cooperative group, the more group members will feel personally responsible for contributing their efforts to accomplish the group goals and the more they will realize that negative sanctions appear for failing to do one’s part. Table 1 presents a summary of the kinds of positive interdependences offering some tips on how to design and implement them in a software tool. Also, shows some examples of our software tools. These eight types of positive interdependence (we do not include Positive Outside Enemy Interdependence) are not mutually exclusive. Indeed, our software tools described in this paper involve several types of positive interdependence.

5 Discussion Rather than simply allowing students to interact in small groups and then hoping they will do so in a cooperative manner, our software tools incorporate specific procedures designed to create a feeling of group identity among students and collective responsibility for one another's learning. It is important to notice that we are drawing insights from studies done at unsupported face-to-face settings. Our study, instead, includes computer-mediated communication. The computer support introduces several aspects into the collaborative situation by modifying the interdependences, as discussed below. The following procedures are used to increase the likelihood that this sense of positive interdependence develops within groups: Group Production of a Common Product at the End of the Cooperative Learning Experience. In contrast to the usual discussion, or buzz group which gets together for informal discussion of some course related issue, each group is expected to generate a formal product which represents a concrete manifestation of the group collective effort (it solve the problematic situation). The objective of working towards a clearly defined common goal is essential for keeping individual students on task and focused on a group goal. Assignment of Interdependent Roles for Each Group Member. A sense of individual responsibility to the group may be increased if each group member has a specific and essential role to play in achieving the group's final goal or product. Roles can also be assigned on the basis of different perspectives that group members are expected to contribute to the final product e.g., historical, ethical, economic, or global, etc. Such role specialization assures that each individual has an explicit and well differentiated responsibility to the group throughout the learning process. A further advantage of role specialization is that the quality of each member's contribution can be more readily identified and assessed by the instructor, thus allowing for individual grading and individual accountability which is a critical feature of Collaborative Learning [11]. This monitoring feature distinguishes our approach from the unsupported previous face-to-face experiments.

Collaborative Scenarios to Promote Positive Interdependence among Group Members

367

Table 1. Kinds of positive interdependences Interdependence Goal

Reward

Resource

Role

Identity

Environment

Fantasy

Task

Guidelines One way to promote that kind of positive interdependence could be including some break points, where group members ha-ve to check success crite-ria, such as guidelines, roles and boundaries. It can be built into the group by having some form of shared grades. E.g., besides their indivi-dual scores on an activity, the tool gives a certain number of points if all group members score at or above a certain score. Students do not have to complete the task by themselves. The tool must “force” to interact hiding part of the information to some participants. The participants of the session using the software tool must have specific roles assigning specific responsibilities to each person. These roles must be interchanged. It provides a mechanism through which people can choose an avatar, name of the group, and level of difficulty. It provides a virtual shared environment in which they can solve the problematic situation in a collaborative way. Design the interface using imaginary situations where those participants find enjoyable and captivating. Design the activity in a sequential way. To complete certain part it is necessary to have comple-ted a previous part. One group member must first complete her task before the next task can be completed.

Examples In CCCuento, before passing to another phase it is necessary to solve a consensual activity. E.g., the first synchronization instant (before passing to “body A” part), has a break in which the students must assign a name to their group. After finishing the last phase, they must give a name to the story. In Chase the cheese there are partial and total scores. In CCCuento, we have used the software tool as part of a writing course. At the end, the teacher gives a grade according to the quality of stories presented.

In Chase the Cheese, TeamQuest, MemoNet and ColorWay every member of the group has only 25% of the total information to solve the problematic situation. In Chase the Cheese, MemoNet, ColorWay and TeamQuest there are two kinds of roles: Coordinator and collaborators. These roles are exchanged during the collaborative activity. TeamQuest includes an option to choose an avatar according to the type of game.

In Chase the Cheese there is a collaborative shared virtual environment, where players must lead the mouse to its cheese. In TeamQuest group members pretend to be in another time (revival, medieval, etc), or to be different people. In Chase the Cheese and TeamQuest group members must fulfill a partial goal that is accomplished when every one of them “solves” her own quadrant before passing to the other quadrant.

368

C.A. Collazos et al.

Team-Building Activities Designed to Produce a Sense of Group Identity and Cial Cohesiveness. For example, in CCCuento, before passing to another phase it is necessary to solve a consensual activity. Such activities would include ice breakers or warm-up activities when groups are first formed; creating team names; providing explicit suggestions and concrete recommendations for promoting cooperation and teamwork The underlying rationale for these team-building activities is to create a social and emotional climate conducive to the development of an esprit de corps and a sense of intimacy among the group’s members. This will enable them to feel comfortable in future tasks that will ask them to express their personal viewpoints, disagree with others and reach consensus in an open, non-defensive fashion. The key assumption here is that the potential cognitive benefits of small-group learning are more likely to be realized in a social context characterized by group cohesiveness, mutual trust, and emotional security. Furthermore, such explicit attention to the social and emotional aspects of small-group dynamics may be instrumental in fostering social support and emotional ties among peers which are factors known to have a significant impact on student retention [19].

6 Conclusions Positive interdependence provides the context within which promotive interaction takes place, group membership and interpersonal interaction among students do not produce high achievement unless positive interdependence is clearly structured. For that reason, it is not only important to design the software tool and the task, but to consider other aspects such as teacher’s participation, learning goals, etc., in order to have a collaborative environment. Positive resource, role, and task interdependence result in individuals realizing that the performance of group members is mutually caused. No student is on her own. As a result of mutual causation, cooperative efforts are characterized by positive inducibility, i.e., that group members are open to being influenced by each other. If one member of the group has taken the action there is no need for other members to do so [14]. Just putting students in groups and telling them to work together may not be sufficient to achieve positive interdependence among them [10]. For this reason, it is necessary to structure collaborative activities in order to promote positive interdependence among members of the group. High positive interdependence within a cooperative group means the group members feel personally responsible for contributing their efforts to accomplish the group goals. They are also aware there are negative consequences when failing to do one’s own part. Being a member of a group is not sufficient to promote higher achievement - there has to exist positive interdependence among all group members (this would be the case if, e.g., the performance of any group member affected the grade received by all group members). Positive interdependence makes each member feel willing to work hard to make sure that the whole group is successful. It is needed to have individuals interact with one another while they work. Positive interdependence in cooperative situations goes beyond motivating students to work hard and it facilitates the development of new insights and understandings through promotive interaction (it exists when individuals encourage and facilitate each other's efforts to achieve, complete tasks and produce in order to reach the group's goals).

Collaborative Scenarios to Promote Positive Interdependence among Group Members

369

The collaborative scenarios we propose are based on an interpretation given by Dillenbourg on how to link learning situations, interactions, cognitive mechanisms and cognitive effects when groups engage in solving problems [9]. We include positive interdependence as an element to help promote that kind of collaborative situation. Through careful planning, positive interdependence can be established by having students, achieve: (a) mutual goals, such as reaching a consensus on specific solutions to problems or arriving at team-generated solutions; (b) mutual rewards, such as individually assigned points counting towards a criterion-referenced final grade, points which only help, but never handicap; (c) structured tasks, such as a report or complex problem with sections mutually developed by all team members; and (d) interdependent roles, such as group members serving alternately as discussion leaders, organizers, recorders, and spokespersons [16]. Acknowledgments. This work was supported by Fondecyt (Chile) grant Nº 1030959 and graduate thesis scholarship No.49 from Departamento de Postgrado y Postitulos, Universidad de Chile (2002).

References [1]

Al-Saleh, M., Muwakkil, F., Cooperative Learning Teaching Strategies. http://www.mcli.dist.maricopa.edu/labyforum/Win96/win96F3.html, 1996 [2] Collazos, C., Guerrero, L., Pino, J., & Ochoa, S., Evaluating Collaborative Learning Processes. In J. Haake and J.A. Pino (Eds.): Groupware: Design, Implementation and Use. Lecture Notes in Computer Science 2440, 2002, pp. 203–221 [3] Collazos, C., Guerrero, L., & Pino, J., A Computational Model to Support the Monitoring of the Collaborative Learning Process. Accepted for International Journal of Learning Technology (IJLT), 2003 [4] Collazos, C., Guerrero, L., Pino, J., & Ochoa, S., A Method for Evaluating ComputerSupported Collaborative Learning Processes. International Journal of Computer Applications in Technology (IJCAT). To appear during 2003 [5] Cooper, J., Prescott, S., Cook, L., Smith, L., Mueck, R., & Cuseo, J., Cooperative learning and college instruction: Effective use of student learning teams. California State University Foundation, Long Beach, CA, 1990 [6] Cuseo, J. Collaborative and cooperative learning: Pedagogy for promoting new-student retention and achievement. Preconference workshop delivered at the 19th Annual Conference on The First-Year Experience, Columbia, SC., 2000 [7] Chickering, A., Education and identity. San Francisco: Jossey-Bass, 1969 [8] Deutsch, M., An experimental study of effect of cooperation and competition upon group process. Human relations, Vol. 2, pp.199–231, 1949 [9] Dillenbourg, P., What do you mean by collaborative learning?. In P. Dillenbourg (Ed) Collaborative-Learning: Cognitive and Computational Approaches. Pp. 1–19, Oxford:Elsevier, 1999 [10] Jacobs, G., Siowck, G., Ball, J., Learning cooperative learning via cooperative learning: A sourcebook of lesson plans for teacher education. Kagan Cooperative Learning, San Clemente, CA, 1995 [11] Johnson, David, W., Johnson, Roger T. & Holubec, Edith J., Circles of learning: Cooperation in the classroom. Edina, MN: Interaction Book Company, 1986 [12] Johnson, D., & Johnson, R., Learning together and alone. Englewood Cliffs, NJ: PrenticeHall, 1987

370

C.A. Collazos et al. th

[13] Johnson, D, Johnson, R., & Holubec, E., Cooperation in the classroom (6 ed.). Edina, MN: Interaction Book Company, 1993 [14] Johnson, D.,& Johnson, R., Learning Together and Alone, 5th ed., 1999 [15] Kagan, S., Cooperative learning. San Juan Capistrano, CA: Resources for Teachers, Inc., 1992 [16] Millis, B., & Cottell, P., Cooperative learning for higher education faculty. Phoenix: American Council of Education. Oryx Press, 1998 [17] Silberman, M., Three ways to add spark to cooperative learning. Cooperative Learning and College Teaching, 7(3), pp. 7–8, 1997 [18] Slavin, E., Cooperative learning. New York: Longman, 1983 nd [19] Slavin, R. E. Cooperative learning: Theory, research, and practice (2 ed.).Boston, MA: Allyn and Bacon, 1995 [20] Smith, K., Cooperative learning: making “group work” work. In Sutherland, T., E., and Bonwell, C (Eds), Using active learning in college classes: A range of options for faculty, New directions for teaching and learning. No. 67, 1996

Building Virtual Communities for Information Retrieval Daniel Memmi1 and Olivier Nérot2 1 LEIBNIZ-IMAG 46 avenue Felix Viallet, 38000 Grenoble, France [email protected] 2 AMOWEBA SAS 41 rue de Cronstadt, 75015 Paris, France [email protected]

Abstract. The search for relevant information is often hindered by the initial difficulty in formulating precise requests, and because much knowledge is actually tacit and thus not easily accessible. Asking for human assistance is the usual response to these problems, but one can develop computer systems to help locate the right persons in the search for information. We describe the structure and functioning of a collaborative, distributed search system designed to emulate the information-gathering functions of social communities. Such systems can be used to create virtual communities as well as to improve information retrieval.

1 Introduction Information retrieval methods have become essential to manage an ever-growing information store, notably on the Web. Information Retrieval is now a mature domain [9,14], offering well-known techniques and applications. It is also a domain where progress now consists mostly in small incremental steps, improving classical performance indicators of recall and precision by a few percentage points only. One of the main reasons for such limited search performance is poor request formulation. When starting a search process, users often submit vague, incomplete or inaccurate requests. Because of their initial lack of knowledge about the subject matter, users do not come up easily with established terms and expressions or their common variants, and search results therefore prove disappointing. Of course, methods have been devised to tackle the common problem of poor initial requests [14]. Using a thesaurus to expand or rephrase a request with related terms is one possible answer, but the search might still remain too general. Relevance feedback is more focused, but usually requires one or two interactive passes. The user must indicate whether the results of an initial request are relevant or not, so that the request may be modified accordingly by the system. Another fundamental reason for the limited usefulness of search techniques is that much information is in fact tacit [12]. Indexing and retrieval techniques can only deal with explicitly formulated knowledge, to be found in databases or textual documents in electronic form. But know-how, professional skills and expertise are tied up with J. Favela and D. Decouchant (Eds.): CRIWG 2003, LNCS 2806, pp. 371–379, 2003. © Springer-Verlag Berlin Heidelberg 2003

Building Virtual Communities for Information Retrieval

372

individuals and their interactions, and are not publicly accessible. Tacit knowledge is unfortunately both very common and socially important. All this explains why the initial source of our information is usually not explicit documents, but other human beings. When people set about some inquiry, they often start by asking more knowledgeable people for advice about how and where to find relevant information. They ask for help in formulating the right requests with the correct vocabulary, and in locating the most likely sources of information, whether human or textual. In short, human beings use interest communities and social networks to find the information they want. Modeling or building such communities and networks should therefore help in the search for relevant knowledge, and several research projects have been developed in this direction. We describe in this paper a collaborative search system, called Human Links, designed to model and emulate the informative function of social networks. By profiling computer users and clustering them according to their interest centers, this system will create a virtual community and use it for information retrieval purposes. Requests will be expanded, relations established and documents shared so as to promote a better exchange of knowledge between participants.

2 System Overview The Human Links software, a collaborative and distributed search engine, has been developed by a recently created French start-up: Amoweba. For more details about the company, please see its Web site: http://www.amoweba.com. 2.1

System Outline

The basic concept of Human Links is to establish a peer-to-peer network of registered users to help them in their search for relevant information. The peer-to-peer (P2P) approach consists in creating direct links between computer users without necessarily going through a central server. Unlike a classical server/client architecture, operations and data are as distributed as possible among a network of users. A peer-to-peer architecture offers potentially unlimited computing power and data storage, contributed by the many computers linked together in a common network. The approach also provides an answer to the updating problem of centralized indexing servers, which cannot keep track of the constant additions, deletions or modifications to Web pages and documents. Of course, adequate software is then necessary to coordinate operations throughout the network. This is the general model behind famous file-sharing software such as Napster [10], Gnutella [3] or KaZaA [7]. The goal of Human Links is not simply to share files, however, but to help find all kinds of information, through human contact or by answering formal requests. There are two main modes of operation for this system: it can be employed to locate knowledgeable users on a given subject, or to answer imprecise requests by augmenting them with expert knowledge found in the user network. The two modes have in common the profiling of the system’s users so as to create virtual communities sharing similar interests. These communities are essential to the functioning of the system, for the fundamental idea underlying Human Links is that

373

D. Memmi and O. Nérot

social links are a good way to locate relevant information. In the case of tacit knowledge, this might indeed offer the only possible access to information. In other words, information retrieval should start first with a search for the right persons, before trying to launch a more classical search for documents. From a technical point of view, this results in a distributed and collaborative system, typical of the peer-to-peer approach. The advantage is a potentially more powerful and robust functioning, as data and operations could be distributed throughout the network of registered computers. On the other hand, this approach might cause potential privacy and security problems, which will have to be addressed. 2.2

Similar Work

Human Links may be compared to related projects. The main idea of linking people with similar interests is to be found in several systems, which differ in their primary motivation and their definition of similarity. Using bookmarks to regroup people is now quite common, probably because it is both reasonably informative and fairly easy to do. Systems such as Grassroots [5], SiteSeer [13] or kMedia [16] consider not only a user’s set of bookmarks, but also their folder structure to form interest communities. Other systems use different sources of information to compute a similarity between users. For example Referral Web [6] looks at bibliography databases, but one could also use e-mail messages or browsing patterns to establish individual profiles for comparison. Community organization or browsing recommendations, and not information retrieval per se, however, seem to be the primary motivation of those systems, whereas Human Links was designed to be a practical search engine. In this respect, the closest system is probably Opencola [11], which also performs a distributed search through a network of various sources. The problem of tacit information is also a well-known issue in knowledge management, but is usually not discussed sufficiently in computer science.

3 System Functions Users of Human Links register at first by downloading the system software on their individual computer, which must of course be connected to the Internet (or to an intranet). Human Links will then work as an addition (plug-in) to common browsers (e.g. Explorer or Netscape). The software will operate both locally and by co-ordinating distributed operations and data transfers over the network of users. 3.1

User Profiling

The first stage is to establish locally a characteristic user profile by examining a user’s files. This could be done by inspecting various types of documents: e-mail messages, attached documents, Web pages, text files, etc., but we have chosen user bookmarks (i.e. favorite Web pages) as a simple solution. One may suppose that a user’s book-

Building Virtual Communities for Information Retrieval

374

marks are characteristic enough of his interests. This is a debatable assumption, but our tests so far have been encouraging. Vectorization. The Web pages corresponding to the bookmark pointers are gathered as an unstructured set (the bookmark folder structure is not used in the present version). Each Web page is represented by a numerical vector according to the vectorspace model of document processing [14]. Common function words (articles, particles, auxiliaries...) with little semantic content are first discarded. Occurrences of more significant words (mostly nouns and verbs) are counted, after a simple stemming process has reduce related words to a common form (term). The frequency of terms in a page is weighted to give more importance to the more discriminating terms in the corpus of pages (classical TFIDF measure) and this value for each term produces a vector for the page. This vectorization stage is standard in document indexing for information retrieval, and there exist many variants. Term frequency is usually the basic measure for vector components, but more sophisticated properties are also available. Informationtheoretic measures may be used, but for common profiling purposes, simple indexing schemes such as TFIDF seem good enough. This approach is also languageindependent and does not requires an initial dictionary. Clustering. These vectors are now clustered with a variant of the well-known kmeans algorithm [1,8], so as to reveal groups of pages corresponding to the user’s interest centers. The clusters obtained may be compared to the bookmark folders (if any) to ascertain their relevance: clusters should correspond to user-defined folders. This unsupervised classification is necessary because a user may have totally different interests (let’s say computing, politics and sports) that should be kept separate for further processing. The centroid of each cluster will then be used as a prototype vector for an interest center, and a user profile will consist of several such prototypes. The classification of bookmarks is a first benefit for the user. It can be used to organize a set of bookmarks, improve or modify a prior folder structure, or simply to visualize this organization on an interactive map (see below). The clustering algorithm may also be applied to other document types, and the resulting map can be very useful. 3.2

Collaborative Search

Initial profiling can be done locally on the individual user’s computer, but the next stages must involve interactions between different computers on the network. This is typical of a peer-to-peer approach and offers potentially much more computing power than on a central server. Virtual Communities. Individual user profiles may be compared in order to regroup users with similar interest centers so as to form communities, but in fact communities remain virtual and are implicitly revealed by the proximity of requests to particular users. Note that users in a community are seen only through their relevant interest center, and users may well belong to several communities. For the sake of clarity, we

375

D. Memmi and O. Nérot

will call "contact" a user identified by one of its interest centers, and communities consist of contacts rather than users. Communities may also be represented by vectors: the centroid of a cluster of users is the prototype for the community. As a matter of fact, all items in this system (documents, interest centers, contacts, communities, requests...) are represented by lexical vectors, which will make comparisons possible between various items. Virtual communities can now be used to foster social interactions. Members of a given community may communicate with one another by e-mail, instant messaging ("chat" such as ICQ) or any other means. A request for information can then be discussed with other knowledgeable human beings. But the privacy of individuals must be protected: their consent is required before disclosing personal information about them (such as their name and address). Search Process. These communities can also support an automatic collaborative and distributed search process. A novice about some subject domain will find it hard to formulate pertinent, focused requests, but given an imprecise request, the system will be able to find expert users with similar interests. Their bookmarks or documents might be relevant for a novice and expert interest prototypes help to formulate more focused requests. An initial request may consist of keywords as well as particular interest centres. The request is sent to other users with a profile similar to the request. If the similarity is good enough, documents will be sent back, and the new profile may be used to focus the request, and so on from user to user [15]. Each user may lead to several others, so that the search graph looks like a tree. This process propagates forward and backward through the network to gather relevant documents or items. Requests jump forward from one user to another with similar interests, but care must be taken to limit the depth and breadth of the search. To ensure this, a propagation parameter is set before launching a search; this may be seen as a kind of diffusion energy associated with a request, which is progressively used up during the forward pass. The backward pass starts when this energy has been exhausted, and search depth has been limited to 7 jumps anyway. Requests also keep a trace of the path followed, to avoid potential loops and to allow a distributed backward pass without central supervision. Answers to a request are sent back directly to the caller, so that it does not matter if an individual computer is switched off between the forward and the backward pass (or becomes inaccessible). Duplicate documents are then discarded and answers sorted by order of relevance. 3.3

Interactive Map

The graphical interface is essential to the system’s usefulness. Classical information retrieval systems (using requests and lists of documents) are not very intuitive for inexperienced users, and we have devoted great care to the design of the interface. Map Components. The main component of the interface is a map on which are displayed interest centers, users, virtual communities, documents and requests (Fig. 1). Those different items can be shown on the same map because they are all represented

Building Virtual Communities for Information Retrieval

376

by vectors. This common representation format makes it possible to compare very different objects. Note, however, that the two-dimensional map is a projection from a multi-dimensional space, with some inevitable loss of information. One must also suppose that all items belong to the same vector-space, i.e. the space of possible lexical terms. In our experience, such a map is much more intuitive and easier to use than a set of folders or a category tree. Documents are more or less distant from other items on the map, and do not have to be classified into exclusive binary categories. Beside the map, the interface also shows a list of interest centers and a list of documents returned. If the vector-space is defined by reduced dimensions of the kind computed by factor analysis from original lexical features, terms can also be placed within the same space and on the same map. Principal Component Analysis [4] [8] is probably the best known dimensionality reduction technique, and one version of the system employs it to represent all items. We used a neural network technique to compute the new dimensions, an approach of interest in itself [2] which can be compared with Latent Semantic Indexing.

Fig. 1. System interface with interactive map

User Interaction. This is an interactive map: the user can move items on the map (with the mouse) and this action will change the underlying representation. For example the user may want to move a document closer to an interest center, and the document vector will be modified accordingly. Interest centers may also be placed within a cloud of documents, superseding the system’s classification. Requests may also be defined by their placement on the map.

377

D. Memmi and O. Nérot

One can define an influence zone around items (roughly by drawing on the map a circle around an item). When an item is displaced and modified, all items within its zone of influence are also visibly displaced on the map and modified accordingly. This influence may be designed as decreasing with the distance to the central item; gravity would be a good metaphor for this diminishing effect. Such interactive modifications pose serious updating and coherence problems, made even worse by the two-dimensional projection, and this capability should be designed with care and used with caution. Nonetheless, giving the user some control over the representation of objects in the system seems important, and poses interesting theoretical questions. Lastly, for this interactive map to be acceptable in practice, the user should not have to wait for results and modifications to be displayed. This is a very important practical constraint on the profiling and clustering algorithms, which must work online. Incremental versions of these algorithms might have to be developed to speed up computation. 3.4

First Results

All the features of Human Links presented here have been implemented. The system works as described, and all modules (profiling, clustering, visualization, search and retrieval) have been tested separately and together. Tests have been run with thousands of participants, but we do not have yet the experience of real-life, everyday use with thousands of participants. So we are now about to install the software on the student network of a large French university. We are confident about the operation of the system, but we are not quite sure about how participants will choose to use it. For example will they emphasize human communication or formal requests? Security concerns are also worth mentioning. Systems managers are often uneasy with peer-to-peer, notably because of the danger of security breaches (by viruses or hackers) in a distributed computation network. Company firewalls try to limit access from outside, and we had some difficulties at first to make Human Links work in such environments. One conclusion might be that such a system is easier to accept over an intranet within a huge organization than at large via the Internet.

4

Discussion

This collaborative approach to information retrieval raises several questions. The underlying philosophy is that the best way to go about a request for information is to do a computer-aided search for the right people. This is closer to the way human beings operate, but human factors must then be considered and evaluated. Privacy is an important issue. Belonging to a community can be beneficial, but may also bring unwanted attention (although profiling decreases to some extent the risk of receiving irrelevant information). To ensure the ethical and social acceptability of such a system, the right of participants to remain anonymous must be guaranteed. We have been careful to hide from others the name and address of each participant (by using a coded identifier). Before disclosing somebody’s address, he must have granted

Building Virtual Communities for Information Retrieval

378

his permission. Experts in particular are busy people who do not want to be flooded with personal requests from novices. One should also be clear about the real benefits and limitations of such a system. This approach attempts to assist in the search for explicit information by exploiting tacit knowledge and human expertise. But whatever the particular source chosen (Web bookmarks in this case), the system can only capture expertise having left computer traces. This is obviously a limited view of human knowledge. Although people deal more and more with computers and computer-controlled devices (e.g. cash machines and credit-card readers) in their professional and daily life, a major part of social interactions does not take place by computer. Face-to-face meetings and phone calls still represent the bulk of human contacts. The kind of system we have been describing can only make use of computerized interactions and is clearly geared toward textual documents.

5 Conclusion We have described a collaborative and distributed search system developed to help find knowledge which happens to be shared among various human beings. It is thus possible to locate information which might not be found otherwise in electronic documents. The Human Links system will help a novice user to formulate more focused requests by exploiting the profiles of expert users in a network of registered participants, and will facilitate direct contact between participants with similar interests. The system shows how to make accessible valuable tacit knowledge. This approach can be seen as an attempt to fulfill several goals at the same time. Its primary objective was to locate relevant documents, even with poor initial requests, a classical goal of information retrieval. But this is achieved by creating virtual communities, which could then give rise to real human relationships among the participants. In this way is also modeled to some extent the information-gathering function of human social networks, an interesting task in itself. The computer system may thus fulfill some important social needs as well as more technical goals. Acknowledgment. We would like to thank the whole development team of the Human Links project. The system described here would not have become a reality without their various individual contributions.

References 1. Anderberg M.R. (1973) Cluster Analysis for Applications, Academic Press 2. Delichère M. & Memmi D. (2002) Neural dimensionality reduction for document processing, ESANN’02, Bruges 3. Gnutella, http://www.gnutella.com 4. Jolliffe I.T. (1986) Principal Component Analysis, Springer Verlag 5. Kamiya K., Roscheisen M. & Winograd T. (1997) Grassroots: a system providing a uniform framework for communicating, structuring and organizing people, Proceedings of WWW-6

379

D. Memmi and O. Nérot

6. Kautz H., Selman B. & Shah M. (1997) Referral Web: combining social networks and collaborative filtering, Communications of the ACM, 40 (3) 7. KaZaA, http://www.kazaa.com 8. Lebart L., Morineau A. & Piron M. (2000) Statistique Exploratoire Multi-dimensionnelle, Dunod 9. Manning C.D. & Schütze H. (1999) Foundations of Statistical Natural Language Processing, MIT Press 10. Napster, http://www.napster.com 11. Opencola, http://www.opencola.com 12. Polanyi M. (1966) The Tacit Dimension, Routledge & Kegan Paul 13. Rucker J. & Polanco M.J. (1997) SiteSeer: personalized navigation for the Web, Communications of the ACM, 40 (3) 14. Salton G. & McGill M. (1983) Introduction to Modern Information Retrieval, McGrawHill 15. Spalanzani A. (2002) Partage des connaissances et système peer-to-peer : le système Human Links, AIM’02, Hammamet 16. Takeda H., Matsuzuka T. & Taniguchi Y. (2000) Discovery of shared topics networks among people, PRICAI’00, Melbourne

Author Index

Kwon, Yong-won

Adam, Fr´ed´eric 261 Alarc´ on, Rosa 314 Antunes, Pedro 109, 159 Arroyo-Sandoval, Pedro 277

Landgraf, Britta 74 Lee, Yung-Chuan 135 Le Pallec, Xavier 82 Lintinen, Risto 345 Lukosch, Stephan 26

Baloian, Nelson 199 Betbeder, Marie-Laure 90 Biemans, Margit 58 Borges, Marcos R.S. 208, 232, 300 Bourimi, Mohamed 74 Bourquin, Yvan 99 Br´ezillon, Patrick 261 Carro, Rosa M. 191 Collazos, C´esar A. 247, 356 Collet, Ludovic 82 Costa, Carlos J. 109 D’Annunzio Cavalcanti, Gabrielle Daradoumis, Thanasis 126 Derycke, Alain 82 de Freitas, Rosa M. 232 de Lima Bezerra, F´ abio 151 de Souza, Jano 224 Dillenbourg, Pierre 99 Favela, Jesus 330 Fuks, Hugo 183 Fuller, David A. 314 Gerosa, Marco Aur´elio 183 Gonzalez, Victor M. 330 Goslin, Jeremy 99 Greenberg, Saul 1 Guerrero, Luis A. 247, 356 Haake, J¨ org M. 74 Haake, Anja 74 Hoogstoel, Fr´ed´eric 82 Hujala, Saku 345 Hwang, Gwan-Hwan 135 Jeong, Chang-Sung Kaarilahti, Niina Kim, Hyung-Jun

42

345 42

42

293

Marqu`es, Joan Manel 126 Mart´ın, Estefan´ıa 191 Martinez-Garcia, Ana I. 277 Memmi, Daniel 371 Mendes de Ara´ ujo, Renata 208 Mezura-Godoy, Carmen 10 Moreno, Melfry 224 Motelet, Olivier 199 Mour˜ ao, Hernˆ ani 159 Muniz Farias, Pedro Porf´ırio 293 Mu˜ noz, Miguel A. 330 N´erot, Olivier 371 Nova, Nicolas 99 Ochoa, Sergio F. Ortigosa, Alvaro

247, 356 191

Pereira de Lucena, Carlos Jos´e 183 Pereira Meire, Alexandre 208 Peter, Yvan 168 Pino, Jos´e A. 199, 232, 247, 356 Pohjola, Pasi 345 Pomerol, Jean-Charles 261 Raja Gabaglia Mitchell, Lu´ıs Henrique 183 Ramirez-Fernandez, Cristina 277 Rikalainen, Arto 345 Riveill, Michel 10 Rodr´ıguez, Marcela 330 Rosa, M´ arcio G.P. 300 Ryu, So-Hyun 42 Samuli, Pekkola 345 Santoro, Flavia M. 300 Santoro, Fl´ avia Maria 232 Schlichter, Johann 191 Sch¨ ummer, Till 74

382

Author Index

Slagter, Robert

58

Talbot, Stephane 10 Tchounikine, Pierre 90 Toivonen, Tero 345 Vantroys, Thomas 168 Vivacqua, Adriana 224

Wainer, Jacques 151 Wehrle, Thomas 99 Woo, Young-Je 42 Wu, Bor-Yih 135

Xhafa, Fatos

126