Groupware: Design, Implementation, and Use: 8th International Workshop, CRIWG 2002, La Serena, Chile, 1.-4. September 2002, Proceedings

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

2440

3

Berlin Heidelberg New York Barcelona Hong Kong London Milan Paris Tokyo

Jörg M. Haake José A. Pino (Eds.)

Groupware: Design, Implementation, and Use 8th International Workshop, CRIWG 2002 La Serena, Chile, September 1-4, 2002 Proceedings

13

Series Editors Gerhard Goos, Karlsruhe University, Germany Juris Hartmanis, Cornell University, NY, USA Jan van Leeuwen, Utrecht University, The Netherlands Volume Editors Jörg M. Haake FernUniversität Hagen, Computer Science VI - Distributed Systems Informatikzentrum Universitätsstr. 1, 58084 Hagen, Germany E-mail: [email protected] José A. Pino Universidad de Chile, Departamento de Ciencias de la Computacion Av. Blanco Encalada 2120, Santiago, Chile E-mail: [email protected]

Cataloging-in-Publication Data applied for Die Deutsche Bibliothek - CIP-Einheitsaufnahme Groupware : design , implementation , and use. 8th international workshop ; proceedings / CRIWG 2002, La Serena, Chile, September 1 - 4, 2002. Jörg M. Haake ; José A. Pino (ed.). - Berlin ; Heidelberg ; New York ; Barcelona ; Hong Kong ; London ; Milan ; Paris ; Tokyo : Springer, 2002 (Lecture notes in computer science ; Vol. 2440) ISBN 3-540-44112-3

CR Subject Classification (1998): H.5.3, H.5.2, H.5, K.3.1, K.4.3, C.2.4 ISSN 0302-9743 ISBN 3-540-44112-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 2002 Printed in Germany Typesetting: Camera-ready by author, data conversion by PTP-Berlin, Stefan Sossna e.K. Printed on acid-free paper SPIN: 10870261 06/3142 543210

Foreword Welcome to the 8th International Workshop on Groupware (CRIWG 2002)! The previous workshops took place in Lisbon, Portugal (1995), Puerto Varas, Chile (1996), El Escorial, Spain (1997), Búzios, Brazil (1998), Cancun, Mexico (1999), Madeira, Portugal (2000), and Darmstadt, Germany (2001). CRIWG workshops follow a simple recipe for success: good papers, a small number of participants, extensive time for lively and constructive discussions, and a high level of cooperation both within and between paper sessions. CRIWG 2002 continued this tradition. CRIWG 2002 attracted 36 submissions from 13 countries, nine of them outside Ibero-America. Each of the 36 articles submitted was reviewed by at least three members of an internationally renowned Program Committee. This year we used a double-blind reviewing process, i.e., the reviewers did not know who the authors of the papers were. In addition, the reviewers were chosen based on their expertise and we also ensured that they came from countries and institutions not related to those of the paper’s authors. This reviewer assignment worked remarkably well, as indicated by the high average confidence value the reviewers gave their own reviews. This means that papers were usually reviewed by experts in the paper’s topic. As a consequence, reviews were usually quite extensive and contained many suggestions for improvements. I would like to thank all the members of the Program Committee for their hard work, which I am sure contributed to improving the quality of the final articles. As a result of this rigorous reviewing process, 18 papers were accepted: nine long papers and nine work-in-progress papers. This year’s program grouped these papers into six sessions on CSCL, meeting support, design and development support, awareness, evaluation and tailoring, and infrastructure. Enjoy! Finally, many thanks to all authors who submitted articles and helped to make CRIWG 2002 a success. I would also like to thank the members of the Organizing Committee, chaired by José A. Pino, for their smooth organization of this workshop. September 2002

Jörg M. Haake

Preface On behalf of the Organizing Committee for this event, I was glad to welcome the participants to CRIWG 2002, the 8th International Workshop on Groupware. I hope they enjoyed the traditional Chilean hospitality. The CRIWG workshops are rooted in the Ibero-American community of researchers, but the latest versions have evolved to become truly open and international forums for researchers working in CSCW, CSCL and their applications. This has occurred thanks to the vision and work of the members of the CRIWG Steering Committee, notably Pedro Antunes, Marcos R. S. Borges, Jesús Favela, Jörg M. Haake, and Ana C. Salgado. The Program Committee prepared a rich scientific schedule of activities. I wish to thank this Committee for its excellent work and especially its Chairman, Jörg Haake, who dedicated many valuable hours to ensure the success of the workshop. We added several social activities to the schedule, opportunities for informal discussion, establishing new research contacts, or simply getting to know new colleagues. Several other people worked in the preparation of the event. I would like to thank Margarita García, Luis Guerrero and Sergio Ochoa for their enthusiastic support and hard work as members of the Organizing Committee. Also, I am grateful to Alejandro Fernández, who organized the Doctoral Consortium. The student volunteers helped with many details. I wish to mention three institutions and a company which helped to make this event possible: The institutions are Conicyt (the Chilean Government Science and Technology Office), the Universidad de Chile (which provided support), and the Universidad de La Serena (which provided local support). The company is Codelco, which sponsored the event. September 2002

José A. Pino

Conference Organization Program Committee Chair Jörg M. Haake, FernUniversität Hagen, Germany Program Committee Members Pedro Antunes, Universidade de Lisboa, Portugal Beatriz Barros Blanco, UNED, Spain Karin Becker, PUCRS, Brazil Marcos Borges, Federal University of Rio de Janeiro, Brazil Dominique Decouchant, LSR-IMAG, France Yannis Dimitriadis, Universidad de Valladolid, Spain Henrique Domingos, Universidade Nova de Lisboa, Portugal Oswald Drobnik, University of Frankfurt, Germany Jesus Favela, CICESE, Mexico Alejandro Fernández, Fraunhofer IPSI, Germany Jutta Fleschutz, Fraunhofer IPSI, Germany Hugo Fuks, PUC/RJ, Brazil Renee Gedge, Monash University, Australia Steve Poltrock, Boeing, USA Luis Guerrero, Universidad de Chile, Chile Jörg M. Haake, FernUniversität Hagen, Germany H. Ulrich Hoppe, University of Duisburg, Germany Marcelo Milrad, Framkom and Växjö University, Sweden Christine M. Neuwirth, CMU, USA Gary Olson, University of Michigan, USA Jose Alberto Pino, Universidad de Chile, Chile Atul Prakash, University of Michigan, USA Wolfgang Prinz, Fraunhofer FIT, Germany Mike Robinson, University of Jyvaskyla, Finland Manuel Romero-Salcedo, Universidad Nacional Autonoma de Mexico Ana Carolina Salgado, Federal University of Pernambuco, Brazil J. Alfredo Sánchez, Universidad de las Américas-Puebla, Mexico Gerry Stahl, Fraunhofer FIT, Germany Ivan Tomek, Acadia University, Canada Gert-Jan de Vreede, Delft University of Technology, The Netherlands Martin Wessner, Fraunhofer IPSI, Germany Weigang Wang, Fraunhofer IPSI, Germany Conference Chair José A. Pino, Universidad de Chile, Chile

X

Organization

Reviewers Pedro Antunes Beatriz Barros Blanco Karin Becker Marcos Borges Dominique Decouchant Yannis Dimitriadis Henrique Domingos Oswald Drobnik Jesus Favela Alejandro Fernández Jutta Fleschutz Hugo Fuks Renee Gedge Steve Poltrock Luis Guerrero Jörg M. Haake H. Ulrich Hoppe Marcelo Milrad Christine M. Neuwirth Sergio F. Ochoa Gary Olson José Alberto Pino Atul Prakash Wolfgang Prinz Timothy Read Mike Robinson Jessica Rubart Manuel Romero-Salcedo Ana Carolina Salgado J. Alfredo Sánchez Gerry Stahl Ivan Tomek Gert-Jan de Vreede Martin Wessner Weigang Wang

Table of Contents

Groupware and Text Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Christine M. Neuwirth

3

Groupware Goes to School . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gerry Stahl

7

Collaborative Learning in a Web-Accessible Workbench . . . . . . . . . . . . . . . . . 25 J.M. Martins Ferreira, Gustavo R.C. Alves, Ricardo Costa, Nick Hine Document Management in a Computer-Integrated Classroom . . . . . . . . . . . . 35 Nelson Baloian, Alexander Berges, Stephan Buschmann, Katrin Gaßner, Jens Hardings, Heinz Ulrich Hoppe, Wolfram Luther Handheld CSCW in the Meeting Environment . . . . . . . . . . . . . . . . . . . . . . . . . 47 Pedro Antunes, Carlos J. Costa Effect of the Coordination Modes in Supporting Group Multiple Criteria Decision Making in a Distributed and Asynchronous Environment Juan Carlos Leyva L´ opez, Dina Esperanza L´ opez Elizalde

61

A Cooperative Visual Hypermedia Approach to Planning and Conducting Virtual Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Weigang Wang, J¨ org M. Haake, Jessica Rubart Towards UML-G: A UML Profile for Modeling Groupware . . . . . . . . . . . . . . 93 Jessica Rubart, Peter Dawabi Designing the Communications Infrastructure of Groupware Systems . . . . . 114 Sergio F. Ochoa, Luis A. Guerrero, David A. Fuller, Oriel Herrera A Component-Based Architecture to Support Collaborative Application Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Ana Paula Terra Bacelo Blois, Karin Becker Before Getting There: Potential and Actual Collaboration . . . . . . . . . . . . . . . 147 Alberto L. Mor´ an, Jesus Favela, Ana M. Mart´ınez-Enr´ıquez, Dominique Decouchant Intelligent Awareness in Support of Collaborative Virtual Work Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Rosa Alarc´ on, David Fuller The 3-Ontology: A Framework to Place Cooperative Awareness . . . . . . . . . . 189 Edmundo P. Leiva-Lobos, Eliana Covarrubias

XII

Table of Contents

Evaluating Collaborative Learning Processes . . . . . . . . . . . . . . . . . . . . . . . . . . 203 C´esar A. Collazos, Luis A. Guerrero, Jos´e A. Pino, Sergio F. Ochoa The CSCW Lab for Groupware Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Renata Mendes de Araujo, Flavia M. Santoro, Marcos R.S. Borges Tailoring Group Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Alejandro Fern´ andez, J¨ org M. Haake, Adele Goldberg Building Groupwares over Duplicated Object Systems . . . . . . . . . . . . . . . . . . 245 Hechmi Khlifi, Jocelyn Desbiens, Mohamed Cheriet Adaptive and Transparent Data Distribution Support for Synchronous Groupware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Stephan Lukosch COPSE-Web: An Infrastructure for Developing Web-Based Groupware Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Jos´e Maria N. David, Marcos R.S. Borges

Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

Groupware and Text Technologies Christine M. Neuwirth Carnegie Mellon University Pittsburgh, PA 15213 USA [email protected]

Abstract. In this talk, I will outline the history of text technologies and the ways in which they have supported groups working across time and place and changed work practices. I will focus on the rise of annotation practices and its importance to reading and writing processes, and review new technologies that are likely to change the ways in which annotation can enhance and will alter traditional reading and writing practices, both in collaborative writing and in cooperative learning to write. I will raise some directions for future research, including how professionals read and annotate, how readers might make use of annotations produced by others, and how interfaces to annotations are likely to affect communication and collaboration. I will identify outstanding research issues, research methods that are likely to be productive in furthering our theories of workplace and classroom communication, and draw implications for the design of annotation technologies in groupware.

Speaker Biography. Dr, Christine Neuwirth is Professor of English and Human-Computer Interaction at Carnegie Mellon University. In 1986, she received her Ph.D. degree from Carnegie Mellon and, at the same, time, she became a member of its faculty. Her research has focused on designing computer tools for computer-mediated communication as well as conducting empirical research that explores the effects of those tools. Early work focused on building a conceptual framework for understanding collaborative writing, coupled with the development of a "work in preparation" (PREP) Editor to study collaborative writing relationships, especially collaboration at a distance. The PREP Editor implemented an innovative "column" architecture and served as a "proof of concept" for many of the design requirements that were identified from the theoretical and empirical work. Her latest work involves exploring "authorable" visualizations as a way to mitigate or reduce attention and overload problems in electronic mail. Dr. Neuwirth is a member of the Association of Computing Machinery and has served on various advisory panels and conference program committees.

J.M. Haake and J.A. Pino (Eds.): CRIWG 2002, LNCS 2440, p. 3, 2002. © Springer-Verlag Berlin Heidelberg 2002

Groupware Goes to School Gerry Stahl Drexel University (Philadelphia, USA) & Fraunhofer-FIT (Bonn, Germany) [email protected]

Abstract. Groupware for cooperative work (CSCW) and for collaborative learning (CSCL) have many important commonalities as well as different requirements. By transforming a generic CSCW platform into an environment to support a particular vision of education as collaborative knowledge building, we saw how functionality had to be adopted, transformed and refined to meet the specific educational social setting. By “taking groupware to school,” we discovered the need to extend the original system into a CSCL application that could facilitate collaborative learning, knowledge building, perspective intertwining, knowledge negotiation, portfolio sharing and knowledge artifacts in active, structured virtual learning places. In the paper, we describe the resulting system and reflect on issues of design and implementation that differentiate our CSCL approach from its closely related CSCW basis. Keywords. CSCL, educational groupware, knowledge negotiation, collaborative knowledge building

1 From CSCW to CSCL With widespread use of the Internet, groupware promises to provide the kind of support to networked groups that individual productivity software like word processors and spreadsheets grant individuals. The potential of computer support for groups is perhaps even higher than that for individuals because communication within groups has until now suffered from severe constraints that may be eased by computer support. The question must still be addressed as to what groupware should aim at beyond the reproduction of pre-computer forms of group interaction. We need a vision of how networked computers can facilitate the discussion of all with all that does not require the coordination of a manager or teacher and the collaborative building of knowledge that is not restricted to the skills, memories and efforts of individuals. Perhaps CSCL can provide a model for this. When we take groupware into the schools in a principled and explorative way we may see how computer support can be designed to transform teacher-centric learning into collaborative learning and transcend knowledge management with knowledge building. Academically, the exploration of groupware has historically been split into two separate domains: CSCW and CSCL, which address issues of computer support for cooperative work and collaborative learning, respectively. Each domain has its own conferences, journals and adherents. CRIWG is one of the few places that these come J.M. Haake and J.A. Pino (Eds.): CRIWG 2002, LNCS 2440, pp. 7–24, 2002. © Springer-Verlag Berlin Heidelberg 2002

8

G. Stahl

together. This distinction has not been based on a conceptual analysis that might motivate and justify such a division. Certainly, the two domains have at least sufficient commonalities that they can borrow extensively from one another. Why should CSCW and CSCL be distinguished? There is at least a superficial rationale for this. CSCW is concerned with the world of work, where people must accomplish commercially productive tasks, while CSCL is concerned with the world of schooling, where students must learn basic skills that will in the end allow them to function effectively in the world of work and in adult society generally. These are very different social contexts. Perhaps the clearest lesson of groupware research to date has been the importance of taking into account the social context – the motivations, prevailing practices, political constraints – in which software is to be used. By this criteria, the two domains are indeed distinct and should be treated so. However, it is also true that in today’s “knowledge society” work is often knowledge work that requires constant learning [4, 21]. In the interesting cases, work – whether individual or cooperative – is not the repetitive carrying out of well-known tasks that were learned once and for all in school, but work itself centrally involves various learning tasks. Work may require just-in-time learning, where existing information must be found to solve a current problem. Or it may involve inquiry learning, where solving a wicked, ill-structured or non-routine problem requires the building of new knowledge. Similarly, the learning that is needed to prepare students for an effective role in tomorrow’s knowledge society cannot consist merely of the transfer of existing knowledge into passively receptive minds, but must guide the students to develop personal and social skills that will allow them to find information relevant to unanticipated problems and to engage in inquiry processes. In this sense, the application domains of CSCW and CSCL are closely related; it is not just a matter of both having to support activities of groups. This paper reports on the results of trying to extend a basic CSCW system for a typical CSCL application. We started with BSCW, a well-known and widely used groupware system [1, 2, 8]. Used by over 200,000 people since 1995 when it was developed at the Institute for Applied Information Technology – FIT (previously a GMD Institute, now a Fraunhofer Institute near Bonn, Germany), BSCW provides a system of autonomously managed Web-based workspaces that can be used by members of a workgroup to organize and coordinate their work. These workspaces are central access points for shared documents, including folders for organizing them and a wealth of functionality for knowledge management. Although BSCW has been used in many classrooms, especially at universities in Europe, it is clearly a CSCW application. We wanted to adapt it specifically for the social setting of schools: to see what it would mean to transform it into a CSCL application. We undertook this within a European Union project named ITCOLE (Innovative Technology for Collaborative Learning and Knowledge Building) [10]. With its emphasis on collaborative knowledge building, this project aims primarily at supporting group discourse. It differs from many other educational approaches, that strive to convey information in the form of curriculum content or videotaped lectures, which can perhaps be done with a CSCW system. In ITCOLE, we assume that students can find information on the Internet or in documents uploaded into the system, and that what needs CSCL support is: œ the collaborative reflection on this information (sharing and annotating), œ the building of group knowledge (discussion from perspectives) and

Groupware Goes to School

œ

9

the determination of what is to count as produced knowledge artifacts (knowledge negotiation).

The focus of the ITCOLE Project differs from that of BSCW, which is on the archiving and sharing of existing knowledge artifacts. Thus, while we wanted to take advantage of important forms of CSCW support like knowledge sharing and social awareness, we also wanted to go beyond the management of established knowledge to the creation of knowledge that is innovative within a learning community that develops, defines, sanctions and shares its knowledge. This paper reports on how we designed a CSCL system by transforming a CSCW system. It begins with a scenario (section 2), illustrating the vision of how our new system, called Synergeia, might be used to facilitate collaborative knowledge building in a typical collaborative classroom. The system is named Synergeia in recognition that the whole can be much more than the sum of its parts. Thus, the system strives to support the synergistic construction of knowledge at the group level that is quite distinct from what any of the students could produce on their own. The scenario anticipates the pedagogical concepts that are then presented in the next section (section 3). For instance, the “folders” of BSCW are referred to as “virtual learning places” because the metaphor is no longer one of passive storage containers, but of locations within which active knowledge building is supported. The functionality associated with the pedagogical concepts is described with the respective concepts. Other Synergeia functionality for students, teachers, administrators and researchers is then summarized (section 4). Following a brief discussion of the system infrastructure (section 5), reflections on the attempt to adapt CSCW to CSCL are presented (section 6). The Synergeia groupware is already going to school. Teachers and students in Italy, Greece, the Netherlands and Finland have begun to use an initial version within the ITCOLE Project. An additional 50 classrooms in these countries will use the revised version described in this paper during the Fall. The revisions are based on early feedback from pedagogic researchers, teachers and students to the initial version, which was itself based on extensive experience with related systems in both CSCW and CSCL contexts.

2 Scenario of CSCL Support Synergeia is designed to support collaborative knowledge building. However, it must also be flexible enough that teachers in various countries can use it for a broad spectrum of educational approaches. The scenario illustrates what might be called the “default usage” of Synergeia. This means that Synergeia was designed to make it especially easy for teachers to set Synergeia up for structuring knowledge building this way, although other ways of using it are also supported. Meet Carla, a student in a course on The Human Brain. Her teacher has enrolled her in the course and assigned her to a workgroup on the role of Vision. When Carla first logs in, she can see a folder for her course on “The Human Brain.” In addition, there is a “personal knowledge building perspective” for her to jot down her own ideas.

10

G. Stahl

Carla clicks on her course to view its contents. She sees a folder for her project group within that course called “The Vision Team.” She notices in the size column that there are already some items in the group learning place, so she clicks on “Group: The Vision Team” and goes there (see Figure 1). Carla works with the other students in her project team to collect websites and other documents about how vision works as part of the human brain. As they collect new information, the team members discuss what they have found and begin to build theories about vision in the group knowledge building perspective (see Figure 2). This discussion motivates them to do more Web searches and to try to answer questions that they pose to each other. Gradually, they converge on an understanding of their topic and put together a portfolio of what they have learned, to share with the other members of the course. As they begin to explore the physiology of vision, different students come upon different explanations. Some find discussions of vision in terms of light dynamics, lenses and the stimulation of the retinal sensors; others read about chemical reactions in the sensors and nerve connections; while others discover presentations involving electrical charges in neurons. As these different findings come together in the group knowledge building perspective, the concepts and claims in the notes interact. Efforts to question one another and to synthesize multiple notes raise new questions, hypotheses and insights. Carla is a shy girl who does not normally participate much in face-to-face class discussions. She is afraid that her ideas are not very good and she hesitates to share them until she has had time to think about them and to compare them with other ideas or to check them out by collecting more information. So when she sees an interesting idea in the group learning place, she often copies it into her personal perspective and works on it there, where no one else will see it right away. During the week, her

Fig. 1. The Group learning place. Here is where collaboration takes place. Documents, websites and other forms of information are collected, shared, organized, analyzed and critiqued.

Groupware Goes to School

11

Fig. 2. The group knowledge building area. This area provides an overview of the discussion within a group and offers an interface for engaging in the knowledge building process. personal area fills with the results of new web searches, documents she has collected or edited, notes that she has copied from the group area, and ideas she has jotted down in her own knowledge building area. When she is happy with some of her ideas, she copies them and related documents into the group area to see what her team mates will say about it. Now she has some confidence that her ideas are thought through and can stand up to inspection by others. Even if her suggestions are not adopted unchanged in the end, they will be taken into the group discourse as serious contributions. At some point in the collaborative knowledge building process, Carla thinks that the group members have something almost ready to present to the course as a “knowledge artifact” or part of their team “knowledge portfolio.” So she puts this information together in a folder named “Good documents we found about vision” and makes a proposal to share this with the course. Now the group area contains a proposal folder named “The Vision Team’s proposal 1” (see Figure 1). In addition to the folder named “Good documents we found about vision,” this proposal folder contains a voting interface and a knowledge building area for discussing what changes are needed before the group members are ready to agree to send this folder to the course learning place as their “knowledge portfolio.” Once the team has decided to send their portfolio to the course learning area, it can be discussed by everyone in the course and evaluated by the teacher as a product of the group’s knowledge building effort. This might be the end of a curriculum unit, or it might lead to further inquiry and knowledge building. The same groups might continue to work together or the teacher and students might create new groups in new learning places. Our scenario ends here, but the learning continues.

12

G. Stahl

3 Pedagogical Requirements for Synergeia The adaptation of BSCW for school classrooms involves responding to a particular pedagogical vision, and providing support for the particulars of that vision. To understand the difference that the CSCL setting makes to system design, one must understand the pedagogical concepts that drive the adaptation. The central concepts of collaborative knowledge building are presented in the current section, along with a description of the support implemented for them in Synergeia. Note that although Synergeia is most useful and powerful if used to support what is here called “collaborative knowledge building,” the system has been designed to be flexible so that teachers with different curricular goals and pedagogical approaches can adjust it to their needs. The design process tried to incorporate the following influences: œ Adoption of pedagogical principles of collaborative knowledge building and progressive inquiry. œ Incorporation of effective functionality from related CSCL and CSCW systems, both commercial and research. œ Adaptation to the social settings of constructivist European classrooms. œ Support for social practices involved in collaborative learning such as that described in the preceding scenario. œ Flexibility for teachers in different countries and pedagogical cultures to adapt the system to their varying approaches. 3.1

Collaborative Knowledge Building

The design of Synergeia is guided by an educational approach that stresses the construction of knowledge within a community of learners, typically including students and more experienced teachers. The idea is that new knowledge will be created through the investigations and discourse of the group. While there are important roles for individual student thinking as well as for teacher guidance, there is also emphasis on sharing, critiquing and building upon each others’ ideas to arrive at deeper knowledge of a topic within a learning community [3, 13]. “Group learning” is to be understood here in an emphatic sense: it is the group that learns, knowledge is constructed by the group itself. Whereas CSCW supports the sharing and archiving of knowledge that is contributed by cooperating individuals, CSCL supports the functioning of a collaborative group so as to build knowledge that is the shared creation and property of the group. Primarily, group knowledge arises in discourse and is preserved in linguistic artifacts, whose meaning is interpreted within group processes [15, 16]. Because knowledge building proceeds largely through discussion, each personal, group and course perspective automatically contains its own knowledge building area in Synergeia. These knowledge building areas have extended the basic threaded discussion facility of BSCW. While threaded discussion support is derived from CSCW, it requires more nuanced and specialized support in CSCL. Notes from one perspective can now be copied to other virtual learning places in other perspectives,

Groupware Goes to School

13

and notes from elsewhere can be pasted here. Notes in these areas are now included in system searches, because they form an important part of the knowledge in the system. The user interface of the threaded discussion areas in Synergeia has been carefully designed to encourage thoughtful, focused, deep knowledge building. Below the current note is a display of all other notes entered in the same knowledge building area. The notes can be displayed as indented threads, indicating which notes reply to which other notes. Alternatively, the notes can be sorted by author, date or thinking type. Sorting by author shows quickly who is contributing the most; by date shows the order in which ideas were written; by thinking type indicates which parts of the knowledge building process have or have not been emphasized so far. In each of the sorted displays, the display of the content of the notes can be toggled on and off so that one can see either just the list of the notes or the full content of the whole discussion. This is useful so that one can quickly get an overview of the structure of complex discussions or see the full content of brief discussions. As seen in Figure 2, the note that is currently being read is at the top of the screen. With it are a number of buttons for building further knowledge, such as adding a “Reply to this Note.” The background color of this part of the display corresponds to the note’s thinking type. The different thinking types are described on a help page reached with the “Thinking Type Descriptions” button; the corresponding background colors can be seen there. 3.2

Thinking Types

It is important for students to reflect upon the role that a note they are entering will play in the knowledge building process. Both note titles and categories should be chosen carefully [5]. Discussion within the knowledge building areas is scaffolded with a set of thinking type categories for the notes. Before someone can enter a note, they have to decide what category of note they want to add to the existing discussion. For instance, do they want to state the problem that is to be pursued, propose a working theory, deepen the knowledge that is already there, or make a meta-comment about the knowledge building process that is taking place? It is possible to have different sets of thinking types for different approaches to knowledge building. For instance, the preceding examples illustrate categories of inquiry learning notes. Other categories are appropriate for brainstorming, debate, design rationale, etc. Thinking types take on a much more important role in Synergeia than in BSCW, where they were limited and rarely used. 3.3

Virtual Learning Places

The most basic function that Synergeia offers is a set of workspaces on the Internet where people can share ideas, documents, web links and other objects. Whether people using Synergeia are in the same room during the same class period or they are in different countries working at different times, they can share their work and collaborate within these virtual learning places. Teachers and students can create new places whenever they want for any special needs they have. Places can be created to store new collections of documents. Synergeia offers several special kinds of learning

14

G. Stahl

places, such as Courses, Groups, Proposals and Knowledge Building areas that have special features. Although these virtual learning places are based upon BSCW folders for storing documents where they can be accessed by other group members, these places are structured to support specific collaborative knowledge building activities like negotiation of group knowledge. The CSCW workspaces are appropriated and specialized to support a variety of CSCL activities. A major advantage of Synergeia over threaded discussion systems in commercial groupware systems is that the discussions in Synergeia are separated into personal, group and course perspectives in different virtual learning places, so that different topics are not mixed together and it is easier to keep up with relevant discussions without being overwhelmed by contributions of many other people who are investigating other issues. The same is true of the documents, web links, etc. that are collected in the various learning places. It is important that the network of learning places be structured in a way that seems natural to the students using them. The basic structure of learning places follows the normal structure of schools, with students in projects within courses. It should be easy to see what is available and relevant, and to navigate to it easily. Therefore, when a student logs in that student’s personal learning place is displayed; the personal place includes a list of the student’s courses and the course learning place includes the student’s groups. It should also be easy to copy documents and ideas from one place to another. At the same time, because these places are generally shared, it is also important to protect the contents so that one person cannot change or delete someone else’s work arbitrarily – as can occur in BSCW. By default, Synergeia defines appropriate connections between places and reasonable access rights to them when people are registered for courses and groups. Each user, group and course automatically has its own knowledge building area – additional areas can be added or the automatic ones can be deleted. Also, plain places that do not have the special characteristics of groups and courses can easily be added. Thus, the structures, navigation paths, access rights and facilities within Synergeia are designed for usage within the social practices prevailing in school settings, with adequate flexibility to allow for broad variations within these settings. 3.4

Perspectives

The approach to building knowledge in Synergeia is based on the idea of intertwining personal and group perspectives [17]. All knowledge involves interpretation from specific perspectives [12, 14]. In collaboration, personal interpretations of what is said in group discourse interact to form shared understandings. [16] The default structure of Synergeia provides a network of virtual learning places that are set up for personal, group and course uses. These perspectives support a range of pedagogical models that are favored in the different countries participating in the ITCOLE Project: œ Community of learners (Italy). The areas in which work, communication and learning take place are structured to reflect the structure of the community, with its sub-groups and members.

Groupware Goes to School

15

œ

Progressive inquiry (Finland). The inquiry process progresses through collaborative discourse within groups as well as through reflection by individuals. œ Conceptual change (Greece). Learning is treated as a social process in which the understanding of individuals is affected by and grounded in the discourse of the community. œ Shared and individual regulation process (Netherlands). The intertwining of shared group and personal individual ideas leads to new understandings at all levels. Thus, there are private personal learning places where only one person can add notes, documents or sub-folders and can come back and look at these, modify them, or copy them to a group place. These are places to develop your personal perspective on a topic without worrying what other people will think about what you are doing. Because your personal ideas and documents are in Synergeia, they can be easily related to ideas in other learning places. Allowing the system for group work to be used for personal reflection as well has two major advantages. First, it encourages system use and familiarity. A major problem with groupware systems can be that they require users to log in every day to see what it new there; if people do not use the system for their normal activities then they tend not to log in frequently enough. Also, if people have to use too many different systems for their work then it is difficult to become proficient in them all. Second, by conducting both personal and group work in the same system, people can easily move ideas and documents back and forth between the two. In particular, Synergeia is designed to allow quick cut and paste of items and sets of items from any visible learning place to any other. Then there are the group learning places where most of the collaboration and knowledge building gets done. Here everything is shared with the other members of the team or work group. Students who are not in the group cannot modify or comment on work in the group until the group decides to share something with the whole course. Knowledge usually emerges from a group perspective [15]. And there are also course learning places, where all the smaller work groups or project teams within the course contribute the knowledge they have built up. For instance, a teacher who has a course with 30 students might divide them into 6 or 7 teams. Perhaps each team would develop a portfolio to present their ideas to the course. Each team might have the same task or they might divide up different aspects of the larger course topic. After they develop their group portfolios, they can share and debate within the whole course perspective. While CSCW systems provide support within a generic group, a CSCL system should support various levels from individual to large group, with fluid navigation and transfer of contents among the levels. 3.5

Negotiating Knowledge Artifact Portfolios

Sometimes it is pedagogically important for groups to negotiate the promotion of knowledge from one perspective to another, such as the decision to make products of a group available to the larger course. A teacher can set up course learning places so that the only way that new documents, maps and folders can be added is by a group developing a knowledge portfolio or knowledge artifact in their group learning place

16

G. Stahl

and then deciding to move this into the course place. Making this kind of group decision is called knowledge negotiation in Synergeia. There is a negotiation mechanism to help a group reach this decision and move the knowledge they have created into the course learning place, where it can be shared and discussed by all members of the course. By specifying the negotiation option for a course, the teacher in effect declares that the only knowledge allowed in this learning place is knowledge created by groups. In CSCW negotiation, such as Herrmann’s or Wulf’s model [7, 17, 20], commenting on one’s voting serves the purpose of expressing one’s supposedly preexisting opinion. In Synergeia, engaging in negotiation of knowledge building is participating in a group reflection on shared knowledge. This can be seen in the thinking types of the notes contributed. In CSCW the note format stresses who the author is and may characterize the notes as a “pro” or “con” opinion (as even in BSCW); in Synergeia the note must first of all be determined to be a particular aspect of the knowledge building process, such as a problem statement, a working theory or a summary statement. Knowledge negotiation is thereby explicitly structured as a collaborative group effort, where notes written by individuals must fit into the group process and are categorized by their function in the group thinking, not the individual. Negotiation in a knowledge building context is essentially different from that in a knowledge management or group decision situation [18]. In other groupware settings, negotiation is conceived of as a straw vote to determine how people’s pre-existing opinions are distributed on alternative options that have been proposed [7, 9, 20]. In a collaborative knowledge building setting, however, it is a matter of further refining the proposed knowledge artifact. Voting serves just to signify that the participants are generally satisfied that the artifact represents their group knowledge, and can it can be shared at the course level as a knowledge portfolio contributed by their group. The important part of the negotiation process is the evolution of the knowledge itself in parallel with the group discourse about it. When members of a group learning place have built a knowledge artifact – such as a collection of websites, a PowerPoint slide presentation, a concept map, or a portfolio of texts and pictures – they can decide to copy it to their course learning space to share with members of other groups in their course. This result of their collaborative work as a group may be a final product that the teacher will evaluate or it may be an intermediate product that they want to share and get feedback on from other people. If a course has been defined to require negotiation, then students in that course must go through a formal negotiation procedure to copy a proposed knowledge artifact portfolio to the course learning space. The purpose of this is to ensure that all or most people in the group agree to have the proposed portfolio represent the knowledge that the group has built together. (If negotiation is not required in the course, anyone can simply copy an item from the group place into the course learning place.) To use the negotiation procedure, a student must select items for their portfolio and execute the “Negotiate” command. This will create a portfolio proposal in the group place. The portfolio proposal interface includes a voting area that allows group members to vote on submitting the portfolio when they are happy with it. Within the portfolio are:

Groupware Goes to School

17

1. 2.

the selected portfolio knowledge artifacts, and a negotiation knowledge building area for discussing changes that should be made to the proposed portfolio. Students use the negotiation knowledge building area to negotiate changes that they think should be made within the portfolio. They make changes in the portfolio that they think will make it acceptable to all or most people in their group. When they like the way the portfolio looks, they vote to approve it. Each person who submits an approval or disapproval vote must enter a statement justifying their vote; this statement is automatically incorporated into the negotiation knowledge building area where it is included in the negotiation discourse and can be discussed. When all or most of the people in the group have voted for the portfolio, it is automatically copied to the course learning place. The negotiation knowledge building area is copied with the portfolio folder so that members of the course can see what was said about the portfolio. Students may want to make summary comments in this area to say what they think is important in the portfolio. If they still have criticisms of the portfolio or if they would like course members to discuss certain ideas about it, they can put that in the area as well. 3.6

Concept Maps

In building knowledge, it is often useful for a group to discuss how the concepts they are using are related to each other. One method for doing that is for the group to construct a concept map which diagrams these relationships. Synergeia provides a whiteboard called MapTool for people to work together simultaneously to sketch a concept map. The whiteboard is accompanied by a chat window to support coordination of this task and interpretation of the symbols in the map. Students and teachers can open the MapTool in course and group learning places and in proposal portfolios. To work with other members of a proposed portfolio, work group or course, they go to the learning place for that portfolio, group or course. At the top of the screen is a list of all members of the place. Those who are currently logged in to Synergeia have their names shown in bold; if they are active in MapTool, their name is in red. This is a form of social awareness which has been added to BSCW; it lets people know who is involved in MapTool in this learning place. Each proposed portfolio, group and course learning place has its own version of MapTool. When a MapTool session is first started, the last map is automatically opened so that work on it can be continued if desired. You can also reset the MapTool to start with a blank whiteboard. When other members join an active MapTool session, they see the current state of the whiteboard and the chat window, so they can catch up on what has already been done in there. At any time, the current state of the work in MapTool can be saved. Then a student can go into the learning space and make a copy of this map. The saved map can be opened as a JPEG graphics file. The student can save this file in a Word document, a PowerPoint slide show, a larger graphic file or simply as a JPEG file in a sub-folder. This way, collaborative work in MapTool can be documented as part of a report or knowledge portfolio.

18

3.7

G. Stahl

Roles and Personalization

Synergeia defines roles for students, teachers, guests, mentors, etc. This gives people in these roles the power to execute certain menu functions, such as to read, edit or delete objects in a learning place. When someone is invited into or registered for a particular learning place (such as a course or group) they are invited or registered as a member with a specific role (such as student). It is possible to change a user’s role, to define new roles and to add new sub-folders where the user has a different role. Whereas roles in BSCW were generic and rarely used, in Synergeia they capture important distinctions between people based on power and knowledge in school settings. These roles must be adapted to different kinds of learning spaces. For youthful users, it is important to make software more fun to use. Personalization and customization facilities allow users to adapt the system to their own preferences and to feel that the systems is “theirs.” Synergeia users can personalize the user interface by including a picture of themselves in the upper lefthand corner of the screen next to their username. This picture will represent them at other places in the Synergeia interface as well, such as when knowledge building notes are sorted by author. There are many functions for customizing the Synergeia interface. A student can: œ specify which columns to display for details related to sub-folders and documents. œ change the size of the displayed text. œ sort the listed sub-folders and documents in different orders. œ toggle on and off the display of menu shortcut icons below the main menu. œ toggle the descriptions below the names of sub-folders and documents. œ toggle the contents below the titles of knowledge building notes. Students can set a variety of details about how the Synergeia system will work for them. They can: œ change their password. œ set the location for their picture. œ enter their email address or home page. œ set their system preferences. Students are automatically considered “beginners” as users of Synergeia. This means that the menus they see are not full of options that are intended for more experienced users. They can change to “Advanced” or “Expert” status when they feel ready to access more menu items. For younger students in primary school, a new “primary” profile has been defined; it makes the interface simpler by removing many menu items and shortcuts to make student usage simpler.

4 Additional Functionality in Synergeia Section 3 described the pedagogical requirements for Synergeia that distinguish it from related work. Synergeia is focused on the needs of small collaborative groups of students, guided by teachers who structure and facilitate their interactions. By contrast, most commercial systems are oriented to administrative concerns such as

Groupware Goes to School

19

delivering pre-defined content, tracking attendance and test results, handling homework assignments and conducting student evaluation. At best, systems like LearningSpace and WebCT provide basic CSCW functionality for sharing documents and communicating. Because systems like Lotus Notes or Blackboard cater to corporate and professional training applications, they provide generic discussion forums, without specialized thinking types or workgroup perspectives structured in response to classroom cultures. Alternative approaches like Swiki [6] systems also lack the tailoring to classroom needs due to the generality of their functionality. At the other extreme are CSCL systems that are more specialized for particular pedagogies, like the STEP system to support problem-based learning [19]. CISLE/ KnowledgeForum [13] is very similar to Synergeia – because its developers began the tradition in which the ITCOLE Project is firmly planted. Synergeia also incorporated features from FLE [11] and WebGuide [17], research prototypes that led to its conception and prototyped much of the functionality incorporated in it. Synergeia is unique in combining the features of perspectives, multiple thinking type sets and negotiation with threaded discussion to support collaborative knowledge building. It also features a rare integration of synchronous and asynchronous support. In addition to the pedagogically motivated features, Synergeia provides a wealth of functions from BSCW. Some of these have been modified or extended to allow students, teachers, administrators and researchers to take advantage of the core Synergeia functionality. Student actions have been modified to simplify the uploading of the user’s picture; uploading, archiving and versioning of documents, images and websites is already well supported by the inherited BSCW commands. Likewise, the ability to search the Web, review hits, rate URLs and store shared bookmarks was already available. Students can set up new virtual learning places and invite friends to them, as well as starting new knowledge building areas and initiating MapTool sessions. Social awareness is well supported with BSCW’s info, events and history systems. In addition, Synergeia added displays of the names of course and group members, with indications of who is currently active in Synergeia or MapTool. Considerable support for teachers has been added. Teachers can register lists of students in the system and assign them to courses and workgroups easily. Students no longer have to have their own email addresses in order to be registered. Teachers can define course and group learning places, with a number of options for negotiation and access; this gives teachers considerable control in structuring the use of Synergeia. They can, of course, seed a learning place with documents and a knowledge building area with starting questions for discussion. When a new knowledge building area is created, the teacher can select which set of thinking type categories will be used: “knowledge building,” “scientific theory,” “negotiation,” “debate,” “discussion” or “brainstorming.” Teachers can revise the parameters for negotiation, such as the percentage needed for a majority vote. They can also over-ride the voting process to move proposals from group to course places – or even in the opposite direction. Although Synergeia is currently run on a central server in Germany, it can be downloaded to local sites to overcome Internet delays in schools with slow connections. The system administrator registers an initial set of teachers and researchers to use Synergeia. The administrator can also translate all terminology in the interface, including the sets of thinking type categories, as well as re-define the actions associated with various user roles. The entire Synergeia interface has been

20

G. Stahl

translated into Italian, Greek, Dutch and Finnish from the English original. Administrators can modify the translation files. Users select the language they want – by default it corresponds to their browser language setting. In addition, functionality has been added to assist researchers who want to analyze the usage of Synergeia. There are now log files that track all actions in BSCL, the contents of all knowledge building areas and all actions in MapTool. The log files can be analyzed with special tools or copied into a spreadsheet. Knowledge building areas can be printed out in various formats.

5 The Synergeia Architecture The present section briefly indicates how the technological infrastructure of BSCW was extended in response to the needs of the classroom setting. Technically, Synergeia consists of the following three components: BSCW. This is the Basic Support for Cooperative Work system. It is a Web-based system designed to support teams of adult professionals working together and sharing documents. It provides mechanisms for uploading, downloading, versioning and archiving of many kinds of documents. It also supports Web searches, annotations and ranking. BSCW is written in Python as an object-oriented set of cgi scripts. It includes a persistent store for objects. The server runs in Windows or Unix and the client can be displayed in any Web browser. Interestingly, the BSCW technology is literally a technology of extensibility; the cgi scripts extend the functionality of a core webserver like Apache or IIS by means of standard HTTP calls. This makes BSCW an attractive basis for further, open-ended extensions. BSCL. This is the set of functions and interfaces that adapts the BSCW software to collaborative knowledge building in K-12 classrooms. It includes the functions to create personal, group and course learning places and to register users in these with specific roles. It also includes the knowledge building interface, sets of thinking types and support for negotiation. BSCL is implemented as a Python Package that extends BSCW and that interfaces with MapTool. Packages are a flexible technology for modular extensibility in object-oriented languages like Python. BSCL is one of several packages that extend BSCW and it is possible to create new packages that extend BSCL itself. MapTool. This is a collaborative whiteboard that students in a group or course can work on simultaneously (synchronously) to construct concept maps and other simple diagrams. It includes a chat window for coordinating and discussing the drawing. The maps are stored in BSCL learning places. Synchronous support for the MapTool Java applet client is provided by the Ants system, using the Elvin server. The inclusion of MapTool in the Synergeia system is an experiment in extending BSCW with synchronous components, where user information, drawings and chat data must be stored in and retrieved from BSCL’s database by MapTool.

Groupware Goes to School

21

6 What Groupware Can Learn by Going to School Much has already been learned about the differences and similarities of CSCW and CSCL groupware support through the process of designing and implementing Synergeia. The school setting has special characteristics that make certain functionality particularly important and that require specific transformations of other functions. Many such adaptations and extensions have been illustrated in the preceding sections of this paper. One unanticipated technical finding was the importance of mechanisms for setting specific access rights for various kinds of folders. A new version of BSCW (4.0) that was released during the beginning of the ITCOLE Project included mechanisms for defining roles. These mechanisms – which to date have only been explored in the development of Synergeia – proved particularly helpful. From an implementation standpoint, many extensions to BSCW for Synergeia are largely accomplished through the definition of special domain-specific roles, with specific access rights within various kinds of learning places. A straight-forward application of the role mechanism was to define roles for teachers, mentors, students and guests. New users are registered in Synergeia with one of these roles. The role determines what actions the user can undertake within his or her personal learning place. For instance, a user who is registered as a teacher may create courses and groups or redefine negotiation parameters; a student user may upload documents; and a guest may only view contents in Synergeia. A teacher has special powers to delete offensive materials, and so on. A mentor also has many of these powers that students do not have, but does not have the ability to create courses and groups. Users have more control over objects that they created than over other objects, such as the ability to edit or delete them. A user can invite other users to folders and can reset or modify roles, but can never assign abilities that exceed that user’s existing abilities. In addition to the standard roles, special roles were defined for “course mates” and “restricted students.” These are used for special circumstances. For instance, course mates can see in their course learning places what groups exist that they do not belong to. Depending on the option set by the teacher when the group was defined, users who had student roles are re-assigned “course mate” roles, where they are able to see the name of the group listed, or else they are re-assigned the “restricted student” role, where they may enter the group learning place and view or copy – but not add to or modify – the content there. Similarly, in a course where the negotiation option was selected, all student users are re-assigned the role of restricted student. This means that they can see and copy all content, but cannot add or modify anything (except through the group negotiation procedure). This re-assigned role is inherited down into all sub-folders and sub-subfolders, etc. (as is usual for roles). This automatically prevents students in a course from changing the contents of negotiated portfolios from groups, although they can view these contents and copy them elsewhere to work further on them. In a course knowledge building area, the restricted student roles are changed back to normal student roles, so that students can participate in knowledge building discussions within the course perspective. The school setting requires much more complex control over access rights than is instituted in the normal BSCW system. The role mechanism provides a convenient,

22

G. Stahl

flexible and elegant means for defining and instituting the needed sets of access controls. This paper reflects the design of version 2 of Synergeia, which will be released to European elementary and secondary schools within the ITCOLE Project in summer 2002. It has already benefited substantially from informal feedback from the review of version 1 by pedagogic partners in the Project and from the use of version 1 by teachers and students in the winter and spring 2002. The use of version 1 is currently being subjected to extensive evaluation in each of the participating countries. It is expected that this will reveal additional groupware requirements of the school setting. Version 2 of Synergeia will “go to school” in 50 courses in Italy, Greece, the Netherlands and Finland during the fall of 2002. This will again be subjected to formal evaluation using a variety of survey instruments. Data from the log files and classroom observations will be analyzed with a mix of quantitative and qualitative methods. Results of these evaluations should provide important insight into the effectiveness of the Synergeia adaptations and extensions to groupware mechanisms presented in this paper. There are many fundamental commonalities between CSCW and CSCL groupware requirements and the two can build upon each other’s accomplishments. However, the school setting, seen from a specific pedagogical perspective, brings with it considerations that call for particular treatments. In the case of the development of Synergeia within the ITCOLE Project, we have seen that it was necessary to develop a suite of functionality that adapted generic CSCW forms of support to define a unique educational environment. It is likely that as the CSCL extensions mature through testing and usage they will feed back into suggestions for CSCW itself.

Acknowledgements. The ITCOLE Project is a collaboration of many people from universities and schools throughout Europe. The project was conceived largely by people in the Centre for Research in Networked Learning and Knowledge Building at the University of Helsinki and in the Media Lab at the University of Art and Design Helsinki. Much of the Synergeia user interface was designed by the Media Lab group. MapTool was implemented at the University of Murcia. The project manager for ITCOLE at FIT is Wolfgang Appelt. The implementation of most of the features described in this paper was done by the BSCW group at Fraunhofer—FIT, especially by Rudolf Ruland and me. To carry out the adaptation of a complex system like BSCW in a way that takes advantages of the strengths of its design and does not contradict its philosophy would not be possible without detailed guidance from the BSCW development staff, including Thomas Koch, Elke Hinrichs and Gerd Woetzel, in addition to Rudolf. I am grateful to all the people at FIT who made my year there possible, productive and enjoyable. A number of anonymous CRIWG reviewers made suggestions that significantly improved the presentation of this paper.

Groupware Goes to School

23

References 1. 2.

3. 4. 5.

6. 7.

8.

9.

10.

11. 12. 13. 14.

15.

Appelt, W. (1999) WWW-based collaboration with the BSCW system, In: Proceedings of SOFSEM ’99, Springer Lecture Notes in Computer Science 1725, Milovy, Czech Republic, pp. 66–78. Appelt, W. & Klöckner, K. (1999) Flexible workgroup cooperation based on shared workspaces, In: Proceedings of World Multiconference on Systems, Cybernetics and Informatics: SCI ’99 and ISAS ’99 (5th International Conference on Information Systems Analysis and Synthesis), Orlando, FL, pp. 34–39. Bereiter, C. (2002) Education and Mind in the Knowledge Age, Lawrence Erlbaum Associates, Hillsdale, NJ. Brown, J. S. & Duguid, P. (1991) Organizational learning and communities-of-practice: Toward a unified view of working, learning, and innovation, Organization Science, 2 (1), pp. 40–57. Gerosa, M., Fuks, H., & de Lucena, C. (2001) Use of categorization and structuring of messages in order to organize the discussion and reduce information overload in asynchronous textual communication tools, In: Proceedings of CRIWG 2001, Darmstadt, Germany. Guzdial, M. & Turns, J. (2000) Sustaining discussion through a computer-mediated anchored discussion forum, Journal of the Learning Sciences . Herrmann, T., Wulf, V., & Hartmann, A. (1996) Requirements for a human-centered design of groupware. In D. Shapiro, M. Tauber, & R. Traunmüller (Eds.), Design of Computer Supported Cooperative Work and Groupware Systems, Elsevier, Amsterdam, NL. Klöckner, K. (2001) Preparing the next generation of learning: Enhancing learning opportunities by Web-based cooperation, In: Proceedings of 10th European Distance Education Network (EDEN) Anniversary Conference 2001, Stockholm, Sweden, pp. 330– 335. Kraemer, K. & Pinsonneault, A. (1990) Technology and groups: Assessment of the empirical research. In J. Galegher, R. Kraut, & C. Egido (Eds.), Intellectual Teamwork: Social and Technological Foundations of Cooperative Work, Lawrence Erlbaum Associates, Hillsdale, NJ, pp. 375–405. Leinonen, T., Hakkarainen, K., Appelt, W., Dean, P., Gómez-Skarmetav, A., Ligorio, B., Lipponen, L., Merisaari, L., Mielonen, S., Pontecorvo, C., Sligte, H., & Vosniadou, S. (2001) ITCOLE Project: Designing innovative technology for collaborative learning and knowledge building, In: Proceedings of Ed-Media 2001: World Conference on Educational Multimedia, Hypermedia and Telecommunications, Tampere, Finland. Muukkonen, H., Hakkarainen, K., & Leinonen, T. (2000) Introduction to Fle2 Pedagogy, at http://fle2.uiah.fi/pedagogy.html. Nygaard, K. & Sørgaard, P. (1987) The perspective concept in informatics. In G. Bjerknes, P. Ehn, & M. Kyng (Eds.), Computers and Democracy: A Scandinavian Challenge, Avebury, Aldershot, UK, pp. 371–393. Scardamalia, M. & Bereiter, C. (1996) Computer support for knowledge-building communities. In T. Koschmann (Ed.) CSCL: Theory and Practice of an Emerging Paradigm, Lawrence Erlbaum Associates, Hillsdale, NJ, pp. 249–268. Stahl, G. (1993) Supporting situated interpretation, In: Proceedings of Annual Meeting of the Cognitive Science Society (CogSci ’93), Boulder, CO, pp. 965-970. Available at: http://www.cs.colorado.edu/~gerry/publications/conferences/19901997/cogsci93/CogSci.html. Stahl, G. (2002) Contributions to a theoretical framework for CSCL, In: Proceedings of Computer Supported Collaborative Learning (CSCL 2002), Boulder, CO, pp. 62–71. Available at: http://orgwis.gmd.de/~gerry/publications/conferences/2002/cscl2002/cscl2002.pdf.

24

G. Stahl

16. Stahl, G. (2002) [submitted] The complexity of a collaborative interaction, In: Proceedings of ICLS 2002, Seattle, WA. 17. Stahl, G. & Herrmann, T. (1999) Intertwining perspectives and negotiation, In: Proceedings of International Conference on Supporting Group Work (Group ’99), Phoenix, AZ. Available at: http://orgwis.gmd.de/~gerry/publications/conferences/1999/group99/group99.pdf. 18. Stahl, G., Ruland, R., Appelt, W., Hinrichs, E., & Woetzel, G. (2002) [submitted] Negotiating shared knowledge in asynchronous learning networks, In: Proceedings of HICSS 2002, Hawaii, HA. 19. Steinkuehler, C., Derry, S., Woods, D., & Hmelo-Silver, C. (2002) The STEP environment for distributed problem-based learning on the World Wide Web, In: Proceedings of Computer Support for Collaborative Learning (CSCL 2002), Boulder, CO, pp. 217–226. 20. Wulf, V., Pipek, V., & Pfeifer, A. (2001) Resolving function-based conflicts in groupware systems, AI & Society, 15 , pp. 233-262. 21. Zuboff, S. (1988) In the Age of the Smart Machine, Basic Books, Inc., New York, NY.

Collaborative Learning in a Web-Accessible Workbench 1

1

1

J. M.Martins Ferreira , Gustavo R. C. Alves , Ricardo Costa , and Nick Hine 1

2

Faculdade de Engenharia da Universidade do Porto (FEUP / DEEC), R. Dr. Roberto Frias, 4200-465 Porto, Portugal {jmf, galves, rjcosta}@fe.up.pt 2 University of Dundee (Department of Applied Computing, MicroCentre), Park Wynd, Dundee DD1 4HN, United Kingdom [email protected]

Abstract. Web-based course management and delivery is regarded by many institutions as a key factor in an increasingly competitive education and training world, but the systems currently available are largely unsatisfactory in terms of supporting collaborative work and access to practical science facilities. These limitations are less important in areas where “pen-and-paper” courseware is the mainstream, but become unacceptably restrictive when student assignments require real-time teamwork and access to laboratory equipment. This paper presents a web-accessible workbench for electronics design and test, which was developed in the scope of an European IST project entitled PEARL, with the aim of supporting two main features: full web access and collaborative learning facilities.

1

Introduction

Web-based course management and delivery software packages are widely available on the market and are becoming increasingly popular [1]. Easier access to pedagogical contents and flexible schedules are attractive not only to students but also from the institutional point of view, where a rich catalogue of pedagogical web contents is nowadays of strategic importance [2]. However, and in spite of its fundamental importance for students in practical science domains, effective remote access to laboratory facilities is traditionally ignored in the current generation of webbased education and training frameworks. Moreover, and since teamwork plays an important role in most work assignments, facilities for collaborative learning / work are equally as important and must be able to support real-time communication in the form of audio and video conferencing, besides the traditional text-based chat. The PEARL (Practical Experimentation by Accessible Remote Learning) project was set up with the objective of overcoming these limitations [3:5]. Funded by the European IST (Information Society Technologies) programme, PEARL is a threeyear (2000-2003) project that is being developed to enable practical experimentation for students working together over the Internet or the campus Intranet. The students interact with the remote experiments much as they would in a real teaching laboratory, being able to change parameters and in some cases design experiments. They are also able to observe the results and discuss their actions, using Internetbased collaborative tools embedded in the PEARL system. It is important to stress J.M. Haake and J.A. Pino (Eds.): CRIWG 2002, LNCS 2440, pp. 25–34, 2002. © Springer-Verlag Berlin Heidelberg 2002

26

J. M.Martins Ferreira et al.

that the experiments are real, and as such have an unpredictability that cannot be replicated by simulation. PEARL presents an opportunity to widen access to real experiments that might otherwise only be offered to those able to get to a suitably equipped laboratory. Four types of experiments were selected for validation purposes: – Cellular biology, hosted by the Department of Biochemistry of the University of Dundee (UK), which uses computer controlled electron microscopes to conduct cytology studies – Visual inspection, hosted by the Trinity College at Dublin (Ireland), which is used by engineering undergraduates to carry out image analysis of printed circuit boards – Environmental analysis, hosted by the Open University at Milton Keynes (UK), designed to support a series of experiments at the residential schools for its popular foundation science course – Electronics design and test, hosted by FEUP (Faculdade de Engenharia da Universidade do Porto, Portugal), which provides a web-accessible workbench supporting three main types of experiments: test of digital and mixed-signal circuits (for final year undergraduate and MSc. students), microcontroller-based circuits (second year students) and introductory logic design (first year students) The electronics design and test remote lab was developed in the form of a workbench supporting full access via the web and is the main subject of this paper, where a specific emphasis is placed upon the collaborative learning facilities and their implications over such aspects as system design, information system management, and design of pedagogic experiments. The three types of experiments available share a common look-and-feel interface, which varies only according to experimentspecific control / observation facilities. The access protocol for the microcontroller and the introductory logic design experiments is the same and includes the following steps: i) implementation of the functional specification presented in the lab script (code design or hardware design, according to the type of experiment), which is carried out off-line; ii) design verification by simulation, still off-line; iii) connection to the remote lab server; iv) design upload (code or schematic), remote hardware reset and set up. The third type of remote experiment supported addresses the test of digital and mixed-signal circuits. While sharing the same user interface design and collaborative learning facilities, all the steps are performed on-line (because all test actions are carried out using an interactive application integrated in the user interface). A set of interim trials have already been conducted in relation to this type of experiments, providing a rich volume of data on pedagogical and technical aspects, including the implications of collaborative learning tools over the network traffic and effectiveness of learning. The architecture of the remote lab (hosting the web-accessible workbench that supports the three types of experiments) will be presented in the next section, followed by a description of the digital and mixed-signal test experiments, and a summary of relevant aspects related to experiment access and design. Finally, a summary of the main conclusions that are available so far will be presented, together with the current perspectives for future work.

Collaborative Learning in a Web-Accessible Workbench

2

27

FEUP’s Remote Lab Architecture

All PEARL experiments are based on a remote lab architecture that includes three main components: the web server, the lab server and the laboratory equipment. The web server hosts the course management and delivery software (e.g. WebCT or any other similar package), processes all the actions / requests from the user, and communicates via local area network with the lab server. This second machine interacts with the laboratory equipment, either directly or via a dedicated communication and control bus. In the case of FEUP’s web-accessible workbench, the architecture of the remote lab may be represented as illustrated in Fig. 1. PXI computer (lab server) LAN RS-232

Goepel

4

Function generator

Parallel

4

Digital I/O

RS-232 connection

1

Reset input

Multimeter

Oscilloscope

1

Analog Power -on (+5V) in output

std desktop (web server)

Internet

Analog out

Client

Remote hardware LAB

Fig. 1. The web-accessible workbench in FEUP’s remote lab. The whole infrastructure remains the same for the three types of experiments supported, which differ only in the remote hardware that is made available to the students

The lab server is implemented in the form of a 500 MHz Pentium III embedded controller that is part of a PXI rack interconnecting the various workbench instruments. This computer runs Windows NT and is responsible for controlling the following modules: – A Goepel digital I/O board supporting boundary scan, used to control and observe digital pins, and to interact with IEEE 1149.1 scan chains (for digital and mixed-signal test experiments) – A function generator board, used to provide analog stimulae in mixed-signal test experiments – A multimeter board, made available to support simple measurements of analog and digital waveforms – A two-channel 100 MHz oscilloscope, used to visualize waveforms in predefined pins, as specified in each experiment script LabView was used to build customized interfaces for all the PXI instruments referred above. A commercial tool from Nacimiento (AppletView) was then used to generate the equivalent web interfaces in the form of JAVA-based applets, which the

28

J. M.Martins Ferreira et al.

experiment designers use as building blocks to produce the user interface seen by the students (a given experiment may or may not use all the instruments referred above).

3

Digital and Mixed-Signal Test Experiments

A first set of experiments was developed to support the Design for Testability class offered to final year undergraduate and MSc. students in Electrical and Computer Engineering (ECE). The remote hardware for these experiments consists of demonstration boards containing one or more components compatible with the IEEE standards 1149.1 (standard test access port and boundary scan architecture) [6] and 1149.4 (standard for a mixed-signal test bus) [7]. IEEE std 1149.1 defines an embedded test infrastructure commonly present in VLSI components and was developed to support structural testing of digital printed circuit boards. IEEE 1149.4 is essentially an extension of 1149.1, and supports structural and parametric testing of mixed-signal circuits. These two test standards enable full controllability and observability operations via a small number of access pins (four pins for the test access port – TAP – in the 1149.1 std, and two extra analog test access port – ATAP – pins for the 1149.4 std), making it possible to detect open or short circuit faults without requiring physical access to the nodes under test. The digital and mixed-signal test experiments enable the students to interactively carry out elementary test procedures, using the JAVA-based applets to control the remote instruments, and a simple public domain application to interact with the IEEE 1149.x test access ports. 3.1

User Interface

A user interface integrating control and communication tools was built to support a first set of interim trials, described in the following section. This user interface is illustrated in Fig. 2 and provides the following main resources: – Videoconferencing channels, seen vertically on the left – Text-based chat, seen horizontally on bottom – A two-channel oscilloscope, occupying the central area (channel 0, channel 1, trigger controls, time base and display) – A function generator, seen above the oscilloscope display – Interaction with the IEEE 1149.x test access ports, seen horizontally on top It is particularly important to stress the presence of control and communication resources in the same interface, enabling videoconferencing among the students while the experiment is being carried out. Text-based chat might be considered redundant in this case, but it becomes an effective tool to register actions agreed upon by the team, which may later be printed out by each member as a session log. Notice that the various resources referred are available to the experiment designer as independent building blocks, and as such the user interface might comprise several windows, one for each specific action or PXI instrument.

Collaborative Learning in a Web-Accessible Workbench

29

Fig. 2. User interface used by the final year undergraduates and MSc. ECE students to carry out mixed-signal test experiments

3.2

Interim Validation Trials

A set of interim trials was conducted at FEUP on November and December 2001, providing important feedback concerning the proposed system architecture, usability of the interface and pedagogical effectiveness. An experiment script was previously made available to five groups of two MSc. students, specifying in detail all the actions that should be carried out. The two students in each pair were located in different rooms and could only communicate via videoconferencing and chat. The script specified which procedure was under the responsibility of each student, but they had to communicate frequently in order to agree upon the specific actions required (this was particularly important, since both were able to control the remote PXI instruments). Additionally, a tutor was available in his office to provide support and clarify doubts, who again could only be contacted via videoconferencing or chat. A typical student workplace and the remote web-accessible workbench are shown in Fig. 3. In order to explore the implications for the network operators of the campus infrastructures, measurements were made of the traffic generated during the interim trials. These measurements are a good first indication of the impact that a PEARL system will have on the campus infrastructures, and provide early data for exploitation discussions within and outside the project institutions.

30

J. M.Martins Ferreira et al.

A typical student workplace

Remote lab workbench

Fig. 3. A student workplace and the remote lab workbench during the interim trials of the digital and mixed-signal test experiments. Notice the PXI server and instruments, all contained in the rack at the center of the workbench

3.3

Network Traffic and Collaboration Tools

The EtherPeek network monitoring tool was used to capture the network data packets. This tool is able to capture all packets, or only a filtered set, within a network subnet. Statistics such as packet loss, distribution of packets between network protocols, etc., can then be extracted from the data gathered. Traffic between the lab server and the students’ or tutor’s workstations passes to them via the learning material server (which in the this case was a WebCT server), as may be seen in a detailed analysis of the network traffic logs. The total volume of traffic generated by the experiment was around 650 Kbps, of which around 170 Kbps was between the collaboration server and the various participants’ machines. The traffic between any user’s machine and the rest of the machines is around 160 Kbps. This suggests a requirement for the servers to be on a 100 Mbps LAN segment, and the user / tutor stations to be on 10 Mbps segments with good routing to the servers. The traffic data gathered for the user and tutor machines shows that HTTP traffic represents a higher share than videoconferencing traffic, which confirms the feasibility of using this type of synchronous communication facilities for collaborative work in this context. The collaboration tools chosen for the PEARL project are based on a web-based conferencing system built around a central server and browser-delivered user interfaces. The web-based approach was chosen in order to enable seamless integration with the interfaces of the experiment instruments. As far as the authors are aware, there is currently only one system available that provides these requirements, the CUWeb system marketed by First Virtual Communications. This system is an evolution of the successful CUSeeMe videoconferencing technologies, and uses a software H.323 compatible videoconferencing server. Because this server is standards compliant, a variety of software and hardware clients may be used in a single conference. Application sharing and collaboration tools are supported according to the T.120 standard, but the only viable implementation of that standard is within the NetMeeting

Collaborative Learning in a Web-Accessible Workbench

31

software from Microsoft. NetMeeting was not chosen as the principle client for PEARL however because for two reasons. Firstly, it operates as a client application alongside other applications. This would mean that rather than provide the students with a single seamless interface, the various functions of the experiment and student interactions would be provided through different applications on the students’ machines. The second reason relates to the way that the NetMeeting client generates the packets of data containing the video and audio content. NetMeeting preserves video quality in its default configuration by encoding all content in a given time period in variable length IP packets. The greater the complexity of the video and audio content, the larger the packets. Other software based clients, including the CUSeeMe video and audio engines sacrifice quality by using fixed length packets, and discarding content if it exceeds the capacity of the packets available for the specified operating bandwidth limits. This quality loss is noticeable but does not affect the information conveyed in the PEARL context. This approach ensures that, from a network management point of view, the CUSeeMe clients consume less network capacity and generate predictable network traffic.

4

Experiment Access and Design

This section will exemplify the sequence of actions required to carry out an experiment, including session booking and collaborative learning issues. Additionally, and since collaborative work aspects are a specific script design feature, the final remarks will address this topic.

4.1 Access and Booking Access to the remote lab is done via the entry page shown in Fig. 4 and requires a valid login and password, which may be obtained by filling in a registration form and submitting it to the Lab administrator. Once a valid login and password is granted, the student may then book a session, using the interface shown in Fig. 5. When accessing their own booked sessions, the students are given full control and observation privileges. If a student accesses an ongoing session, i.e. another user has booked it or is currently using the remote lab, he/she is still granted access, but only with observation privileges (i.e. it is possible to watch what the current user is doing, but not to control any of the buttons / switches present in the user interface). When a certain experiment requires collaborative work, the team members have to use the same login and password, which can be requested by any of them. After receiving the registration approval from the Lab administrator, the element that made the request may indicate the group’s login and password to the other group members. 4.2 Collaborative Learning and Script Design The lab script for the experiment on the mixed-signal test infrastructure instructs one student to control / observe the digital part and the other student to control / observe the analogue part, as summarised in table 1. The proposed experiment requires

32

J. M.Martins Ferreira et al.

Fig. 4. Entry page to the remote lab supporting the three types of experiments described

Fig. 5. Weekly schedule displayed to enable a student to book a session

Collaborative Learning in a Web-Accessible Workbench

33

exchange of information within the pair of students, since the required test procedures include coordinated actions in the digital and analogue parts. The collaborative tools are essential in this type of experiment, because they allow the students to exchange ideas and solutions, and also enable the necessary synchronization between their actions (which is facilitated by the fact that each of them sees what action is currently being carried out by the other). The data collected from the interim trials revealed the students mostly use audio and video for exchanging support information, while the tutor used the chat window essentially for answering questions posed by the students (tutor participation via chat had two benefits: it had a low impact on the network traffic and it enabled the students to keep a record of the tutor’s recommendations). Table 1. Summary of the collaborative actions required from each pair of students in the digital and mixed-signal test experiment selected for the interim trials Task

Student A (uses an integrated application to access the digital part)

Initialise test infrastructure and provide the required waveforms to the analogue inputs Check that the test infrastructure is in transparent mode

Select the required access port and initialise the test infrastructure

Place test infrastructure in observability mode (observe the signal present at the analogue output, through one of the analogue test pins)

Verify that the signal applied to the analogue input is present at the analogue output – connected to one of the oscilloscope input channels Set up the digital test infrastructure (ensuring that the analogue switching structures provide the required operating mode)

Student B (uses the function generator and oscilloscope to access the analogue part) Set up the function generator (sine wave, frequency, amplitude, etc.) Set up the oscilloscope (Volt/div, trigger source, time basis, etc.)

Help student A to determine the test vectors that will set up the digital test infrastructure as required

It is important to stress the importance of teamwork towards the effectiveness of the learning process, as became readily evident from the questionnaires filled by the students during the interim trial period. This is a well-known fact in cognitive studies and should be taken into account either in remote experimentation or in simulationbased experiments [8]. However, the introduction of collaborative work features calls for specific pedagogical skills, which frequently go well beyond the technical competence required for the design of (remote) experiments. Script design should therefore be seen as a multidisciplinary activity oriented by technical and pedagogical requirements, particularly when an increasing number of web-based communication and collaboration tools are widely available to improve the outcome of the authoring process.

5

Conclusion

The prototype validation and interim trials work done so far leads us to believe on the effectiveness of providing access to remote experiments in a collaborative context [9].

34

J. M.Martins Ferreira et al.

The trials carried out with five groups of two MSc. students were videotaped and the network traffic was monitored. At the end of the experiment, each student filled in a questionnaire and was personally interviewed by a psychologist. At the time of writing, the PEARL project is at about two thirds of its duration. Besides experiment design and production of tutor support documentation, the work currently under way addresses the preparation of the main validation trials, which are planned for November 2002, when approximately 400 ECE students attending the Microcontroller / Microprocessor class will be available to provide comprehensive information concerning usability, reliability and pedagogical aspects. The effectiveness of remote experimentation as a cognitive tool for learning was not addressed in the interim trials of PEARL, which were essentially concerned with technical and usability information, and not so much an evaluation of pedagogic impact. Moreover, its effectiveness comparatively with other cognitive tools for learning [10] will be an important issue to address in the main validation trials.

References 1.

B. Landon, On-Line Educational Delivery Applications: A Web Tool for Comparative Analysis (http://www.ctt.bc.ca/landonline/). 2. Richards, P.: MIT to make nearly all course materials available free on the World Wide Web (http://web.mit.edu/newsoffice/nr/2001/ocw.html) (April 4, 2000) 3. Cooper M., Scanlon E., Freake, S.: Remote Controlled Teaching Experiments, in Science and Engineering Subjects, Accessible over the World-Wide-Web: the PEARL project, World Conference on Educational Multimedia, Hypermedia & Telecommunications (EdMedia), Montreal, Canada (2000) 4. Cooper M., Santacruz Valencia, L.: User interface approaches for accessibility in complex WWW applications – Examples from the PEARL project, Association for the Advancement of Assistive Technology in Europe Seminar (AAATE), Hatfield, UK (2000) 5. Fidalgo, A., Costa, R., Martins Ferreira, J. M., Alves, G.: Experimenting the 1149.1 and 1149.4 test infrastructures in a Web-accessible remote Lab (without Plug-ins!), XVI Conference on Design of Circuits and Integrated Systems (DCIS’01), Porto, Portugal (2001) 6. Test Technology Standards Committee of the IEEE Computer Society, IEEE Standard Test Access Port and Boundary-Scan Architecture, IEEE Std 1149.1-1990 (includes IEEE Std 1149.1a-1993), ISBN 1-55937-350-4 (1993) 7. Test Technology Standards Committee of the IEEE Computer Society, IEEE Standard for a Mixed Signal Test Bus, IEEE Std 1149.4-1999, ISBN 0-7381-1755-2 (2000) 8. Joolingen, W.R. van: Designing for collaborative discovery learning. In G. Gauthier, C. Frasson, K. VanLehn (eds.) Intelligent Tutoring systems (202–211), Berlin: Springer (2000) 9. Martins Ferreira, J. M., Costa, R., Alves, G., Cooper, M.: The PEARL Digital Electronics Lab: Full Access to the Workbench via the Web, 13th EAEEIE Annual Conference on Innovations in Education (European Association for Education in Electrical and Information Engineering), York, UK (2002) 10. Joolingen, W.R. van: Cognitive tools for discovery learning. International Journal of Artificial Intelligence in Education, 10, pp. 385-397 (1999)

Document Management in a Computer-Integrated Classroom 1

2

2

2

Nelson Baloian , Alexander Berges , Stephan Buschmann , Katrin Gaßner , 2 2 2 Jens Hardings , Heinz Ulrich Hoppe , and Wolfram Luther 1

2

Universidad de Chile, Departamento de Ciencias de la Computacion, Blanco Encalada 2120, Santiago, Chile {NBaloian}@dcc.uchile.cl

University of Duisburg, Institute for Computer Science and Interactive Systems, Lotharstr. 65, 47048 Duisburg, Germany [email protected], {buschmann, gassner, hardings, hoppe, luther}@collide.info www.collide.info

Abstract. This paper reports on a work in-progress scenario of a computerintegrated classroom (CiC) with a focus on document management and document sharing. Following a brief introduction on the topic of distributed (distance) and non-distributed (face-to-face) learning, the system´s functionalities and architecture are being described, as well as the file structure to be found in the document archive. The system uses a unique type of XML document that can be created and edited by the FreeStyler application. The paper then concludes with a short description about the future work on the project.

1

Introduction

Traditionally, most of the research efforts in Computer Supported cooperative Learning (CSCL) areas have been dedicated to develop distance learning scenarios (for a good covering of this issue see [4]), still most learning activities take place in the traditional classroom, i.e. in a face-to-face learning scenario. It is still an open question if future learning will take place in the more de-personalized way of “virtual learning” or continue in the traditional style. Meanwhile, there are still classrooms, and there are people, namely teachers, whose responsibility it is to organize classroom learning. Accepting this reality, we can still ask what could be gained by using new information and communication technologies in classrooms. Motivated by the fact that innovative hardware and software has made its way to the classroom, some systems supporting in classroom learning scenarios have been developed [5, 9]. In this paper we present a system supporting teacher and student sharing learning documents in a computer-integrated classroom (CiC). The original idea of a computer-integrated face-to-face classroom was exemplified in the COSOFT environment [2,3]. Recently, the CiC idea was adapted to “early learning” in a primary school classroom [10] as well as to academic lecturing [7]. We share the J.M. Haake and J.A. Pino (Eds.): CRIWG 2002, LNCS 2440, pp. 35–44, 2002. © Springer-Verlag Berlin Heidelberg 2002

36

N. Baloian et a1

same principles which are behind the development of systems like Classroom2000 [I] and the electronic classroom used by ITM [13] about ubiquitous computing in the classroom [12]. However, Classroom2000 is oriented to capture the lecture and store it in files and the ITM classroom is oriented to remote lecturing. In our project we address the problem of document management (distribution, collection, sharing) inside (and outside) the classroom. It differs from the traditional courseware creation and managing systems in that it combines traditional face-to-face lecturing with computer supported collaborative learning. In a CiC setup the teacher presents the learning material (multimedia documents) on an electronic blackboard. Every student has a notebook or PDA, while the technical system provides the functionalities of interaction among the multiple computers. A wireless LAN connects the student's computer with the electronic blackboard, and there is a server (outside the local network) which provides and stores learning material. A CiC also includes systems which help teacher and students to recover, manage and share learning material. The CiC combines positive aspects of the classical chalkboard approach, particularly its flexibility in the spontaneous elaboration of ideas, with the potential of modern networked multimedia. The value added lies in the avoidance of discontinuities in representations ("media breaks"). In the CiC approach presented here, re-use and exchange of results, either synchronous or asynchronous, is easily possible. The full spectrum of basic representations, ranging from freehand input to sophisticated simulation and animation is available.

7 MW variolu

Fig. 1. The computer-integrated classroom scenario.

The work presented in this paper was motivated by concrete experience from a lecture about programming in distributed systems held at Duisburg University. Many problems occurred which could have been avoided by having an administration system for the learning material of the course. The same group is now designing and developing the CiC system for this particular case. The work reported here focuses on the teacher's work-plan (in a classroom).

Document Management in a Computer-Integrated Classroom

37

Although the CiC is still work in progress, most functionalities have already been implemented. The next chapter will introduce the use cases, that have been extracted as important needs. Chapter 3 will deal with the implementation of the system presenting its architecture, modules, and implementation of some important functionalities. Chapter 4 will briefly present some characteristics of the documents which are administrated by the system and the tool used to present and manipulate them. Chapter 5 will present some conclusions and future work.

2

The System Functionalities

The basic functional requirements for the envisaged CiC scenario can be broken down into the eight items listed below, each corresponding to a typical “use case”: Registration of teachers, courses, and students. In order to facilitate the document handling and management it is necessary to first register teacher, students and courses to the Document Manager. This module also maintains information about what courses are taught by each teacher, and the students that participate in each course. Login procedures for students and teacher. Teacher and students have to login to start a teaching and learning session. The teacher can establish a classroom session which the students may join. The username and password credentials determine access rights to files and directories within courses’ and students’ files, inside as well as outside the classroom. Distributing/collecting documents. During a classroom session the teacher can distribute and collect documents of any type to and from the students. Documents can be located on the Document Manager or in a local directory, either at the teacher’s electronic blackboard or on the students’ computer. 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/her work to the rest of the class. Discussions can be supported by allowing other students or the teacher to use the document being shown, adding notes and drawings to further explain their idea. Monitoring the students’ work. During a classroom session, a teacher can look at student’s work within a document, for example to examine the progress made on an assignment or to verify the correctness of work in progress. A teacher is also able to collect parts of documents from the students, increasing his ability to monitor the work by comparing different approaches. Questions and answers. A module named “Questions and Answers” allows students and teacher to interact in a chat-like manner. The conversation details can be saved for a later analysis of the written interaction inside the classroom.

38

N. Baloian et al.

Working outside the classroom. Users should have the possibility to create and modify learning material wherever they are. For this reason, we have implemented an interface that enables the user to access and edit the learning material via the internet. However, the tool does not include a synchronous remote learning environment via video or audio conferencing, it solely enables users to continue and edit their work started in the classroom environment. Logging the actions during a session. We will provide mechanisms for keeping track of relevant information about the actions taken during the lectures by the teacher and the students for a later analysis. Conclusions can then be drawn about how the lecture was organized. For example, it is important to record which documents were opened during a session, how many times they were opened during the whole course, and how many times they were modified. This can provide us with valuable information about which files need to be replaced, complemented, or deleted.

3

The System Architecture

As a result of our practical experience we assumed the system should consist of at least one classroom local area network (Classroom Environment), desirably secured by a firewall which is again connected to a Document Manager (see 3.1). Adding to this we wanted to present the users the ability of asynchronous and distributed work on their documents, i.e. via an internet connection outside the classroom. The component developed for this purpose is situated in the Home Environment. 3.1

The Modules of the System

The System is organized into different components, placed into three environments: classroom environment, server and home environment. The functionalities of the components shown in Figure 2 and their interaction with each other is described below. Session Control. The first component of the classroom environment is a supervision tool for the teacher: the Session Control. It is to be run by the teacher only, either on the electronic blackboard or on a separate computer. It includes mechanisms for synchronizing the instances of client interfaces in the classroom environment, for giving and taking rights to or from the users, and for logging session information. As the central component for the teacher it also includes file handling functionalities. This enables the teacher to use the Session Control as a stand-alone interface on the blackboard or in combination with the File Handler (run on the blackboard). Not only can any document from the Document Archive or inside the classroom environment be sent to a selection of students, any document that is currently being worked on by any user can also be displayed on a selection of students’ File Handlers.

Document Management in a Computer-Integrated Classroom

39

Fig. 2. System structure and environments.

File Handling. It is used in the classroom environment by the students and the teacher to open, edit, create, transfer and display the user’s files or course files. Adding to this it allows direct communication with the Session Control Interface via a questions and answers dialogue. Remote File Editor. The home environment consists only of the Remote File Editor, that enables the users to view, create, edit and transfer their files located on the Document Archive from a remote location. This is implemented by an internet connection and the document editor FreeStyler. It does not include synchronous collaboration with other users. Document Manager. The Document Manager is part of the server environment and provides authentication to all users in either the classroom or home environment, including the individual’s rights inside the whole CiC system. Adding to this it controls all file transfers from and to the Document Archive and keeps track of new and existing sessions and courses. Document Archive. This repository is the second part of the server environment and stores all documents of the users, courses and sessions, all personal information of the users and all logged information. The Document Archive is controlled by the Document Manager. 3.2

The File Structure at the Document Archive

The Document Archive consists of a hierarchical organization of files containing all the necessary information to administrate the CiC. This includes information about the teachers and their files, the students and their files, the courses and the learning material associated with them, the information about which students are in a certain course, which teacher is responsible for a certain course, as well as the rights for

40

N. Baloian et al.

teachers and students to create, modify, and/or read certain files. The next figure shows the directory structure and the information contained. The root of the repository is divided in three directories: Courses, Teachers and Students, which contain the corresponding home directories. The home directories of Teachers and Students contain personal information, a Logs directory to store the actions history and a Files directory which is the only visible to the clients. The courses have the same structure, but the Files directory has another name as its use is oriented to share documents rather than store personal files. Also, each course may have another directory intended for uploads of e.g. homework prepared by students.

Fig. 3. The file structure at the Document Archive.

3.3

Permissions Management

The access rights are managed on the Document Manager, which assigns some default settings that can be changed later on. By default, each user controls the visible part of the home directory (he/she can perform all the available operations), and can grant or deny “read”, “write” and “delete” access rights within this hierarchy. The enforcement of the rights is done at a lower level, using a custom Java SecurityManager which is automatically invoked before operations like opening files are attempted within the JVM. Using this scheme, it is not necessary to audit every part of the server code, since the code itself is not trusted to perform every action.

Document Management in a Computer-Integrated Classroom

3.4

41

Implementation of Login Procedure

The login procedure consists of several steps, including authentication from the data stored in the Document Archive. To start a new Classroom Environment Session for an existing course, the Session Control sends login parameters to the Document Manager and receives all available course information accessible to the given teacher. When a new session has been created, any File Handler can now access the running session by sending user parameters to the Document Manager, which authenticates the user with information stored on the Document Archive. Only after having received a unique session ID, the File Handler can perform a login to the Session Control (via RMI) and is then signed up to the Classroom Environment.

3.5

Implementation of Document Distribution and Sharing

During a classroom session the teacher can distribute and collect documents or parts of documents to and from the students. Files are first downloaded from the Document Archive (Fig.4, arrow 1) and can then be distributed among the multiple users (Fig.4, arrow 2). For the sharing of content (i.e. part of a document) in the classroom situation, we use a synchronization server called MatchMaker [11], which allows the sharing of objects. This sharing is accomplished by maintaining a copy of the FreeStyler document model on the server, and sending the modifications to all clients that share the specific object being edited. It is important to note that the model exists in distributed copies on each client, so an application or communication failure does not imply loss of data, since the model will be available from any copy. 3.6

State of Implementation

All Modules have been developed and tested in collaboration with each other. Some functionalities are still missing, though, which will have been implemented and tested by the time the paper is being printed. A restructuring of the whole system, including the specification of standard actions evolving in a learning situation and the implementation of these is to be undertaken at that point. At the same time we will work on the strengthening of the interaction between the FreeStyler document editor and the individual CiC tools, which implies that certain actions or user inputs can be implemented in the FreeStyler directly, rather than repetitively in each CiC tool.

42

N. Baloian et al.

Fig. 4. Distribution and sharing of documents displayed in the FreeStyler model.

4

The Documents

For creating, manipulating and viewing the documents, the primary tool will be the FreeStyler [8]. It can be used during multiple working phases as preparation, creative meetings, presentation, postprocessing or wrapping up information Therefore, is serves also as an interface between face-to-face discussions and the documentation process. This is enabled by a cooperative visual language which offers a set of content objects to structure information. A content object combines a symbolic view with predefined interactions. It can be characterized as a template for a special type of information as ideas, concepts, decisions, addresses or internal and external links. Whereas several content objects rather define the category of information, others, i.e. the links, provide additional structural information and interaction features. Together with these content objects users can add handwritten input flexibly. Methods as concept mapping, mind mapping or MetaPlan are easy to perform with the FreeStyler. The external representations both enrich and influence the communication. The documents may include a workflow description about how and when they should be distributed to the students, collected, where they should be stored, etc. This allows the system to offer useful default alternatives to the user, minimizing the input required to perform each task and keeping the focus on the session. FreeStyler files are stored in XML format. Beside the advantages of a standard format in general, XML makes it easy to retrieve information. In order to exchange

Document Management in a Computer-Integrated Classroom

43

the maps an integrated mail functions converts the maps to a picture format and send the content as attachments or the original XML files. FreeStyler-internal filters allow for separating types of information in order to focus on special aspects as decision or ideas. The system will provide an interface to query the XML documents, both in their current state while being edited and off-line in the repository. This way, the teacher can monitor the work of the students over the document as well as grade the work or analyze the result of past sessions. The structure of the documents will help the teacher to look whether certain part of a assignment has been finished by all students, or if some keywords appear in the answers.

5

Conclusions and Future Work

We intend to use and evaluate the system in various scenarios, one of which will be a sample classroom setup in AccessNova at the University of Chile, another will be a comparison of lecturing using this system to the traditional way of teaching at the University of Duisburg. The evaluation of the results will be on the level of system usability (with surveys for teachers and students) and effectiveness (with tests about the issues being learnt/taught for the students and comparing them with results of the same test taken on a control group). The CiC architecture and functionality share certain features with currently available “course management tools” such as Blackboard CourseInfo, WebCT, Luvit or TopClass (for a comparison, cf. Hazari, [6]). The specific issues addressed in our work are: - The services provided have been designed with a primary focus on inclassroom work as opposed to remote scenarios. - The application focus is more on the intra-course perspective with a smaller granularity (although multiple groups and courses are supported), not so much on the administration of courses in a bigger institution. - The system is deeply integrated with the document data model used and comprises a XML-based query interface for teacher supervision as well as for intelligent support and analysis. - The components in our modular architecture can also be used in other contexts or as special purpose services.

References 1. 2. 3.

Abowd, G.: Classroom2000: An Experiment with the Instrumentation of a Living Educational Environment. IBM System Journal, Special issue on Pervasive Computing. Vol. 38, Nr. 4, pp. 508–530, (1999). Baloian, N., Hoppe, H.U., Kling, U.: Structural Authoring and Cooperative use of Instructional Multimedia Material for the Computer integrated Classroom. In: Proceedings of the ED-Media, Graz, Austria (1995). 81–86 Baloian, N., Hoppe, H.U., Pino, J.A.: A Teaching/Learning Approach to CSCL. In: IEEE Comp. Science press, Los Alamitos, CA (USA) 33rd Annual Hawaii International Conference on System Science. Maui, HI (USA). (2000)

44 4. 5. 6. 7.

8.

9.

10. 11. 12. 13.

N. Baloian et al. Berge, Z. & Collins, M. (eds.): Computer-mediated Communication and the Online Classroom, Hampton Press, New Jersey, USA, (1995) Colazzo, L. & Molinari, A.: To see or not to see: tools for teaching with hypertext slides. In: H. Maurer (Ed.): Proceedings of ED-Media 95 (World Conf. on Educational Multimedia and Hypermedia), Graz, Austria (1995) 17–21 Hazari, S.: Evaluation and Selection of Web Course Management Tools. http://sunil.umd.edu/webct/ (1998) Hoppe, H.U., Luther, W., Mühlenbrock, M., Otten, W., Tewissen, F.: Interactive Presentation Support for an Electronic Lecture Hall. In: Cumming, G., Gomez, L., Okamoto, T. (eds.): Advanced Research in Computers and Communications in Education. IOS Press, Amsterdam, The Netherlands (1999) 923–930 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, USA (2002) 716–725 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) 473–477 Tewissen, F., Lingnau, A., Hoppe, H.U.: “Today’s Talking Typewriter” – Supporting Early Literacy in a Classroom Environment. In: Gauthier, G., Frasson, C., VanLehn, K. (eds.): Proceedings of Intelligent Tutoring Systems. Montreal, Canada (2000) 252–262 Tewissen, F., Baloian, N., Hoppe, H.U., Reimberg, E.: "MatchMaker" Synchronising Objects in Replicated Software-Architectures. In: Proceedings of 6th International Workshop on Groupware (CRIWG) Madeira, Portugal. IEEE CS Press (2000) Weiser, M.: Some Computer Science Issues in Ubiquitous Computing, Communications of the ACM 36, No. 7, 75–84 (1993). Perez, E., “IT Management Center Project”, http:// itm.dsv.su.se/eng/index.htm

Handheld CSCW in the Meeting Environment 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. This paper discusses the role of PDA in the meeting environment. Three fundamental design issues are raised: PDA as mobile devices, CSCW devices and coordination devices. The research work described in this paper is focused on the coordination facet. The paper proposes three levels of detail to characterize meetings as coordination mechanisms and ascertain the role of PDA in that process. The first level identifies meeting agents and roles, as well as the tangible things necessary to support those roles. The second level describes how the tangible things are organized in meetings, highlighting repetitive patterns in meeting processes. Finally, the third level draws the functional requirements of the PDA support to the tangible things. The paper applies the proposed approach to a specific meeting environment, staff briefings, and uses a small consulting company as test bed. The PDA functionality was specified from analyzing how the test bed organization conducted staff briefings. A prototype was then developed. The test bed organization also produced feedback information on the prototype use. The obtained results indicate a general satisfaction with the functionality and increased enthusiasm with PDA usage in the meeting environment.

1 Introduction PDA play an important role as mobile devices that support personal information [1]. In that context, PDA allow one person to create and manipulate personal information away from the desktop and plug in to remote information sources to upload, download or synchronize specialized information. Several researchers analysed in detail the concept of mobility. Dix et al. [2] consider three levels of mobility: fixed, mobile and autonomous systems. Kistoffersen and Ljungberg [3] [4] define three different modalities for mobile work: travelling, wondering and visiting. Travelling is the process of working while going from one place to another. Wondering is extensive local mobility in a building or local area. Visiting is spending time in one place for a period of time before moving on to another place. The concept of visiting clearly encompasses formal meetings, where people get to-

J.M. Haake and J.A. Pino (Eds.): CRIWG 2002, LNCS 2440, pp. 47–60, 2002. © Springer-Verlag Berlin Heidelberg 2002

48

P. Antunes and C.J. Costa

gether in a conference or office room, while the wondering concept applies to informal meetings held in places such as hallways and cafeterias. Mobility should also be considered in terms of context [5]. Context deals with the situated nature of groups of users and existing work practices and poses significant problems to the design of information devices that allow mobility between different contexts [2]. PDA can also be regarded as CSCW devices, able to manipulate collective artefacts. Luff and Heat [6] illustrate the importance of these artifacts with the example of the medical record, which in many circumstances serves to organize work and mediate the interactions between doctors and patients, as well as other health care personnel. In this perspective PDA must support two fundamental requirements of collective artefacts. One is fluidity between public and private contexts [1]. The other requirement is flexibility. People manage collective artefacts in many subtle ways according to the affordances of the medium, situated nature of work, type of interaction and degree of cooperation (Luff and Heat highlight the importance of what they designate micromobility [6]). Meeting environments represent another instance where fluidity and flexibility are vital. During meetings, people alternate between private and public information in very fast and disorganized ways. Meeting subgroups are dynamically created and reconfigured as well. Moreover, meeting processes are governed by many complex and subtle rules and procedures. Thus, meeting environments challenge the design of adequate PDA support to shared meeting artifacts. PDA can finally be regarded as coordination tools. A critical issue to organizational and team performance is coordination. According to some authors, coordination can be classified in two major categories: impersonal coordination and coordination by feedback [7]. Impersonal coordination is exemplified by the use of plans, schedules and procedures. Coordination by feedback is illustrated by two significant examples: one-to-one communication and group meetings. In everyday activities, people move around personal information, such as calendars and address books – possibly the most widely used PDA tools – creating opportunities to reduce the effort associated to impersonal coordination [8]. However, PDA are as well becoming important tools in the support to coordination by feedback. In this paper we analyze the role of PDA in the meeting environment. Our main scenario is a meeting room where people meet face-to-face, have a desktop computer in the room, possibly linked to a shared whiteboard, and bring their own PDA as well. This scenario emphasizes the importance of the link between personal information and meeting information. The issue then is to understand how can the PDA be used in this environment, considering the design issues of mobility, support to shared artifacts and coordination. In this paper we also describe an implementation of a handheld meeting system in the scenario broadly described above. The system was experimented by an organization, thus drawing some preliminary results also presented in this paper.

Handheld CSCW in the Meeting Environment

49

2 Related Work Several research projects studied the role of PDA in the meeting context. We will overview these projects according to the three major design issues that were previously considered: mobility, support to shared artifacts and coordination. One of these research projects is Pebbles, developed at the Carnegie Mellon University [9] [10] [11] [12]. Pebbles connects PDA devices and desktop computers in real-time. The major concern of Pebbles is to explore different modalities, such has having the PDA controlling a slide show on the desktop. Another area of concern is developing mechanisms to exchange information between PDA and large display devices, which are awkward to write directly. Another project, developed at the University of Calgary, is the SharedNotes prototype [1]. Shared Notes is a meeting system that uses PDA to integrate public and private artifacts. The project addresses the issues of information exchange and presentation, while resolving important design issues such as feedback and awareness. NotePals is a note sharing system designed to take individual notes during meetings and later synchronization and sharing via the web [13]. As such, NotePals is fundamentally concerned with mobility issues, information uploading and post-meeting sharing of information. One example of NotePals usage is the post-production of meeting reports. The RoamWare project intended to support informal face-to-face meetings, such as the ones that people have in hallways and corridors [14]. One research issue addressed by this project is the support to ad-hoc meeting arrangements, where PDA must scan for co-located devices to establish connections. In what concerns shared artifacts, RoamWare pursues the seamless distribution of notes taken during meetings while preserving their context. RoamWare associates meeting notes with the particular group of individuals interacting in a ad-hoc meeting, creating, for instance, e-mail distribution lists and thus facilitating information distribution to the right people. Table 1. Systems and major design goals Systems Peebles

Mobility

Shared Notes Note Pals

RoamWare

Note taking in meetings; Uploading and sharing Ad-hoc meetings

FieldWise MeetingLog, MeetingManager

Shared artifacts Multiple modalities; Information exchange and presentation Information exchange and presentation

Coordination

Seamless integration; Meeting context Knowledge management

Individual recording meeting topics

50

P. Antunes and C.J. Costa

FieldWise addresses the problem of autonomous mobile workers that must coordinate with co-workers to make decisions and accomplish tasks [15]. FieldWise is a mobile knowledge management system. It supports evolving tasks and notifies users of interdependencies. One should note however that FieldWise was basically designed for remote work rather than face-to-face meeting environments. Besides the several systems described above, developed in the research field, we should also mention that several commercial/freeware PDA tools (e.g. MeetingLog and MeetingManager) can be used in meetings for individual recording and tracking of topics, notes, decisions, etc. As summarized in Table 1, the role of PDA in meetings has mainly studied and developed the mobility and shared artifacts facets. The work described in this paper will essentially focus on coordination though.

3 Focusing the Problem Meetings bring together people sharing a common purpose. Meetings combine a series of dimensions in human behavior, such as communication, interaction, decisionmaking, negotiation, conflict resolution or creativity. The major argument in favor of meetings is that they increase creativity, coordination and informed decision-making [16]. In this context, coordination may be defined as managing dependencies between activities [17]. Often, meetings are connected in meeting systems revolving around the same problems over a long period of time and thus serve as a control mechanism by determining whether and when work is performed. Malone et al. [18] [19] conceptualized the types of dependencies between activities and corresponding coordination mechanisms. In this conceptualisation, resources emerge as a fundamental mediator between activities. We will not go into the details of the relations between resources, activities and dependencies. Instead, we will consider two different types of information in these resources: œ The intangible things – The contribution of the resources to organizational objectives, such as reconcile conflicts, make decisions, solve problems, plan actions, approve activities, etc. œ The tangible things – Physical testimonials that report and preserve the intangible things that will be consumed or produced during meetings. Examples are meeting minutes, action plans or meeting transcripts (e.g., [20]). Many organizations are even legally required to document this way some particular meetings, such as stakeholder meetings. For us, this distinction is necessary to delimit the type of interventions in the meeting environment that we are considering for PDA. Having PDA supporting the management of intangible things leads necessarily towards the field of workflow and, particularly, flexible workflow and mobile workflow, (e.g. [21]). Ancona, et al. [22] describe such approach in a healthcare system. On the other hand, the PDA support to tangible things deals basically with organizational

Handheld CSCW in the Meeting Environment

51

memory. For instance, Davis et al. [23] developed a note-taking repository that uses PDA. Our work focuses only on the PDA support to the tangible things that turn up in meeting environments. Having in mind these considerations, we will now delineate a conceptual approach to the problem.

4 Conceptual Approach In this section of the paper we characterize in more detail the tangible things that mediate meetings and the other activities in organizations. Our conceptual approach proposes a characterization at three increasing levels of detail [24]. The first level describes the context of the problem, including the main agents and activities. The second level describes the institutionalised communication patterns, categorizing the tangible things consumed and produced by meetings. Finally, the third level is the implementation level, describing what and how tangible things integrate in the organization, and the role of PDA in the process. In the first level we can identify five types of agents (or roles): œ

Sponsor is the owner of the meeting, who defines the meeting objectives and rules.

œ

Facilitator is the person that plans and manages a meeting.

œ

Participants are those who attend a meeting and contribute by making comments, giving opinions, voting, etc.

œ

Secretary is the agent that produces the meeting report and distributes it to the other agents.

œ

Organisational agents are those agents that affect meetings or find their activities directly affected by meetings.

This first level allows us to identify a set of generic tangible things necessary for accomplishing the above roles: (1) the agenda, produced and managed by the facilitator and approved by the sponsor; (2) issues, produced by organizational agents and related to the topics proposed in the agenda; (3) decisions, taken by the meeting participants and affecting organizational agents; and (4) the meeting report, produced by the secretary to document the other tangible things. The second level of the framework is intended to describe how the different tangible things are organized in a meeting. This organization is not ad-hoc, it is rather ritualized, reflects organizational culture and most times follows a ceremonial order [20]. In fact, the organizational values and rules impose repetitive patterns in meeting processes. One issue to ponder is how to identify these patterns. We adopted an organizational analysis/diagnosis method designated genre analysis [25] [26]. The genre concept was imported from the literature, where its main purpose was to classify literary works, and generalised to the organisational context [27] [28]. A genre of “organisational

52

P. Antunes and C.J. Costa

communication” is an institutionalised template for social action, such as a memo, report, resume, inquiry, letter, meeting, announcement, expense form or training seminar. Genres are primarily characterised by their purpose and form. The purpose is not an individual’s private motive for communicating, but a purpose socially constructed and recognised by the community, and invoked in typical situations. The form refers to observable aspects of the communication, such as medium, structural features and linguistic features, which entail recognition and action by the community. The genre approach gains particular interest considering that organizations utilize many different computational systems to communicate and work, such as e-mail, video conferencing, web chats, workflow, calendaring tools or group editing. Genre analysis captures and categorizes the different “digital genres” used by the organization in terms of communicative purpose and form. Furthermore, the genre analysis also captures how organizations combine different genres in complex communicative patterns designated “genre systems”. These genre systems highlight how organizations structure work and manage interdependencies. Considering the meeting environment, the genre analysis highlights typical patterns in meetings. Orlikowski and Yates [28] consider that meetings can be regarded as a system consisting of four generic genres: logistics, agenda, the meeting itself, and the meeting report. Note that the agenda and meeting report are two tangible things that we already identified at the first level. The genre approach adds logistics to that list, i.e., details on who participates in the meeting, when and where is the meeting taking place, what technology is being used. Most importantly however, the genre approach defines a scheme to classify and characterize different types of recurrent meeting systems in organizations, such as planning meetings, quality circles, staff briefings, formal evaluation meetings, design meetings, task forces, brainstorming meetings, conferences and workshops, ceremonial meetings, etc. These different types of meeting systems include particular types of logistics, agenda, meeting genres and reports, as well as particular types of agents and roles, issues and decisions. This second level of detail thus amalgamates in coherent patterned structures the tangible things that make up meetings. Finally, we will consider the third level of detail. The third level concerns implementation details: how genres and genre systems are materialized and integrated in the organization, how people enact and use genres to accomplish work. How PDA will participate in that process. Considering our previous discussion, we can at this level identify the following functional requirements to the PDA use in the meeting environment: œ Allow users to produce, distribute and carry to meetings a meeting agenda; œ Support the production of issues related to the agenda items; œ Document decisions taken during meetings; œ Integrate the agenda, issues and decisions into a meeting report that can be distributed to organizational agents; œ Document the meeting logistics (who, when, where, what); œ Support concrete meeting patterns;

Handheld CSCW in the Meeting Environment

53

œ

Offer different templates of the agendas, issues, decisions, reports and logistics according to the meeting patterns that are recurrent in the meeting environment. In the next sections we will describe the implementation of our conceptual approach to the particular case of staff briefings.

5 Applying the Approach to Staff Briefings Organizations regard staff briefings as particularly important coordination mechanisms. Usually, staff briefings call for project members to report on the progress of individual or group tasks, allowing management to track and assess the overall project status, identify project risks and apply any corrective actions that may be needed. In order to study in detail the particularities of staff briefings, we observed and analyzed how a small financial consulting and accountancy company conducted weekly staff briefings. Both the type of structure (small, flat) and core business (independent consultancy) of this company stresses the role of briefings as a primary coordination mechanism. The target organization uses, on a daily basis, several coordination technologies, such as web chat, net-meeting and e-mail. Fundamentally, these technologies support one-to-one coordination. The organization relies on meetings to achieve more broad coordination, encompassing the whole senior staff, which includes accountants and consultants. We participated in several meetings and were able to find out that the organization coordinates itself around three recurrent meeting patterns: (1) process definition meetings, dedicated to analyze work processes in an informal way, clarifying and improving the organizational maneuver; (2) planning meetings, which allocate staff to consulting projects and schedule individual tasks; and (3) briefings, where the state of each committed task is analyzed. Briefings, in this organization, have a weekly frequency, occurring in general every Friday. The typical composition includes two senior consultants and one senior accountant. We will now describe how we applied the conceptual approach described in the previous section to derive design goals for PDA support to this company’s staff briefings. Level 1 – Agents, Activities, and Tangible Things

In the target organization, the same person carries out the sponsor and facilitator roles. This person is the top responsible for the organization, although we should note that the power distance is small, considering that the organizational structure is small and flat. The sponsor/facilitator is also a meeting participant. The secretary role is distributed through all participants. The participants write down their own actions committed during the briefing, while the sponsor/facilitator is also informally responsible for tracking the others’ actions.

54

P. Antunes and C.J. Costa

The organizational agents affected by these briefings are the senior consultants and accountants. Thus, the meeting participants are also organizational agents but not all organizational agents participate in a weekly briefing. The sponsor/facilitator manages an agenda consisting of a list of tasks currently in progress. The issues contributed by participants consist of progress reports. The decisions taken during briefings involve approvals of on-scheduled tasks and re-schedules of delayed tasks. Each participant is responsible for taking notes about the decisions made during the briefings. Finally, this organization does not produce a formal report, although the sponsor/facilitator preserves the whole list of tasks that the organizational agents are responsible for. Level 2 – The Briefing Pattern

The sponsor/facilitator brings to the briefing the list of tasks that were previously scheduled in planning meetings and are currently in progress. This list shapes the briefing agenda. During the briefing the sponsor/facilitator goes through this agenda, item by item. The participants may bring their issues already prepared to the briefing, reporting the progress of the tasks that are their responsibility, or produce them during the briefing. Apparently, the consultants and accountants prefer a certain level of informality in their meetings and thus a formal progress report is not required. While going through the agenda, the participants analyze and discuss the issues, considering in detail what was done and what was not done and why. The decisions taken during briefings consist fundamentally in informally approving on-schedule tasks and re-scheduling delayed tasks. Sometimes re-scheduling also requires reassigning tasks to participants and organizational agents. Each participant is responsible for taking notes about the individual tasks that are re-scheduled. The sponsor/facilitator also takes notes about the status of all tasks. This organization uses simple and fixed logistics. The briefings happen in a weekly frequency, occurring every Friday, in the same room, at the same hour, with the available senior consultants and accountants. Level 3 – Functionality

The proposed system functionality is based on the assumption that the sponsor/facilitator has a PDA. The other participants may have PDA as well or use paper and pen to write down the meeting decisions. Furthermore, there must be a desktop computer available in the meeting room, ideally connected to a shared whiteboard. The sponsor/facilitator brings the agenda to the briefing in her PDA. The agenda consists of a “topic list”. The sponsor/facilitator can synchronize the PDA with the desktop computer, thus sharing the agenda with the other participants through the whiteboard. Then, the sponsor/facilitator goes through the topic list to get issues from the participants. The participants may have prepared these issues in their PDA and, in that case, are able to synchronize their PDA with the desktop computer to present an issue to the audience. The desktop computer collects these issues and associates them with

Handheld CSCW in the Meeting Environment

55

the topic list in the agenda. The participants may also insert issues directly on the desktop computer. At any time the sponsor/facilitator may synchronize her PDA with the desktop computer and get a coherent collection of topics and issues. To that collection, the sponsor/facilitator may append the decisions taken in the briefing. The participants can take individual notes on their PDA, documenting the decisions and schedules concerning their individual tasks. These individual notes are collected in “to-do lists”. Such lists can be associated with the collection of topics and issues synchronized with the desktop computer. In the next section we will describe in more detail the implementation of this functionality.

6 Prototype The prototype consists basically of three different components: (1) the sponsor/facilitator’s database; (2) the participants’ database; and (3) the shared whiteboard application. The PDA software implementation used the Jfile database system (www.landj.com) for the Palm Pilot. The sponsor/facilitator’s database has the following elements: topic list, issues, and decisions. The participants’ databases add to-do lists to the above elements. In Figures 1 and 2 we illustrate the structure of these databases, while in Figure 3 we illustrate the Palm user-interface for the to-do list. The shared whiteboard application was implemented using Internet technology (HTML files, CGI and Perl scripts) and a relational database from Microsoft. Users can interact with this application using a web browser, since it runs on the Xitami (imatix.com) web server. Sponsor/ facilitator

maintains >

Topic list

< report

< progress

Decisions

Re-schedules Fig. 1. The sponsor/facilitator’s database

Issues

56

P. Antunes and C.J. Costa

< report

Topic list

Issues

< progress

< approves

Decisions

track >

brings >

Participant maintains >

Re-schedules

To-do list

briefing >

Fig. 2. The participants’ database

Fig. 3. To-do list on a participant’s database

We should mention that this prototype was developed from a previous prototype that we built to integrate PDA with an Internet-based Electronic Meeting System (also built by us). In fact, the prototype described in this paper is the result of removing functionality to the previous one. While experimenting the PDA/EMS integration mechanism, we found out that the added value was resulting from the coordination support provided by PDA rather than integration with EMS. More details on the previous prototype can be found in [29] [30].

Handheld CSCW in the Meeting Environment

57

7 Feedback and Discussion The solution that was developed to integrate PDA in the meeting environment was experimented by several employees of the organization where the study was conducted. Although no formal evaluation was performed, we could obtain some preliminary feedback information about the overall acceptance of the system. The major aspect of the solution that made the users generally satisfied is that it preserves the flexibility of the team. The conceptual approach does not mandate formalized work procedures but, instead, supports the recurrent work practices and types of information exchanged between the meeting participants. All of the users that participated in this project had a PDA (one had a Psion while the others had Palm Pilots). However, at the beginning of the project, they were not very enthusiastic about using PDA in meeting environments, basically because they considered its use very disruptive. By the end of the project, however, there was a rebirth of interest in PDA usage during meetings. Apparently the benefits provided by the system (synchronizing meeting information) surpassed the associated costs (disruptive use). We should also mention that many aspects pertaining to the characterization of the tangible things managed in briefings were oversimplified. For instance, re-scheduling and re-assigning tasks may be a complex procedure, requiring the group to manage project, process and task information. However, the users were satisfied with the level of detail that was implemented. Some users even criticized any attempt to increase functionality. This attitude should be further analyzed in the future, but it hints that this kind of system should be kept simple. We note however that briefings are a particularly simple meeting pattern. Briefings are very ritualized and do not seem to offer much latitude for creativity, discussion and decision-making. Furthermore, the tangible things managed in briefings are also very simple. For instance, people mention projects, processes and tasks but do not seem to analyze or discuss their inner details, rather focusing on status information. Other meeting patterns should thus be more difficult to implement, such as planning meetings or strategic meetings. Future work is necessary to understand if our conceptual approach can be applied to more demanding situations.

8 Conclusion This paper describes how we brought handheld CSCW into the meeting environment. Our major concern was to understand how PDA could improve the role of meetings as fundamental coordination mechanisms. PDA have already an important role in the support to individual information, but its support to team meeting information is still low. The conceptual approach proposed in this paper defines three levels of detail for handling the problem. The first layer highlights the major roles and activities that people assume during meetings, as well as the tangible things necessary to accomplish those roles. Then, the second layer is concerned about how organizations bring to-

58

P. Antunes and C.J. Costa

gether the tangible things into identifiable repetitive patterns in meeting processes. Finally, the third layer is dedicated to identify the functional requirements of the computational system and, particularly, the role of PDA in that system. The paper describes the application of the conceptual approach to a particular type of meetings: the staff briefings. A target organization in the accountancy field was selected to help us identify the major roles and activities, tangible things and patterns associated to briefings. The implementation work was accomplished with the cooperation of several employees of the organization. The employees had also the opportunity to experiment the developed prototype and provided us with some feedback about their satisfaction with the whole system functionality. The prototype was considered adequate to support briefings and also seemed to increased users’ enthusiasm towards PDA usage.

Acknowledgments. This paper was partially supported by the Portuguese Foundation for Science and technology, Project POSI/SRI/34392/99.

References 1.

Greenberg S, Boyle M, Laberge J (1999) PDAs and Shared Public Displays: Making Personal Information Public, and Public Information Personal. Personal Technologies, March. 2. Dix A, Rodden T, Davies N, Trevor J, Friday A, Palfreyman K (2000) Exploiting Space and Location as a Design Framework for Interactive Mobile Systems. ACM Transactions on CHI 7 (3), September. 3. Kristoffersen S, Ljungberg F (1998) Your mobile computer is a stationary computer. CSCW’98 Handheld CSCW Workshop. Seattle, November. 4. Kristoffersen S, Ljungberg F (1999) Mobile Informatics. In: Planet Internet. Studentlitterature, lund. 5. Urray J (2000) Sociology beyond societies: Mobilities for the twenty-first century. Routledge, London. 6. Luff P, Heath C (1998) Mobility in Collaboration. Proceedings of ACM CSCW’98 Conference on Computer-Supported Cooperative Work. Seattle, Washington. 7. Van de Ven A, Delbecq A (1976) Determinants of Coordination Modes Within Organizations. American Sociological Review (41):322-338. 8. Lewis B (1997) Personal digital assistants could sneak into the office and become the next PCs. InfoWorld 19 (49), December:138. 9. Myers B (2001) Using handhelds and PCs together. Communications of the ACM 44 (11), November:34-41. 10. Myers B (2000) The Pebbles Project: Using PCs and Hand-held Computers Together; Demonstration Extended Abstract. Adjunct Proceedings CHI’2000: Human Factors in Computing Systems. ACM Press, The Hague, The Netherlands, pp 14-15. 11. Myers B, Miller R, Bostwick B, Evankovich C (2000) Extending the Windows Desktop Interface With Connected Handheld Computers. 4th USENIX Windows Systems Symposium. Seattle, pp 79-88.

Handheld CSCW in the Meeting Environment

59

12. Myers B, Lie K, Yang B (2000) Two-Handed Input Using a PDA and a Mouse. Proceedings CHI’2000: Human Factors in Computing Systems. ACM Press, The Hague, The Netherlands, pp 41-48. 13. Davis R, Landay J, Chen V, et al (1999) NotePals: Lightweight note sharing by the group, for the group. Proceedings of the CHI 99 Conference on Human Factors in Computing Systems. ACM Press, Pittsburg, pp 338-345. 14. Wiberg M (2001) RoamWare: An integrated architecture for seamless interaction in between mobile meetings. Proceedings of the 2001 International ACM SIGGROUP Conference on Supporting Group Work. ACM Press, Boulder, Colorado, pp 288-297. 15. Fagrell H, Forsberg K, Sanneblad J (2000) FieldWise: A Mobile Knowledge Management Architecture ACM Press (ed.). Proceeding of the ACM 2000 Conference on Computer supported cooperative work. Philadelphia, pp 211-220. 16. Romano N, Nunamaker J (2001) Meeting analysis: Findings from research and practice. Proceeding of the 34th Hawaii International Conference on Systems Science - HICSS 2001. Hawaii. 17. Malone T, Crowston K (1994) The Interdisciplinary Study of Coordination. ACM Computing Surveys 26 (1), March:87-119. 18. Malone T, Crowston K, Lee J, et al (1997) Tools for inventing organizations: Toward a handbook of organizational processes. Center for Coordination Science, Massachusetts Institute of Technology. 19. Malone T, Crowston K, Lee J, Pentland B (1993) Tools for inventing organizations: Toward a handbook of organizational processes. Proceedings of the 2nd IEEE Workshop on Enabling Technologies Infrastructure for Collaborative Enterprises. Morgantown, WV. 20. The 3M Meeting Management Team (1994) Mastering Meetings. McGraw-Hill, Inc., New York. 21. Carlsen S, Gjersvik R (1997) Organizational metaphors as lenses for analyzing workflow technology. In: Proceedings of the international ACM SIGGROUP conference on Supporting group work : the integration challenge. ACM Press, Phoenix, Arizona, pp 261-270. 22. Ancona M, Dodero G, Minuto F, Guida M, Gianuzzi V (2000) Mobile computing in a hospital. Proceedings of the 2000 ACM symposium on Applied computing 2000. ACM Press, Como, Italy. 23. Davis R, Lin J, Brotherton J, Landay J, Price M, Schilit B (1998) A framework for sharing handwritten notes. ACM Press, San Francisco, California. 24. Costa C, Antunes P, Dias J (2001) A model for organizational integration of meeting outcomes. In: Maung K. Sein, Bjørn-Erik Munkvold, Tore U. Ørvik, et al (eds.) Contemporary Trends in Systems Development. Kluwer Plenum. Papers from the Ninth International Conference on Information Systems Development, ISD 2000. ISBN: 0-306-46608-2. 25. Antunes P, Costa C, Dias J (2001) Applying genre analysis to EMS design: The example of a small accounting firm. Seventh International Workshop on Groupware, CRIWG 2001. IEEE CS Press, Darmstadt, Germany, pp 74-81. ISBN: 0-7695-1351-4. 26. Costa C, Antunes P (2001) Meetings as genre systems: Some consequences for EMS design. In: F Ackermann, G Vreede (eds.) Proceedings of Group Decision & Negotiation 2001. Faculty of Technology, Policy and Management, Delft University of Technology, La Rochelle, France, pp 261-263. ISBN: 90-5638-078-8. 27. Orlikowski W, Yates J (1994) Genre repertoire: The structuring of communicative practice in organizations. Administrative Science Quarterly 39:547-574. 28. Orlikowski W, Yates J (1998) Genre systems: Structuring interaction through communicative norms, CCS WP 205. Sloan MIT WP 4030.

60

P. Antunes and C.J. Costa

29. Costa C, Antunes P, Dias J (2002) Integrating two organisational systems through communication genres. Fifth International Conference on Coordination Models and Languages (Coordination 2002). Lecture Notes in Computer Science, Springer-Verlag, York, UK. 30. Costa C, Antunes P, Dias J (2000) Supporting the meeting report process. Proceedings of the 23rd Information Systems Research Seminar in Scandinavia, IRIS 23. Laboratorium for Interaction Technology, University of Trollahattan Uddevalla, Uddevalla, Sweden, pp 1141-1150. ISSN: 0359-9470.

Effect of the Coordination Modes in Supporting Group Multiple Criteria Decision Making in a Distributed and Asynchronous Environment Juan Carlos Leyva López and Dina Esperanza López Elizalde Universidad de Occidente Carr. a Culiacancito, Km. 1.5 Culiacán, Sinaloa, México Tel. +52-667-7540495 [email protected] [email protected]

Abstract. To solve a multiple criteria decision problem by a collaborative group is necessary to have an adequate coordination process. This paper discusses an on-going research project, which aims to develop an internet-based Multiple Criteria Group Decision Support System (MCGDSS) – which will support to collaborative group decision makers in reaching a consensus when they try to solve a ranking problem – and to further investigate the impacts of such a system on group multiple criteria decision aid (MCDA) process performed in parallel and sequential coordination modes. Features of the MCGDSS prototype and design of a follow-up laboratory experiment are described in this paper. Keywords. Group Decision Support Systems, Multiple Criteria Decision Aid, Ranking Problem, Coordination Modes, ELECTRE Methods.

1 Introduction Group decision making is one of the most frequent and important processes inside of organizations in the public or private sector. Most of the problems about real decision making involve multiples decision makers [34]. The comprehension, analysis, and support of the decision making process can be extremely difficult for three reasons: 1) the basic problem is badly structured, 2) the dynamic environment in which the decision making process develops, 3) the presence of multiple decision makers, each of them with their own points of view about the way the problem has to be managed and what decisions have to be adopted [15]. The strongest obstacle to resolving a group decision problem is that each individual has his/her own perception about problem. Consequently, he/she has his/her own belief about what should be the result or the correct decision to make. Therefore, in such an environment, it is logical and common to find conflicts between the opinions and desires of the group members. These conflicts arise due to the several factors present such as different values and

J.M. Haake and J.A. Pino (Eds.): CRIWG 2002, LNCS 2440, pp. 61–69, 2002. © Springer-Verlag Berlin Heidelberg 2002

62

J.C. Leyva López and D.E. López Elizalde

objectives, different criteria and preference relations, lack of communication support between group members, etc. [30] encapsulates the diverse factors in conflict under the term “distinct value systems.” This paper presents a research projects that aims to develop an Internet-based Multiple Criteria Group Decision Support System (MCGDSS) prototype built around Multiple Criteria Decision Aid (MCDA) models, which provides support for group decision making processes in asynchronous and distributed environments. The project intends to investigate whether the parallel and sequential coordination modes influence the outcomes of the group MCDA processes. In this paper we briefly discuss the research method and design in our study. The MCGDSS prototype and a lab experiment design are also presented in this paper.

2 Group MCDA Process A coordination mode refers to a series of procedures and aggregation methods, which incorporate the group and individual members activities and facilitate them to reach agreement of a high quality group decision [3]. In such an environment, each participant can sometime work individually and/or collaborate with the rest of the group at other time. These two different processes result from two coordination modes, which has named by Cao and Burstein [3] as sequential and parallel modes respectively. The influence of coordination modes on outcomes of group decision making process, however, has not attracted much attention in previous synchronous GDSS studies. Previous research indicated that the different procedure and aggregation methods might bring about different decision outcomes when using MCDM models [33]. In a distributed and asynchronous setting, these coordination modes may have an important influence on outcomes of group decision making. Therefore, such research is necessary and it may help to find out appropriate coordination modes that will bring the individual decision making process into synchronization with the group process, without restricting the achievement of satisfactory decision performance. Cao and Burstein [3] claim that in a distributed and asynchronous setting, these coordination modes have an important influence on outcomes of group decision making, our interest in this research is validate the hypotheses proposed by Cao and Burstein under different conditions: different multiple criteria modeling approach (MCDM vs. MCDA), different platform (Domino-Lotus vs. Groove), different problem solving (selection problem vs. ranking problem) and different method (Simple Additive Weighting (SAW) vs. ELECTRE).

3 Related Works There are a few GDSS that have used multiple criteria analysis techniques to support a group decision. Most of them have focused on communication elements, the structure of ideas, the generation of alternatives and the voting procedures. For instance, the GDSS of Conklin and Begeman [6], Cesar and Wainer [4], Lee [17] are

Effect of the Coordination Modes

63

focused on distributed and asynchronous meeting support, via an interconnected computer network. In these systems, the elements of a debate can be documented, reviewed or used again in any phase of the process, although, in contrast, they do not have structured techniques to solve problems of group decision making. MCGDSS have emerged just in the 80’s, almost twenty years after the introduction of the field of MCDA. These methodologies were identified in Iz [13], Iz and Gardiner [14], and Hwang and Lin [12]. In the early years, Bui [2] presented Co-oP, a co-operative multiple criteria group decision making system. The PLEXSYS system [8] and its descendant GroupSystems [26] contain, among others, a Alternative Evaluator tool which provide multiple criteria decision making support. After appears the Expert Choice system for group decision support based on the AHP method [31]. Also after Barzilai and Lootsma [1], [25] describe some other interesting methods of multiple criteria group decision making support. Hamlainen and Mustajoki [10] present the web-HIPRE system, which, in part, is based on the AHP. In [22] and [7] we can find another studies on MCGDSS. A similar approach to PROMETHEE MCGDSS developed by Macharis et al. [21] we can find in Leyva [18], which is based on the ELECTRE method [30]. By the way, research on the coordination modes in distributed group decision support systems has recently focused on the issue of system restrictiveness, which refers to the degree that a system limits its users decision making processes to a subset of all possible processes [32]. Another research topic has been the flexibility of coordination structure, and its influence on group decision outcomes and performances [24]. The conclusions reached in this area have been inconsistent. In studies on synchronous groups support systems, Chidambaram and Jones [5] reported that a GDSS with a high degree of system restrictiveness had negative impact on group performance. It seems that an imposed coordination structure can be overly restrictive due to the limited bandwidth of the interaction medium. Research regularly indicates that the individuals come to the group with a predetermined preference over others decision alternative and they seem relatively inflexible to following a particular decision making strategy [28]. It is also suggested that less restrictive coordination structures are more appropriate to support asynchronously interacting distributed groups [16]. Therefore, distributed GDSS should be flexible enough to allow the individual freedom to concentrate on aspects of the problems to which he or she can best contribute [35]. On the other hand, Dickson, Partridge, and Robinson’s [9] research indicated that GDSS should be designed with some degree of restrictiveness. Too much freedom in group interaction decreases group cohesiveness. Such loss of cohesion increases the decision cost either by generating a lower quality decision or taking more time to make a decision. Therefore, a coordination structure in distributed GDSS should impose some restrictions on interaction to maintain a certain level of group cohesiveness. The varying outcomes may results from applying different degree of system restrictiveness [11]. So far very little is known about what objectively determines the perceived degree of system restrictiveness. Previous studies have not explicitly shown the use of MCDA to support the group decision making processes. In our study, system restrictiveness is manipulated by applying certain procedures and aggregation methods (particularly ELECTRE methods) to the GDSS process. By manipulating these procedures and aggregation methods in group MCDA we try observe the impacts of different coordination modes on group decision outcomes and performance.

64

J.C. Leyva López and D.E. López Elizalde

4 Group MCDA Processes with Two Coordination Modes As stated above, in this study, we considered two coordination modes: parallel and sequential. We believe these two modes mostly cover the possible ways that people can go through a MCDA process. Guided by these two coordination modes imposed to the decision making process, group may reach a right decision at a right time. 4.1 Parallel Coordination

Parallel coordination means everyone in a group works independently throughout most steps during the decision making process. The procedure and respective aggregation methods are described step by step as following: Preliminary stage structuring the decision problem The preliminary stage is a phase of knowledge acquisition and problem structuring. A facilitator has first to be appointed. On one hand, the facilitator has to be familiar with the GDSS-ELECTRE methodology and, on the other hand, he needs to have a reasonable knowledge of the actual group decision problem and its context. The following steps can be considered potentially. Step 1. First contact Facilitator – Decision Makers. Each decision maker is encouraged to express his own opinions in order to progressively enrich the maturity of the facilitator with respect to the decision process. Step 2. Problem description. The decision makers meet in the MCGDSS. The facilitator comments the available infrastructure and gives an overall description of the problem. Step 3. Alternative generation. This is a “computer” phase during which the decision makers work alone. Step 4. Choose a stable set of alternatives. Step 5. Comments on the alternatives. Step 6. Define the possible evaluation criteria. This step ends the preliminary stage and the next evaluation stages can start. Individual evaluation stage Step 7. The proposed alternatives are evaluated by each criterion Step 8. Define weights and thresholds of the criteria Step 9. The individual ELECTRE analysis The ELECTRE III method [29] is applied to construct a fuzzy outranking relation and next a genetic algorithm [19] is applied to exploit it and as a result it recommends a complete ranking of the alternatives from the best to the worst ones. During the first stage, each decision maker works individually, with the possible assistance of the facilitator. At the end of this stage, everybody has a good personal view of the decision problem. Everybody has ideas on how to decide. More precisely, each decision maker has a ranking of the alternatives in decreasing order of preference. Group evaluation stage. The purpose is now to focus on group decision support in order to take into account the specific points by view of the different decision makers.

Effect of the Coordination Modes

65

Step 10. Global evaluation At the end of the individual evaluation stage, the facilitator collects the rankings an fuzzy preference relations coming from the decision makers and with these information the ELECTRE GD method [20] is applied to construct a fuzzy outranking relation and again the genetic algorithm is applied to exploit it and as a result it recommend a complete ranking of the alternatives from the best to the worst ones. At the end of the step 10, a global evaluation is obtained for the group. The (ELECTRE GD-genetic algorithm) method proposes a best compromise. If the group is agreeing upon the results of the global analysis, the best compromise can be adopted and the GDSS-ELECTRE session can be closed. On the other hand, if for some reasons some decision makers don’t agree on this compromise, the conflicts have to be faced. 4.2 Sequential Coordination

In a nut shell, we can say that sequential coordination implies that consensus would be sought throughout some stages of decision making process, from problem formulation to ranking determination. The consensus may be reached by applying aggregation methods at any appropriate stage. A procedure with sequential coordination mode and ELECTRE III method is: The group is asked to agree on the alternatives, criteria, weights, and thresholds before the model provides a ranking. The group discussion focuses on what actions and criteria should be considered, what weights and other necessary parameters are appropriate. Once the discussion is closed and all the individual information has been gathered, a technique is used for obtaining values of these model parameters, which should represent the collective opinion. With this information, the (ELECTRE IIIgenetic algorithm) method gives us the group ranking. It needs to be noticed that this procedure is iterative rather than simply sequential. If the group is unsatisfied with the result at any stage, it may go back to any step and redo it.

5 Research Design The research question in our study is stated as: “ Which coordination mode between the parallel and sequential ones is more appropriate for a group multiple criteria decision aid process in the asynchronous and distributed environment?” 5.1 Research Framework

The research adopts Nunamaker et al. [27] general GDSS research model. Revised version that conforms to our research design is present in Figure 1. From this “inputprocess-output” system standpoint, coordination mode is an independent variable in our study. McGrath and Hollingshead [23] developed a framework that consists of four primary factors: input, organization concepts, process variables, and outcomes. Their framework stresses the interactive relations between the variables. One of the

66

J.C. Leyva López and D.E. López Elizalde

most interesting points is that the process variables can be regarded as independent or dependent variables depending on the intended purpose. Process quality

Small Group

Process outcome

meta tasks

Satisfaction w ith process Participation

Process

Satisfaction w ith decision Decision outcome

Context

Decision quality Asynchronuous GDSS prototype

Coordination mode: Paralle l and sequential

Confidence in decision

Fig 1. Research framework for adapted MCGDSS [27]

In order to answer the research question, we need to implement a GDSS, which provides appropriate procedures and tools to support the group MCDA process. It should be tailored to suit for our further investigation of the research question. Once the GDSS prototype is implemented, a lab experiment will be organized to further investigate the research question. Two kinds of subject groups will be asked to use the system prototype going through a predefined MCDA process coordinated by the parallel and sequential modes. By observing the MCDA process outcomes, which are measured by the decision outcome and the process outcome, we may find out how significant these two coordination modes might influence the process outcomes. 5.2 GDSS Prototype System Development Environment. The prototype will be developed in Groove by using C++ and Visual Basic languages. Groove is a new groupware technology and consists of a combination of both software and services to transform the Internet into a personal medium for directing communication and interaction between some users. The Groove platform provides services and abilities of development in a wide variety for applications peer to peer. The users directly interact with each other in a real-time environment and share in an asynchronous or synchronous manner. This component has a 40% of advance. System Architecture. The Functional architecture will incorporate the following features: The ELECTRE III model to aggregate multiple criteria individual preferences, the ELECTRE GD model to aggregate the multiple criteria group preferences, a genetic algorithm to exploit a fuzzy outranking relation, the Delphi technique to stimulate and to generate ideas, use of a facilitator tool for optimization

Effect of the Coordination Modes

67

the meetings coordination of the group members, use of a Graphic interface, use of a Database Management subsystem to allow efficient and secure information access, a Norm subsystem, a Discussion subsystem and a Multiple Criteria Decision Analysis subsystem. This component has a 60% of advance. System Features. The prototype provides support for group MCDA process at three levels: a) Individual activity support, b) Group activity support and c) Facilitation support.

6 Laboratory Experiment Design The objective of the experiment is to examine how the use of parallel and sequential coordination modes with the internet-based MCGDSS affects group performance in an asynchronous and distributed environment. A series of experimental sessions will be conducted with a two-group between-subjects design. These experiments based on simulated business environment are being used to evaluate the group performance affected by parallel and sequential coordination modes. The effect of each group configuration will be assessed experimentally on six dependent variables: users’ satisfaction with process, users’ satisfaction with decision outcomes, users’ confidence in decision outcomes, quality of final decision, participation, and quality of decision process. 6.1 Subjects and Decision Task

The experimental subjects in the study will be undergraduate and postgraduate students enrolled in information systems courses. The decision task for this study will be either a case study of solving MCDA problems selected from textbook or familiar MCDA problem, which have been done previously by subjects. A pilot study will be conducted before the main study to test reliability of the prototype and complexity of the decision task, and to fine-tune both of the experimental procedure and the instrument. 6.2 Independent Variable

Coordination mode is the independent variable in the study. It has two levels: parallel and sequential 6.3 Dependent Variables and Hypotheses

Two classes of dependent variables, process outcome and decision outcome, are evaluated as the outcomes of group MCDA processes affected by two coordination modes.

68

J.C. Leyva López and D.E. López Elizalde

6.4 Experimental Procedure and Instrument

The appropriate instruments will be used to collect qualitative and quantitative data for measurement of dependent variables. The response sheets and questionnaire are being prepared for collection of data on both subjective and objective measurements. Two types of groups are being created with two levels of independent variables. In parallel coordination mode (“parallel groups”), subjects will work through decision procedure individually, except agreeing on alternatives in advance, and final group selection through asynchronous on–line discussion. “Sequential” groups will works through one stage of the procedure at a time. Groups will need to reach agreement or aggregate individual results into a group one before moving onto the next stage of decision process. A facilitator will help monitor and collaborate the overall group process.

References 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.

12. 13. 14.

Barzilai, J., Lootsma, F.A.: Power relations and group aggregation in the multiplicative AHP and SMART. Journal of multi-criteria decision analysis 6 (1997) 155-165 Bui, T.X.: Co-oP: A group decision support system for cooperative multiple criteria group decision making. Lecture Notes in Computer Science, Vol. 290. Springer, Berlin (1987) Cao, P. P., Burstein, F.V.: An empirical study of influences of the coordination modes in supporting Group Multiple – Criteria Decision – Making. Australian Conference in Information Systems (ACIS’2000), Brisbane (CD ROM) (2000) Cesar F.L., Wainer, J.: vIBIS: A discusión and voting system. Journal of Brazilian Computer Society 2 (1) (1994) 36-43 Chidambaram, L., Jones, B.:Impact of communication medium and computer support on group perceptions and performance: A comparison of face-to-face and dispersed meetings. MIS Quarterly 17 (4) (1993) 465-491 Conklin, J., Begeman, M.L.: gIBIS: A hipertext tool for exploratory policy discussion. ACM Transactions on Office Information Systems 6 (1998) 303-331 Davey, A., Olson, and D.: Multiple criteria decision making models in group decision support. Group Decision and Negotiation 7 (1998) 55-75 Dennis, A.R., George, J.F., Jessup, L.M., Nunamaker, J.F., Vogel, D.:Information technology to support electronic meetings. MIS Quarterly 12 (4) (1998) 591-624 Dickson, G., Partridge, J. L., Robinson, L.: Exploring modes of facilitative support for GDSS technology. MIS Quarterly 17 (2) (1993) 173-194 Hamalainen, R. P., Mustajoki, J.: Web-HIPRE-Java-applet for value tree and AHP analysis, computer software, http://www.hipre.hut.fi, Systems Analysis Laboratory, Helsinki University of Technology. (1998) Hiltz, S. R., Dufner, D., Fjermestad, J., Kim, Y., Ocker, R., Rana, A., Turoff, M.: Distributed group support systems: Theory development and experimentation. In: Olsen, G. M., Smith, J.B., Malone, T. W. (Eds.): Coordination Theory and Collaboration Technology. Hillsdale NJ: Lawrence Erlbaum Associates (2000) Hwang, C. L., Lin, M.J.: Group Decision Making under Multiple Criteria: Methods and Applications, Vol 281. Heidelberg, Germany: Springer-Verlag (1987) Iz, P.H.: Two multiple criteria group decision support systems based on mathematical programming and ranking methods. European Journal of Operational Research 61 (1992) 245-263 Iz, P.H., Gardiner, R.L.: Analysis of Multiple criteria decision support systems for cooperative groups. Group Decision and Negotiation 2 (1) (1993) 61-79

Effect of the Coordination Modes

69

15. Jelassi, M.T., Kersten, G, Zionts, S.: An introduction to group decision and negotiation support. In: Bana e Costa C. A. (Ed.): Readings in Multiple Criteria Decision Aid. Springer Berlin (1990) 16. Kim, Y., Hiltz, S., Turoff, M.: Coordination structure and system restrictiveness in distributed group support systems: An experiment on coordination mode and leadership. st In: Proceedings of the 31 Annual HICSS Hawaii. IEEE Computer Society. (1998) 145153 rd 17. Lee, J.: SIBYL: A tool for managing group decision rationale. 3 Conference ComputerSupported Cooperative Work 10 (1990) 72-92 18. Leyva López J. C.: A genetic algorithm application for individual and group multicriteria decision making: PhD Thesis Abstract. Computación y Sistemas IV-2 (2000) 183-188. 19. Leyva López, J.C., Fernández González E.: A Genetic Algorithm for deriving final ranking from a Fuzzy Outranking Relation. Foundations of Computing and Decision Sciences 24/1 (1999) 33-47 20. Leyva López J.C., Fernández González E.: A New Method for Group Decision Support Based on ELECTRE-III Methodology. Accepted in: European Journal of Operational Research. January 2002 21. Macharis C., Brans J.P., Mareschal B.: The GDSS PROMETHEE Procedure. Journal of Decision Systems 7 (1998) 22. Matsatsinis N.F., Samaras A. P.: MCDA and preference disaggregation in group decision support systems. European Journal of Operational Research 130 (2001) 414-429 23. McGrath, J. E., Hollingshead, A.B.: Groups interacting with technology: ideas, evidence, issues, and an agenda. Vol. 194. Sage Publications. Thousand Oaks, CA (1994) 24. McLeod, P., Liker, J.: Electronic meeting systems: Evidence from a low structure environment. Information Systems Research 3 (3) (1992) 195-223 25. Miettinen, K., Salminen, P., Hokkanen, J.: Acceptability analysis for multicriteria problems with multiple decision maker. Report 2/1997, University of Jyvaskyla, Department of mathematics, laboratory of scientific computing, Jyvaskyla (1997) 26. Nunamaker, J.F., Dennis, A.R., Valecich, J.S., Vogel, D. R., George, J.F.: Electronic meeting systems to support group work. Communications of the ACM. 34 (7) (1991) 4060 27. Nunamaker, J.F., Dennis, A. R., Valacich, J.S., Vogel, D.R., George, J.F.: Group support systems research: Experience from the Lab and Field. In: Jessup L.M., Valacich J.S. (Eds.): Group Support Systems: New perspective. Macmillan Publishing Company. (1993) 125-145 28. Putnam, L.L.: Procedural messages and small groups’ work climates: A lag sequential analysis. Communication Yearbook 5 (1982) 331-350 29. Roy, B.: The outranking approach and the foundations of ELECTRE methods. In: Bana e Costa, C.A., (ed.) Reading in multiple criteria decision aid. Springer-Verlag, Berlin. (1990) 155-183 30. Roy, B.: Multicriteria methodology for decision aiding. Nonconvex Optimization and its applications, Vol 12. Kluwer Academic Publishers, the Netherlands (1996) 31. Saaty, T.: The Analytic Hierarchy Process. McGraw Hill, New York (1980) 32. Silver, M.S.: Decision support systems: Directed and nondirected change. ISR 1(1) (1990) 47-70 33. Tung, Y.A.: Time complexity and consistency issues in using the AHP for making group decisions. Journal of Multi-Criteria Analysis 7(3) (1998) 144-154 34. Turban, E.: Decision Support Systems and Expert Systems: Managerial Perspectives. Macmillan, New York. (1988) 35. Turoff, M., Hiltz, S.R., Bahgat, A., Rana, A.: Distributed group support systems. MISQ Vol 17 (4), (1993) 399-417

A Cooperative Visual Hypermedia Approach to Planning and Conducting Virtual Meetings Weigang Wang1, Jörg M. Haake2, and Jessica Rubart1,3 1Fraunhofer

Institute for Integrated Publication and Information Systems (IPSI) Dolivostr. 15, 64293 Darmstadt, Germany {wwang, rubart}@ipsi.fhg.de 2 FernUniversitaet Hagen, Computer Science VI Informatikzentrum, Universitaetsstr. 1 D-58084 Hagen, Germany [email protected] ³go4teams GmbH Julius-Reiber-Strasse 15a, 64293 Darmstadt, Germany

Abstract. Most distributed meeting support systems focus on meeting management and audio/video communication mechanisms. They provide little support for a flexible meeting process and a shared information space with structure-rich visual artifacts. In this work, a cooperative visual hypermedia system is developed to provide visual hypermedia artifacts for team members to manipulate in a distributed meeting. The visual hypermedia system is a hypermedia-based drawing system that integrates visual hypermedia artifacts and structures found in multiple hypertext domains. In addition, the visual hypermedia is integrated with process support for flexible meeting control and for easy setup of audio/video and application sharing communication channels. A use cases is presented, which shows that using the cooperative visual hypermedia, distributed teams can perform many kinds of meetings, in the meantime, enjoying dedicated support for the planning, control, information management, and follow-up activities of a distributed meeting. Keywords. Cooperative hypermedia, visual hypermedia, process support, distributed meeting support.

1 Introduction The trend towards globalization of business activities requires business teams to carry out their projects in a distributed environment. While face-to-face project meetings have always been central to effective teamwork, distributed meetings are used more and more often to reduce traveling costs and time, and to couple with emerging issues on short notice.

J.M. Haake and J.A. Pino (Eds.): CRIWG 2002, LNCS 2440, pp. 70–89, 2002. © Springer-Verlag Berlin Heidelberg 2002

A Cooperative Visual Hypermedia Approach

71

Traditional meeting support systems focus on augment co-located face-to-face meetings. In recent years, many distributed meeting support systems have been developed to provide audio/video communication channels, meeting management services, and some simple floor control mechanisms. However, these systems lack support for a well-planned flexible meeting process, lack a common information space with structure-rich visual artifacts, and lack the support for document handling. Our approach to tackle the problems is to develop a cooperative visual hypermedia for providing Πa common information space with structure-rich visual artifacts, Πflexible meeting process modeling and control, Πintegrated document management, and Πsession-based meeting management and easy setup of communication and application sharing channels for a meeting session. The remainder of the paper is organized as follows: section 2 provides a problem analysis on meetings, distributed meetings and distributed meeting support systems. Section 3 introduces the cooperative visual hypermedia concept and provides detailed descriptions of our approach to addressing the found problems. Section 4 describes hypermedia related implementation techniques that make our approach possible. Section 5 presents use cases of our system. Section 6 presents related work and section 7 concludes the paper with a summary, contribution highlights, and plans for further work.

2 Problem Analysis Meetings are social or business events when a number of persons come together at a certain time and place for certain purposes, such as discussion and decision-making. Good meetings can create a dynamic interaction between participants to achieve more then one could achieve alone. Meetings are an important part of any business. There are many kinds of business meetings, such as, Πproject work sessions, Πstrategic planning, Πmanagement team meetings, Πcustomer problem solving sessions, Πproject reviews, Πstaff meetings, and Πteam building meetings. 2.1 What Makes a Meeting Successful Working together does not always guarantee efficiency. Unnecessary or bad meetings could be just a costly interruption and a waste of time. A good meeting needs to have [8]

72

W. Wang, J.M. Haake, and J. Rubart

Œ Œ Œ

A strategically designed agenda with commonly understood goals and objectives. A clear, agreed upon process for reaching those goals and running the meeting. An awareness that people come with their personal preoccupations and feelings, as well as an interest in the subject at hand. Œ A sense of involvement and empowerment; Œ A skilled facilitator. To make a meeting effective, five meeting specific roles need to be taken by meeting organizers and participants [11]: Œ

Chairman: who is responsible for meeting pre-coordination, setup, operation, and follow up; who decides the "why/what," "when," "where," and "who" of the meeting; and organizes and publishes a meeting agenda.

Œ

Presenter: who finds out how much time the presentation is allowed to take, and provides information clearly and concisely. ΠRecorder: who condenses information into key points, documents decisions, actions, and pertinent information, and produces meeting minutes ASAP after the meeting. ΠTimekeeper: who helps maintain the pace of the meeting by reminding people of time used, and ΠParticipants: who shows up on time and prepared for discussion, and remains attentive, alert, and focused throughout the meeting. The chairperson of a meeting needs to plan for support of each of these roles. It is possible to play more than two roles during a given meeting, but that is not wise in most meetings. Because it may not be possible for one to pay enough attention to the task at hand when one attempts to do this. Therefore, to make a meeting successful, the following meeting support services should be provided: Πmeeting planning for preparing a well-designed meeting process (or agenda) with a clear purpose in a business context. A meeting process or agenda specifies the sequence of meeting activities, the roles of participants, and the resources allocation to the activities. Πmeeting management for setting up meeting facilities and for participants to take part in the right meeting sessions they are intend to, Πa common information space for information presentation and manipulation, Πleadership to run a meeting in an efficient and flexible way, and Πdocument handling for documents prepared before a meeting, presented and manipulated in a meeting, and stored for follow-up activities. Based on their roles, meeting participants may have different access rights to the meeting support services. The common information space should not only provide tools for information presentation, but also allow meeting participants to annotate and modify the information presented (e.g. to modify an agenda). For supporting discussion and exploitation, widely used visual artifacts and tools should be provided.

A Cooperative Visual Hypermedia Approach

73

2.2 Distributed Meetings (Virtual Meetings) Distributed meetings are Virtual Meetings that denote the situation where meeting participants from different locations and organizational units meet in a "virtual" meeting place. In such a distributed virtual setting, meeting planning, coordination and communication become even more crucial. The meeting process as one fundamental component of collaboration needs to be viewed and supported as a part of the overall business processes taking place in the organizational and social context. Audio/video channels have to be easy to setup and use. It should also be easy for meeting participants to find the virtual place and join their part of the meeting, or be on-line at the right time for meeting organizers to bring them into the right meeting sessions. Before or during the meeting, the participants may have a need to import pre-existing documents into a common workspace, jointly view and manipulate the workspace in the meeting, and export documents to a shared organizational repository. As a discussion aid, synchronous manipulation and structuring of visual artifacts including writings and drawings are also very important. 2.3 Distributed Meeting Support Systems Efficient and effective technology support for distributed meetings is a key to virtual organization effectiveness through (1) saving of cost and time required for communication and collaboration in distributed teams. This will enable the user organization to better cope with dynamics of the market. (2) better reaction on short notice will be possible. This leads to greater flexibility. (3) establishing/strengthening business relationships (not only to partners, but also to suppliers and customers) due to better communication and collaboration facilities. (4) reduction of media breaks due to integrated document management, collaborative work and conferencing facilities. However, so far, attempts of technological support for distributed meetings (e.g., video conference studios for meetings, Internet-based and Web-based text or audio chatting, white boarding, application sharing tools) have been disappointing. Insufficient progress – or even failure – of most current meeting support systems are caused by their lack of support for shared document handling, by missing support for a rich set of information structures and visual artifacts, and by their insufficient integration with asynchronous modes of co-operation and related applications (e.g., workflow management systems). Most importantly, the current generation of tools for distributed meetings lacks a comprehensive model of such meetings in a business context. A model that integrates the meetings into the overall business processes is necessary to guide the construction of effective virtual meeting facilities. Because of all these deficits, the current generation of facilities remains of marginal value to businesses.

74

W. Wang, J.M. Haake, and J. Rubart

3 The Cooperative Visual Hypermedia Approach Our approach to tackle the above mentioned problems is to develop a cooperative visual hypermedia for providing Πa common information space with structure-rich visual artifacts, Πflexible meeting process modeling and control, Πintegrated document management, and Πsession-based meeting management and easy setup of communication and application sharing channels for a meeting session. In this work, we extended our component-based cooperative hypermedia system XCHIPS [7] with visual hypertext artifacts and above mentioned meeting support services. The key points of our approach are presented in the following subsections. 3.1 Visual Hypermedia: A Hypermedia-Based Drawing System with Structure-Rich Visual Artifacts The visual artifacts and tools that people widely use in face-to-face meetings include blank sheets or whiteboards, on which people can write and draw using colored lines, shapes, and sticky tags or pin cards. Sticky tags or pin cards allow people to post them in one way and then to organize or classify them in different ways. It is also very common to see people to draw arrow lines between cards or group of cards to indicate their relationship. Cooperative electronic whiteboards are tools provided in many distributed meeting support systems for such purpose. But these whiteboarding tools lack the flexible structuring support, such as the composing and decomposing capabilities that many object-oriented drawing systems have and the reorganizing and classification, nesting, and linking that supported by many spatial [12] and graphical navigational [17] hypermedia systems. Spatial hypertext uses spatial layout and some visual characteristics to represent relationship. For instances, similar information objects are placed near to each other. Navigational hypertext is the classical hypertext that is normally presented to users as a content page with highlighted embedded links (e.g. a Web page). Navigational hypertext structures may also be presented visually as hypertext maps, in which labeled square or icons represented nodes and arrow lines between them represent links. Our approach to providing structure-rich visual artifacts is to combine the features found in spatial and graphical navigational hypermedia systems as well as those found in drawing tools into a visual hypermedia system. Such a system can make use of various visual properties found in drawing systems for the expressing relationship among various visual artifacts. These visual properties include the (foreground and background) colors, patterns, images, the label text, the size, the orientation, the position, the shape, and the Z-ordering of the visual components. In the mean time, it makes all these visual components into hypermedia objects that can be re-organized into different sets or nested structures, be linked to or referred to each other, and linked to external documents.

A Cooperative Visual Hypermedia Approach

75

For instance, while explicit link representations (e.g. as arrow lines) are good for expressing the precedence relationship between tasks, color-coding is better for indicating the state of the tasks (e.g. yellow means ready and green means on-going). Such visual hypermedia can be used to create and manipulate both the meeting process structures (see section 3.3 and section 5) and the visual contents (see section 5) that used in various sessions of the meeting . The user interface (i.e. the XCHIPS browser) for the visual hypermedia (see Figure 1) resembles that of a drawing tool: it has two visual object palettes providing predefined visual hypermedia object types and general types that can used to derive new types. In Figure 1, on the top toolbar, there are buttons to activate a textual chatting tool and the MS NetMeeting tool. On the right-hand side palette, there is a list of visual object types for process modeling. On the left-hand side palette, there are object types for creating information objects, among which there a general node type (the button with a blue “i” icon) and a general link object type (the button a link icon) for users to create new node and link types on selected hypermedia model objects (such as “folder” or “href”, see section 4.1 and 4.2). The appearance of new visual types can be defined by using menu operations on the newly created general types, for instance, to change its foreground and background colors or patterns, the label text, the size, the orientation, the shape, and the Z-ordering of the visual component, or to load an image. These visual properties correspond to the visualization design dimensions that a good visual design should consider [16]. Any visual objects in the content pane can be used as a prototype for creating new instances of the same type with the same appearance (by copying). A view copy mechanism can be used to create multiple views of the same model object (see section 4.1). The whole nested structures rooted from a composite node can be used as a template for cloning the whole hypermedia structure in one operation. 3.2 Session-Based Meeting Management and A/V Setup A meeting is normally organized into one or more sessions A session is also a meeting, which may involve all or part of meeting participants. Sessions may happen in parallel or one after another. Each session takes a period of time used for a particular purpose or activity and happens normally in one meeting room. To simplify meeting management for distributed meetings, we do not make a difference between a meeting and a session. In our approach, a session is made up of a collection of people, groupware components, and shared objects. To provide a sense of virtual place, each session is visualized as a separated session window. Under the menu bar of the window lists all the names (uids) of the on-line participants of the meeting (see Figure 2). Groupware tools used in the session will be opened in the session window. All participants of a session will have a synchronous instance of the session window. Working with the XCHIPS browser component in a session, other groupware components invoked from the browser user interface or from the shared objects in its content pane can be activated using menu operations on the (closed) views of the shared objects. Options of

76

W. Wang, J.M. Haake, and J. Rubart

the menu operations are provided for users to open them in either in the same session window (thus becoming accessible to all users within this session) or in a new session window (providing a simple transition to individual work or a subgroup meeting in a new session). If a meeting takes a long time and needs multiple sessions, we use a meeting process structure to organize it (see next section) and to divide sessions by opening composite objects for different session activities in different session windows. Meeting organizers can invite other users to join their working session by activating the Invite user button at the upper right corner of the session window (see Figure 2). Users can also use a query tool to search for all the active meeting sessions and request to join selected sessions. With the XCHIPS browser, it is very easy to set up a NetMeeting session for audio/video communication and application sharing for all the on-line participants (see the section 4.4 for detail). Users can also activate a Chat groupware component for all the session participants by clicking on the Chat tool button on the user interface. 3.3 Process-Based Meeting Control and Document Handling A process structure can be described as a directed graph consisting of a coordination structure among the steps. Such a graph can be modeled as a typed hypermedia structure (see also [23]). In XCHIPS, the process structure is represented by a set of predefined hypermedia object types: Œ Task nodes, which may carry a description of the task and other information objects (such as embedded links to external documents) as its contents, and which can be related to other resources via specific explicit links, such as a “assign” link from a role (or position). When a task node contains other task nodes connected with process links, it becomes a composite task node that presents a process or a sub process. Thus, processes can be nested and may form a layered graph. This nesting allows for representing the decomposition of work procedures into smaller parts. Task nodes have process-specific attributes, such as state and time, and have process-specific behaviors, such as state transitions and activation of certain actions, Œ Process links, which represent precedence relationship between task nodes. Process links have control flow and data flow behaviors. For example, instances of the process link type “precede" can be used to link tasks and processes into sequences or parallel structures, where each precede link specifies under which condition the successor node can be activated and which documents will then flow from the predecessor node to the successor node, Œ Role (or position) nodes, which specify the responsibility in a process or an organization, Œ Person nodes, placeholders that present actual individuals, Œ Assignment links, which assign a role to a task. Œ Filled-by links, which specify which Roles are assumed by which Persons, and

A Cooperative Visual Hypermedia Approach

77

Œ

Any other nodes or links for additional information, such as information about the goals and objectives of the work process, background information, and resources. Thus, in such a typed hypermedia environment, a process can be represented as graphs consisting of typed hypermedia objects, together with additional information related to the process. For a clear overview of the state of a process, the state information of task nodes is color-coded in their views (white for inactive, yellow for enabled, green for active and brown for completed). Tasks can be performed by menu operations activated on the task nodes. Selecting "enable" and then "activate" menu operations on the root composite task node of a process structure can start the process execution. When a composite task node is "activated", the starting tasks of the process structure nested in the composite task node are "enabled". They can then "activate" their tasks. When the work of a task is finished, its actor can select the "complete" menu operation on the task node, such that its following tasks (or nested starting tasks if it is a composite task node) are "enabled". A process is completed when all its subtasks are completed.

Using such a process-enable hypermedia structure, a meeting process can be created: Œ A meeting process can be modeled using a root task node, which contains other task nodes for meeting sessions and agenda items (meeting activities). Œ Information objects (see section 4.1-4.3) presented and manipulated for each meeting activities can be placed into the task nodes represent the meeting activities before the meeting takes place. Œ

Œ Œ

Meeting specific roles, such as Chairman, Recorder, Presenter, Timekeeper, and Participant can be modeled using Role nodes.

Meeting participants can be modeled using the Person nodes. The meeting roles can be assigned to meeting activities by the assignment relationship. ΠThe meeting role and participant relationship can be specified using filled-by links. The document handling capabilities are integrated into several types of embedded links that can be placed in folders or tasks in a process model (see section 4.12-4.3). The meeting process structure can be modified at the beginning of a meeting or modified on the fly during the meeting. The execution of a meeting process (i.e. the transition from one meeting activity to another) can be manually controlled by the Chairman. Presenter can open documents in his or her task node when the task is enabled. For annotation, or discussion and exploitation activities (tasks), visual artifacts can be used together with the audio or textual chatting communication between meeting participants.

78

W. Wang, J.M. Haake, and J. Rubart

4 Implementation Details The cooperative visual hypermedia as described in previous section has been implemented and supported with a cooperative visual hypermedia browser in our component-based XCHIPS system, which is an extension of the CHIPS system [22-24]. This section focuses on the cooperative visual hypermedia related implementation issues.

4.1 Visualization and Behaviors of Hypermedia Objects A graphical view of a hypertext is a view of its underlying model (instance). It is composed of the views of the objects (nodes) and relationships (links, containment, and visual indications) in the model. If a node has content or if it is a reference to another object, the node will have at least two views: one for its closed view and the other for its opened view (for its content or the referred object). A node that refers to another object or external document (URL) can be seen as an embedded link. In this case, node opening is equivalent to (reference) link following. Each node or link object may have more than one view. In this case, all of them are kept consistently up-to-date with the model of the node or the link. The view and controller object for a closed view has an instance variable pointing to its model object, while the model object has no direct (instance variable) reference to its view object. The changes to a model object are propagated to its view objects by means of an event subscription mechanism. The controlling operations to the hypermedia object can be triggered using the menu available from the view objects. Menu operations available from a link view or a closed node view object include operations collected from both the view object and its underlying model object. We use Groupware Component to implement the opened view of a node. The binding between the model object and the view object for its opened view is resolved at run-time through a model-task-component triple object that is published on the view component object class (see [7] for details). In addition to the explicit links, the layout (e.g. positions and visual properties) of the nodes can also indicate relationships. For instance, for a composite node presenting the structure of an organization, the contained views of nodes and links can be laid out as an organization chart – a top down hierarchical structure whose links are lines with rectangular corners. The content view of a composite node can be provided with a layout manager to automatically layout its components. For manually handled free layout, the positions, bounds and other visual properties are persistently stored so as to assure a stable spatial and visual relationship representation.

A Cooperative Visual Hypermedia Approach

79

4.2 Text, Hand Writing or Drawings, Lines, Shapes, and Images as Hypermedia Objects By default, these view objects are created together with a simple model object, which has a type label and a name attributes. The model object can be changed to other predefined model object types. The pre-defined types include composite model objects types (such as “folder” and “task”) which can contain other node and link objects, an xref model object that can refer to another shared object (see [7]), a href model object that can refer to a read-only external document (see below), or a Webdec model object which can refer to an editable external document (see below). 4.3 Shared Objects as Embedded Links to Shared Documents For integrating document handling into the common information space, two types of shared objects are developed as embedded (cooperative) links to documents on the Web. Œ href is an embedded link for a read-only access to documents on the Web (such as HTML pages and other document types that can be handled by plug-ins of a standard Web browser). The pages or documents are fetched and displayed by the standard Web browser or its plus-in applications. This embedded link is presented as a labeled icon. The behavior of the link is encapsulated in the href object type. Users can activate a menu upon the labeled icon to - set a label, - set a URL, - open a page or document for oneself, or - open it for all the active users in the meeting session. Such a link that opens an external document (or a page) for more than one person (on a number of dynamically selected machines) can be considered as a kind of computed cooperative link. Both the 'open for one' and the 'open for all' methods can also be considered as process links (see the HB/SP series [29] on links and anchors as processes), as they both activate a method (or methods) of a COM object on a local machine (through a Java-COM bridge). The difference between them is that the 'open for all' method sets the 'showForAll' attribute of the href object; while the 'open for one' method not. After the invocation of the 'open for all' method, the changed attribute 'slot' is replicated to all the local proxies of the href object for its distributed users. This value change (i.e. from false to true) in turn triggers a local call to COM APIs. In this case, it is an href method calling for the FollowHyperlink(url) and close() methods of a Word.Document COM Object. The open for all option can be used to do a Web-based presentation using a standard Web browser. For doing so, user can create a sequence of href embedded links pointing to each of the Web pages, and then activate them in a sequel in his or her presentation.

80

Œ

W. Wang, J.M. Haake, and J. Rubart

Webdec is an embedded link for a read-write access to documents on the Web (such as HTML pages and other document types). The pages or documents are fetched and displayed by the Web browser for HTML pages and MS Office tools for MS office documents. This embedded link is presented as a labeled icon view. As the underlying data object of the view is a shared object, many attributes can be defined for the object and be reflected on the view for group awareness purpose. The behavior of the link is encapsulated in the webdoc object type. Among many operations on the object, users can activate a menu upon the labeled icon to - set a label, - set a URL, - check-out and edit (i.e. lock, download, and open) a document from an organizational shared document repository, which can be any Web server that supports the http get and put protocols, and - check-in (i.e. upload and unlock if locked) a document to the shared repository. When a document is checked out for editing, it is locked and a name label appears on the graphical view of the embedded link. The name label provides a kind of group awareness information on who is editing the document. If another person tries to invoke any of the above menu operations, he or she will get a warning message. This message tells him or her that the document is locked and he or she can contact the person for releasing the lock or for setting up a NetMeeting session to share the MS Office application for the document (see next section). The locking is implemented with a locking-service that is a simple implementation derived from the naming service of the XCHIPS system. The upload and download methods used by the check-in and check-out menu operations are implemented initially using the common http get and put methods, and then in a later version using a WebDav [3] based Java package from one of our project partners. The open document method used in the Check-out menu operation is implemented using a COM API, i.e. an open() method of a Word.Document COM object.

4.4 Mobile Groupware Components as Embedded Links to Distributed Applications We use Microsoft NetMeeting for audio/video communication channels and for application sharing (e.g. to share a PowerPoint presentation or to jointly edit a Word document). Because NetMeeting uses a point-to-point network connection, to setup a NetMeeting session for a group of people, the meeting host has to inform all the participants the host machine’s IP address and let them call this address using a NetMeeting client. This is a cumbersome manual process. To make this simple, we develop another type of embedded link, with which the NetMeeting connection for a group of people can be setup easily. Again, here we used a shared object as a wrapper of the NetMeeting COM APIs. Because in this case, we want to allow all the meeting participants to initiate, join or

A Cooperative Visual Hypermedia Approach

81

leave a NetMeeting session, we need to provide them with a user interface to invoke the corresponding COM APIs. For this reason, the shared object has two views: a closed view (shown as an icon) and an opened view, which presented in a separate window (i.e. an Internal Frame within the session window). The closed view is used to invoke the opened view, while the opened view in the separated window provides the graphical user interface for users to setup and control a NetMeeting session. The groupware component can be considered as a computed multi-source process link to the NetMeeting COM objects on the distributed machines of the meeting participants. When one of the participants activates the embedded link and then push the ’host a meeting’ button on the opened view, the user’s machine becomes the NetMeeting host (i.e. the destination of the NetMeeting link). Then he or she can push the 'start a meeting' button to let the NetMeeting client on each all participants’ machine to connect to host automatically (see Figure 2). In this connection process, the link sources (i.e. the NetMeeting clients represented as the IP addresses of all the participants are found from the active user list of the session object that is accessible from the shared object. This is possible as the User object of the system has an IP attribute whose value is automatically assigned when the user is logged on the system. The NetMeeting connection call (through an NetMeeting COM application programming interface with the host IP address as its parameter) is invoked on the local instance of the groupware component (see [7] for detail). When each client invocation is done from each participant’s machine, the NetMeeting host participant gets a dialogue box asking him or her to accept the NetMeeting connection from the client. After that the original NetMeeting control window appears on all the participant’s desktop and the NetMeeting setup is done. Participants can talk to each other and they can also use this control panel to initiate application sharing, passing control to shared application. Using the same techniques, an embedded link (and a groupware component) can be created for doing a PowerPoint presentation for the meeting participants. In this case, the embedded link is a multi-target link; its groupware control panel will has buttons to navigate forth and back in a slide show. This can be used together with conference phone or chat tools in situations when a NetMeeting connection is prevented by firewalls at participants' sites.

5 Sample Use Cases and User Experience EXTERNAL is an IST project on technology support for virtual enterprises. There are five partner organizations distributed in Germany, Norway, and Greece. XCHIPS is one of the tools developed in the project for providing 3C (coordination, cooperation, and communication) and cooperative work management services. The support for distributed meeting is one of its most important services. For testing our own ap-

82

W. Wang, J.M. Haake, and J. Rubart

proach, the XCHIPS system along with other tools developed in the project have been deployed and used in three use cases, one of which is for the joint planning and management of the project. After a period of testing, the first deployment of the XCHIPS system for use cases was in last June, and then a series of revised versions were issued based on the feedback from its use.

Fig. 1. A meeting process description

The following is a description of a distributed meeting use case using the XCHIPS system by the EXTERNAL project management team for distributed project management meetings. The project management team consists of the project coordinator, the work package managers and the site managers of the project. The following use case describes one of the project management meetings. The purpose of the management meeting is to review progress, discuss use case designs, and perform a crisis analysis for identifying important issues that have to be addressed for a successful project. Before the meeting, the organizer (Chairman) of the meeting creates a meeting agenda (in the form of a meeting process structure in a composite task node, which is part of the overall process model for the joint planning and management of the project). The meeting process model includes the status report, user case design, and crisis analysis as its major activities (see Figure 1). Then the Chairman sends an email message to all the participants to inform them the time, the topics, and the (virtual) location of the meeting (i.e. the URL of the meeting process model). Based on the plan, the Presenter of the meeting prepares and then checks-in a PowerPoint file into the “User case design” activity that is assigned to him.

A Cooperative Visual Hypermedia Approach

83

When the meeting time comes, the participants are all logged on to the system, and then are invited into the meeting session by the Chairman. Then one of the meeting participants sets up the NetMeeting tool for all the participants (see Figure 2 for the groupware control panel). As the first meeting activity, the Chairman tries to see if there is any request to adjust the meeting agenda. Then each work package manager reports the status of his or her work package using the audio communication channel.

Fig. 2. A groupware component for NetMeeting

After that the Presenter activates his PowerPoint presentation by selecting the “check-out” menu operation upon a Webdoc embedded link in side of the “Use case design” task. The Presenter shares it with others using the NetMeeting control panel on his desktop. After the presentation and a brief discussion, the Chairman starts the “Crisis analysis” task and opens the task node in the same session for all the meeting participants. Coordinated by the informal audio channel, each participant first posts the issues he or she thinks to be important (see Figure 3), and then they move the vis-

Fig. 3. Collecting important issues

84

W. Wang, J.M. Haake, and J. Rubart

ual cards into several clusters and using explicit links to indicate the relationship among the clusters (see Figure 4). Finally, together with all the participants, the Chairman makes an action list to be carried out after the meeting. During the whole meeting process, the Recorder makes minutes individually using text, scribbles, or other visual components in the content pane of each activity. After the meeting, the Recorder collects his or her notes into a minute (accessible in the Minutes task node) and informs all the participants to see if there are any questions on it. Based on the decisions and action list made in the meeting, the project manager can monitor the execution of the follow-up actions.

Fig. 4. Clustering and linking ideas

From over a year testing and half a year use of the system in the EXTERNAL project, we got numerous comments and feedback from the users. They liked the colorcoding of the meeting agenda items (i.e. the task nodes) and the minute recorded within or accessible from the task node for each meeting activity. As this allows them to see (particularly for the late comers of a meeting) what has been performed, what is on going, and what are the next to come. Other team members who are not able to attend the meeting can navigate the meeting process structure to learn what happened in the meeting and to find and understand the decisions made in its original meeting context. They also liked the ability to write, scribble, post-visual artifacts, and to reorganize them for on-line discussions. The handling of MS documents and its integration into a process structure were considered a useful and practical solution, as all the user organizations of the use case partners of the project have MS Office suite and Windows operating system used in their daily working environment.

A Cooperative Visual Hypermedia Approach

85

Users have also experienced many problems on using the system. As both the XCHIPS and the NetMeeting require the user organizations to open certain ports for inbound TCP/IP communications. One of the problems is with the firewalls. We resorted to the help of the system administrators and even the management of the organizations for opening the port or to deploy machines in a de-military zone of their Intranet settings. But still we have got one user organization refused to do so. For these reasons, in many situations, we have to use conference phone instead of NetMeeting for voice communication. This also motivates us to develop Web-based presentation tools (as mentioned in section 4.3-4.4) that do not have a firewall problem. Another experience we got is that even a NetMeeting session can be setup, participants still prefer to use conference phone for voice communication, as it provides a better sound quality. In these cases, the common workspace provided by XCHIPS was considered by most meeting participants a good aid for presentation and discussion. Our experience suggests that the system is better suited for short distributed meetings of a small group of people. We still have a long way to go before we can use such systems to replace long lasting (i.e. over one day) face-to-face project meetings of a large group of people.

6 Related Work The hypertext technology most closely related to our cooperative visual hypermedia is spatial hypertext, such as the spatial and visual hypertexts supported by Aquanet, Viki [12], VKB [5] and CAOS [18]. Our cooperative visual hypermedia supports a kind of mixture of multi-domain visual hypertext structures, including spatial, set-based, navigational, automaton-based, and cooperative hypertexts. This kind of hypertext extends spatial hypertext with a set of ready-made visual hypermedia objects that is not only visual, but also has pre-defined computational semantics (i.e. each view object has an application specific model object behind it). It also provides ad hot visual hypermedia objects (text, hand drawings, filled or unfilled shapes, images) created-on-the-fly in a shared information space. It supports multiple views (i.e. view objects) on the same model objects. These view objects can form multiple classifications or groupings (i.e. alternative views) on the same set of hypermedia objects. In addition, it includes explicit links that are missing in set-based spatial hypertext. These explicit links can enrich the explicit relationship expressiveness and the computational semantics (as demonstrated by the process links) of spatial hypertext. Other enhancement to existing spatial hypertext is the cooperative manipulation of visual artifacts and the cooperative document handling upon Web-based repositories. Among meeting support systems, the one nearest to ours is the Dolphin system from our group a few years back [14]. Dolphin addressed a much wider range of meeting support issues, such as user interaction on large display in a meeting room and support meetings held in multiple meeting rooms. Dolphin also provides a hypermedia-based whiteboard as a common information space. While XCHIPS focuses on desktop based virtual meeting support for distributed teams. What XCHIPS adds to

86

W. Wang, J.M. Haake, and J. Rubart

Dolphin and other cooperative hypermedia systems developed in our group ([22-23, 7]) are the integrated process support, document handling, meeting management, and a rich set of visual artifacts for supporting distributed meetings. Nest, in the sequel, we discuss several areas of meeting support systems in relation to our approach and our XCHIPS system: ΠDesktop Teleconferencing: In addition to available desktop-teleconferencing functionality as provided by NetMeeting and WebEx, our approach also provides meeting oriented conference control as well as meeting specific functionality (e.g., agenda or meeting process planning). ΠVideo-conferencing rooms (e.g., media spaces [10]): XCHIPS may also be used in electronic meeting rooms with large displays and at the same time it can integrate well remote desktops for participants no available in the rooms. ΠShared documents (e.g., asynchronous shared workspace systems BSCW [2] and WebDav [3]; cooperative hypermedia systems KMS, rIBIS; meeting room systems Group Systems [15], CoLab [20]; Shared editing tools of GROVE [4], ShrEdit [13]; and shared drawing tools of GroupSketch [6] and CaveDraw [9]: Whereas shared document systems enable shared viewing or shared editing of isolated documents, XCHIPS exploits CSCW and hypermedia technology to facilitate rich information structures and seamless process support through the provision of shared workspaces, including traditional linear documents and hypermedia structures as well as support of transitions between different meeting phases. Further more, the use of multimedia functionality inherent in hypermedia will support the integration of different pieces of information without introducing media breaks. ΠAsynchronous collaboration support (e.g., bulletin boards, e-mail or workflow management systems): In contrast to asynchronous collaboration tools, which can only support the exchange of information or describe schematic, well-structured processes, XCHIPS bridges the technology gap and integrate schematic workflow with unstructured phases of the business process, where flexible ways of problem solving, coordination and collaboration support are required.

7 Conclusions Business processes of today are characterized by a change from individual work to teamwork as well as by a shift from single, independently acting corporations to virtual organizations operating as dynamic networks. To realize the benefits of globalization and business networking, we have to find a way for teams of knowledge workers effectively work together across distances and time zones. Efficient and effective technology support for distributed meetings is a key to virtual organization effectiveness. However, current distributed meeting support systems lack support for a wellplanned flexible meeting process, lack a common information space with structurerich visual artifacts, and lack the support for document handling.

A Cooperative Visual Hypermedia Approach

87

Our approach to tackle the problems is to develop a cooperative visual hypermedia for providing Œ a common information space with structure-rich visual artifacts, Œ flexible meeting process modeling and control, Œ integrated document management, and Œ cooperative session-based meeting management and easy setup of communication and application sharing channels for a meeting session. Two use cases are presented, which show that using the cooperative visual hypermedia, distributed teams can perform many kinds of meetings, in the meantime, enjoying dedicated support for the planning, control, information management, and follow-up activities of a distributed meeting. In terms of hypertext technology and its application to distributed meeting support, our approach has a number of innovation aspects: Œ The cooperative visual hypermedia integrates many visual and interaction features found in multiple hypertext domains including cooperative hypermedia, spatial hypermedia, navigational hypermedia, and automaton-based workflow hypermedia [21–23]. Œ It demonstrates the possibility and usefulness of the co-existence of multi-domain visual hypermedia structures for supporting distributed meetings. Œ It provides flexible meeting process support and a common information space for meeting planning, flexible meeting process modification and execution, and follow-up activities (to be carried out in either synchronous or asynchronous cooperation). I.e. it provides a seamless transition between synchronous cooperation and asynchronous cooperation. Œ It integrates document handling into the meeting process structures. More importantly, it can connect and integrate multiple meeting processes into the whole organizational business (process) context. Œ The cooperative embedded links for opening external documents for multiple distributed users and the cooperative embedded links for controlling external applications cooperatively are new to existing hypertext linking mechanisms. To be successful in providing virtual meeting support, we must integrate people, processes, and technology. Our cooperative visual hypermedia approach have used explicitly (visually) represented knowledge about the task at hand, the domain of discourse, and the set of participants involved to improve meeting process. It allows more flexibly move between and integrates different kinds of meetings or a series of meetings into a large business context. It makes contextual information persistently available when moving between different meeting processes. This makes it easier to integrate such environment with the enterprise-wide knowledge and project management systems as well as with the personal work environments of individual knowledge workers. This contrasts sharply with the currently available teleconferencing systems, which are stand-alone generic facilities with very limited capabilities.

88

W. Wang, J.M. Haake, and J. Rubart

Distributed meeting support involves a wide range of technical and social issues, and may use a wide range of communication and groupware technologies. In this work, we made a focus on distributed desktop-based meeting support for small group meetings. From our experience with the Dolphin system, this system can also be used for co-located meetings and the meetings with a mixture of co-located and distributed team members. For this potential, many useful features of the Dolphin system [25] could be re-established. We are also interested in the integration of mobile devices for remote meeting participants. As the current NetMeeting system has difficulties with firewalls, we are looking for alternative audio communication and application-sharing solutions that support http tunneling so as to have a better Web-based integration of our cooperative hypermedia based solutions. Currently one of our EXTERNAL project partners is performing evaluation on the XCHIPS system and other EXTERNAL tools, and we are cooperating with them for both feedback and findings.

Acknowledgments. We would like to thank our EXTERNAL project partners for feedback and discussions on the usage of the tools reported in the paper.

References 1.

2.

3. 4. 5.

6.

7.

8. 9.

Akscyn, R. M., D. L. McCracken and E. A. Yoder, "KMS: A Distributed Hypermedia System for Managing Knowledge in Organizations,"Communications of the ACM, v. 31, no. 7, July 1988, pp. 820-835. 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. 6374. E. James Whitehead, Jr. WebDav, in Proceedings of ACM Hypertext’01, pp. 259, Aug. 1418, 2001. Ellis, C.A., Gibbs, S.J., and Rein, G.L. Groupware: Some issues and experiences. Communications of the ACM 34, 1 (Jan. 1991), 38-58. Frank M. Shipman III, Haowei Hsieh, Preetam Maloor, J. Michael Moore, The Visual Knowledge Builder: A Second Generation Spatial Hypertext, in Proceedings of ACM Hypertext’01, pp 113-122, Aug. 14-18, 2001. Greenberg, S., and Bohnet, R. Group Sketch: A multi–user sketchpad for geographically distributed small groups. In Proceedings of Graphics lnte@aces'91 (June 5-7, Alberta, Canada), 1991, pp. 207-215. Jessica Rubart, Joerg M. Haake, Daniel A. Tietze, Weigang Wang "Organizing shared enterprise workspaces using component-based cooperative hypermedia", in Proceedings of ACM Hypertext2001, pp 73-82, Aug. 14-18, 2001. Kevin Wolf., "The Makings of a Good Meeting", 1994, available at http://www.dcn.davis.ca.us/go/kjwolf/manual.html Lu, I., and Mantei, M. Idea management in a shared drawing tool. In Proceedings of the European Conference on Computer-Supported Cooperative Work (EC-CSCW '91). (Sept. 24-27, Amsterdam), 1991, pp. 97-112.

A Cooperative Visual Hypermedia Approach

89

10. Mantei, M., Baecker, R., Sellen, A., Buxton, W., Milligan, T., and Wellman, B. Experiences in the use of a media space. In Proceedings of the CHI ’91Conference (New Orleans, Louisiana), 1991. 11. Marilyn Manning, "Meetings Bloody Meetings", available at http://www.mmanning.com/Articles/MeetingsBloodyMeetings.html, Reprinted from March 1998 issue of Channel Magazine 12. Marshal, Catherine C and Shipman III, Frank M.: Spatial Hypertext and the Practice of Information Triage. In proc. of ACM Hypertext’97, pp : 124-133 13. McGuffln, L., and Olson, G. M. ShrEdit: A Shared Electronic Workspace. Technical Report No. 45, University of Michigan, Cognitive Sciences and Machine Intelligence Laboratory, 1992. 14. N.A. Streitz, Joerg Geissler, Joerg M. Haake, J. Hol DOLPHIN: Integrated Meeting Support across LiveBoards, Local and Remote Desktop Environments. In: Proceedings of the 1994 ACM CSCW’94, pp. 345-358, N.C., October 22-26, 1994 15. Nunarnaker, J .F., et al. Electronic meeting systems to support group work. Communications of the ACM 34,7 (July 1991), 40-61. 16. Paul Kahn, Information Architecture: a New Discipline for Organizing Hypertext, Opening keynote speech at Hypertext’01, in Proceedings of ACM Hypertext’01, pp. 1, Aug. 1418, 2001. 17. Rein, G. L., Ellis, C. A., rIBIS : a real-time group hypertext system, International Journal of Man-Machine Studies, 1991, volume 34, pages 349-367. 18. Reinert, O., Bucka-Lassen, D., Pederson, C.A., Nuernberg, P.J. CAOS: A Collaborative and Open Spatial Structure Service Component with Incremental Spatial Parsing. In Proceedings of Hypertext’97, ACM Press, Southamton, U.K., pp. 49-50 19. Roseman, M., and Greenberg, S. TeamRooms: Network Places for Collaboration. In Proceedings of CSCW’96, ACM Press, Cambridge, MA, 1996. 20. Stefii, M., et al. Beyond the chalkboard: Computer support for collaboration and problem solving in meetings. Communications of the ACM 30, 1 (Jan. 1987), 32-47.27. 21. Stotts,P.D.and Furuta, R. 1989. Programmable browsing semantics in trellis. In Proceedings Hypertext ’89. Pp 27-42. 22. Weigang Wang "Team-and-Role-based Organizational Context and Access Control for Cooperative Hypermedia Environments", in Proceedings of ACM Hypertext’99, pp 37-46, Feb 23-25, 1999 23. Weigang Wang and Joerg M. Haake, "Flexible Coordination with Cooperative Hypermedia", Proceedings of ACM Hypertext’98, pp. 245-255, June, 1998

Towards UML-G: A UML Profile for Modeling Groupware Jessica Rubart1, 2 and Peter Dawabi1 1 Fraunhofer

Institute for Integrated Publication and Information Systems (IPSI), Dolivostrasse 15, 64293 Darmstadt, Germany 2 go4teams GmbH, Julius-Reiber-Strasse 15a, 64293 Darmstadt, Germany {rubart, dawabi}@ipsi.fhg.de

Abstract. Groupware is explicitly designed to support the cooperation among group members. The implementation of cooperation-aware groupware is supported by several object-oriented toolkits and frameworks, but there is no unified way to model applications built on top of these. We propose UML-G as an extensible UML profile for modeling groupware and want the community to contribute to it. We identify groupware specific modeling needs related to shared data modeling. Since these needs are not addressed by standard UML, we define UML-G’s shared data modeling part. Usage scenarios demonstrate how UML-G can be used to assist groupware modeling. UML-G supports explicit modeling of groupware related needs. Moreover, a shared understanding between developers is backed, which abstracts from the implementation. In addition, CASE tool support for UML-G strengthens its practical relevance.

1

Introduction

Groupware, such as Computer-Supported Cooperative Work (CSCW) and Learning (CSCL) applications, are explicitly designed to support the cooperation among group members [10]. This might be in a distributed or co-located setting. In addition, it might be synchronous or asynchronous. Synchronous cooperation means cooperation happening at the same time with typically fine-grained notifications giving immediate feedback about the activities of other users, whereas asynchronous cooperation can happen at different times with usually no notifications of other users’ actions [14]. The implementation of cooperation-aware groupware is supported by several object-oriented toolkits and frameworks, but there is no unified way to model applications built on top of these. The Unified Modeling Language (UML) [17, 22] is the standard notation for modeling object-oriented software. A UML Profile specializes the UML for a specific domain. We propose such a profile for groupware (UML-G) in order to assist developers in explicit modeling of groupware related needs, such as shared information.

J.M. Haake and J.A. Pino (Eds.): CRIWG 2002, LNCS 2440, pp. 93–113, 2002. © Springer-Verlag Berlin Heidelberg 2002

94

J. Rubart and P. Dawabi

There are several groupware tools available, such as e-mail systems, shared repositories, shared workspace systems, e.g. BSCW (Basic Support for Cooperative Work) [2], audio/video-conferencing, shared whiteboards or sharing support for single user applications. Sometimes it is sufficient for groupware developers to select a single-user tool, such as an office suite’s word processor, and combine it with a shared repository in order to support asynchronous editing of documents. To support synchronous editing, sometimes it is sufficient to combine the word processor and the shared repository with an application-sharing tool, such as Microsoft’s NetMeeting [27]. But there are also obvious restrictions, e.g. by using an application-sharing tool only strict WYSIWIS (What You See Is What I See) functionality can be supported. Moreover, no workspace awareness (if there is any workspace) can be given - in the sense of an up-to-the-moment understanding of another person’s interaction [12]. That’s why application-sharing tools belong to the cooperation-transparent class of groupware. To develop new cooperation-aware applications, object-oriented toolkits and framework, e.g. DistView [19], GroupKit [20], COAST [23], JSDT [3], Habanero [4] and DyCE [29] have become available. All these toolkits and frameworks have their special way of using them. There is no unified way to model applications built on top of these. In this paper, we identify groupware specific modeling needs related to shared data modeling. We propose a modeling language, UML-G, supporting groupware specific modeling needs and designed as an extensible UML profile. With this language, groupware developers are supported in modeling their cooperative applications independent from the latter implementation. This supports œ explicit modeling of groupware related needs, and œ a shared understanding between developers, which is independent of and thus abstracts from the latter implementation. The remainder of this paper is organized as follows: The next section deals with a problem description related to shared data modeling, which leads to a list of requirements UML-G has to fulfill. Then, UML extensions are defined for UML-G, which address the identified requirements. Afterwards, usage scenarios are presented that utilize UML-G’s current shared data modeling part. Next, we talk about CASE (Computer Aided Software Engineering) tool support for UML-G in order to strengthen its practical relevance. Afterwards, related work is presented. The paper ends with conclusions and plans for future work.

2

Requirements: A Problem Description Related to Shared Data Modeling

This section identifies core requirements for modeling groupware. First of all, both, asynchronous and synchronous cooperation – in a distributed as well as co-located setting, work on shared information – either at the same time or at different points in time. Therefore, this is our first requirement: R1. A modeling element marking shared information is needed.

Towards UML-G: A UML Profile for Modeling Groupware

95

Asynchronous cooperation requires persistent data; otherwise different persons at different points in time can’t continue work. In addition, if synchronous work needs to be continued later or at least the results need to stay available, persistence is also required for synchronous cooperation: R2. Shared information requires the option to be modeled as persistent. Synchronous cooperation requires notifications of other users’ interactions since it is explicitly designed to support simultaneous work. These notifications are also important for the provision of awareness. Hence, changes of shared information may need to be propagated: R3. Notifications on shared information need to be supported. Since several users access shared information, access control might be necessary. Therefore, there is a need for modeling access-controllable shared information: R4. Shared information requires the option to be marked as accesscontrollable. Groupware toolkits and frameworks usually provide concurrency control mechanisms so that shared data is kept consistent though multiple users access it simultaneously. But it might be necessary due to some semantics of the cooperative application that shared information should be explicitly locked, e.g. when using floor control mechanisms. Floor control can be used to moderate the cooperation. Only one person at one point in time is in charge of the floor and hence able to change some shared information. Locking is independent from the users who access the shared data so that it differs from access control (note that this requirement does not address the usage of concurrency control techniques, such as optimistic and pessimistic concurrency control – see future work): R5. Shared information requires the option to be marked as lockable. Users of cooperative applications need a model of themselves so that for instance access control mechanisms can be applied to them. In addition, users can be interested in information about other users or awareness regarding users can be necessary. In general, we are talking about actors, such as users, teams or even system parts, which are designed as user representatives. Actors need a model of themselves. Moreover, actors can fill roles. This leads to our last core requirement we have identified: R6. Shared models of groupware actors and roles need to exist. The following table summarizes the identified requirements: Table 1. Summary of Requirements for Modeling Groupware related to Shared Data Modeling

R1 R2 R3 R4 R5 R6

Shared information Persistent shared information Notifications on shared information Access control on shared information Lockable shared information Shared models of groupware actors and roles

96

3

J. Rubart and P. Dawabi

Towards UML-G

Based on the identified requirements we have designed a shared data modeling part of UML-G by using the extension mechanisms of UML. The shared data modeling part itself is designed in an extensible manner, too. 3.1

Extension Mechanisms of UML

UML provides three mechanisms for extension: stereotypes, tagged values and constraints. Stereotypes classify other UML elements and thus represent variations of them with the same structure, but a different intent, respectively. In general, a stereotype represents a usage distinction. Tagged values are (Tag, Value) pairs attaching information to a model element and thus representing properties. Constraints allow the specification of new semantics (a condition or restriction) for a model element linguistically in some textual language. For details see [17]. A UML profile is a predefined set of stereotypes, tagged values, constraints, and notation icons, which tailor the UML for a specific domain. Such a profile does not extend the metamodel of the UML (that defines classes, attributes, stereotypes etc.), but it provides modeling elements for specializing standard UML to a particular domain. This has the advantage that CASE tools supporting the UML extension mechanisms can be configured to support modeling with the profile (see section 5). Since the UML specification does not provide a formal approach for defining the semantics of new stereotypes, tagged values and constraints, we describe the semantics of UML-G informally. 3.2

Syntax and Semantics of UML-G’s Current Shared Data Modeling Part

According to the requirements we have one basic model element that is shared information (R1). This model element can be further specified by e.g. lockable or persistent. Therefore, we have introduced the stereotype <<shared>> and decided to define constraints or tagged values on it to extend its semantics. The stereotype <<shared>> applies to the UML baseclass Element, which is the class in the UML metamodel at the very top of the inheritance tree. Thus, the stereotype <<shared>> can be applied to any UML model element. Instances of elements marked as <<shared>> are potentially accessible from all users. This is meant completely independent from the latter implementation – whether it will be realized by e.g. using a replicated architecture, one-to-many communication channels or remote objects. A shared element can be further specified by the Boolean tagged value {lockable} in case it is used in a scenario where for example floor control needs to be supported (R5). We have chosen a Boolean tagged value in order to indicate whether locking needs to be supported or not. If the cooperative application developer wants to specify the locking in more detail, she can use standard UML model elements, such as associations and OCL (Object Constraint Language) constraints [31]. We haven’t yet identified specific OCL constraints,

Towards UML-G: A UML Profile for Modeling Groupware

97

which need to be predefined in the profile. Note that you can leave out the value of a Boolean tag, if it is set to TRUE. Similarly, we have designed the extensions {access-controllable} and {observable} (R4, R3). A shared model element can be marked as {access-controllable}, which means that during runtime access control mechanisms can be applied. It can be marked as {observable} to express that notifications about changes are possible. This is important to support synchronous cooperation, which usually needs fine-grained notifications. We have chosen the term observable in order to use a more active term. And again, by using e.g. associations and OCL constraints from standard UML more details on the semantics can be expressed by the groupware developer. A persistence Boolean tagged value (R2) is already available in standard UML and is defined on the model elements association, attribute and classifier (which is a supertype of e.g. class). Hence, it can be easily combined with UML-G. If we need this tag on other UML model elements as well, we need to define it. For now, the existing tag is sufficient. In order to model roles and actors of cooperative applications (R6), we have introduced the stereotypes <<sharedRole>> and <<sharedActor>>. We have defined them as subtypes of <<shared>> (see Fig. 1) so that the Boolean tags {accesscontrollable}, {lockable} and {observable} can also be applied to them. <<stereotype>> shared

<<stereotype>> sharedRole

<<stereotype>> sharedActor

Fig. 1. Stereotype-Framework

This is important since according to the requirements, models of groupware users are also shared information, on which e.g. notifications regarding changes need to be possible. For example, it need to be notified whether a user is online or offline. In addition, <<sharedRole>> and <<sharedActor>> are separate stereotypes in order to mark their special meaning. With <<sharedRole>> roles in cooperative sessions are marked and with <<sharedActor>> actors in cooperative sessions are marked that can take several roles. Adding new sub-stereotypes in order to make explicit special shared information can extend this “stereotype-framework”. These sub-stereotypes inherit the possibility to apply the Boolean tags {access-controllable}, {lockable} and {observable} to them. Moreover, additional tagged values or special constraints can be defined on the general stereotype <<shared>> or on special sub-stereotypes. Furthermore, a sub-stereotype can specialize the baseclass to which it applies by naming a subclass of the parent-stereotype’s baseclass. We defined for instance that the stereotypes <<sharedRole>> and <<sharedActor>> apply to classes, rather than to any model element. For the super-stereotype <<shared>> it is important to apply to other model elements than classes as well. In the following, some examples are given: The stereotype

98

J. Rubart and P. Dawabi

<<shared>> applied to attributes is needed in order to support higher granularity. It can be that a groupware developer wants to model some attributes as shared, but not the whole class. If the whole class is marked as <<shared>>, this is synonymous with marking each attribute as <<shared>>. In addition, if a shared class is marked with tags, these tags apply to each attribute since all of them are shared. The stereotype <<shared>> applied to events is important for state and activity diagrams in order to express shared events, e.g. if a user does something special on the user interface, then for other users having the same view this is done automatically. A shared event can be locked for example in order to disallow a special activity on the user interface until a special constraint is fulfilled. The stereotype <<shared>> applied to messages is important for sequence and collaboration diagrams to express shared messages. If a user sends a shared message to an object, then for other users accessing the same object this message should be sent, too. A shared message can be observable for example in order to express explicitly that other users are notified about sending this message. The stereotype <<shared>> on associations expresses potentially accessible associations for all users so that all users can e.g. navigate via this association to related object(s) in case the association is not hidden due to for example access control mechanisms. Table 2 summarizes the defined UML-G elements and briefly describes their semantics (we do not include icons for the different stereotypes yet). Table 2. Summary of UML-G’s current Shared Data Modeling Part Name <<shared>>

Type Stereotype

Applies to Element

<<sharedRole>>

Stereotype

Class

<<sharedActor>>

Stereotype

Class

{access-controllable}

Boolean Tag

{lockable}

Boolean Tag

{observable}

Boolean Tag

Stereotype <<shared>> Stereotype <<shared>> Stereotype <<shared>>

3.3

Description Instances are potentially accessible from all users. Subtype of <<shared>>; marks roles in cooperative sessions Subtype of <<shared>>; marks actors in cooperative sessions Access control mechanisms can be applied to instances. It is possible to lock instances. Notifications about changes of instances are possible.

Telepointer Example

This subsection gives a brief example on how to use the defined UML extensions. A telepointer appears exactly at the same position on every participant’s screen. Often it is visualized as an arrow. Users can move telepointers to point to some part of a shared document.

Towards UML-G: A UML Profile for Modeling Groupware

99

An example telepointer class is detailed in the class-diagram of Fig. 2. It is associated with the roles Tutor and Learner, instances of which represent roles participating in cooperative sessions. That’s why both classes – Tutor and Learner – are marked with the stereotype <<sharedRole>>. Both associations are named move because the actors filling the roles are allowed to move the telepointer, i.e. to change the Xpos and Ypos attributes. For this reason, the Telepointer class is marked as <<shared>>. The semantics of the stereotype is extended by the Boolean tagged value {lockable} because in this example a tutor needs to have the functionality to lock the access to the Telepointer, i.e. by using it exclusively. Additional OCL constraints assigned to the association(s) can be used to detail the locking. <<shared>> Telepointer {lockable, observable, access-controllable}

1

Xpos: Integer Ypos: Integer 1

getXpos(): Integer getYpos(): Integer setXpos(Integer) setYpos(Integer)

<<shared>> 0..n move

<<share d>> move

0..m

<<sharedRole>> Tutor

<<sharedRole>> Learner

Fig. 2. Telepointer Example

The tag {observable}, applied to the whole class, indicates that notifications on changes regarding all attributes need to be supported. This is because learners and tutors are able to observe the movements of a telepointer visualization. The tag {access-controllable} indicates access control to the telepointer. In this example, tutors need to be able to control the access. Additional OCL constraints assigned to the associations can be used to detail the access control. Both associations are marked as <<shared>> since it is visible who at one point in time accesses the telepointer. Note that a coupling degree, i.e. how many users use the same telepointer, can be specified by cardinalities of the associations. 3.4

Relations to Design Patterns

To simplify Fig. 2, the presented class diagram focuses on data modeling and not on the visualization. Note that also visualization classes or only attributes of them can be marked as <<shared>> of course. UML-G does not enforce any design pattern. A pattern names a design structure as a solution to a problem in a particular context and thus increases our vocabulary [9]. It’s like a template that one can apply in different situations. UML-G can help writing down object-oriented design patterns for groupware in a framework-independent way. Fig. 3 shows for example a groupware pattern, which we call shared state.

100

J. Rubart and P. Dawabi

It defines a many-to-one relationship between an object and its shared state so that a flexible coupling degree (i.e. which objects share the same state) is supported. UMLG helps to mark the SharedState class as shared information without going into any framework-dependent details.

Object

n

1

<<shared>> SharedState

Fig. 3. Shared State Groupware OO Pattern

In addition, UML-G can be extended to include any groupware pattern explicitly, e.g. a Boolean tagged value {sharedState} can be introduced in order to specify that the pattern needs to be applied on a given class without specifying the details of it. Additional patterns for groupware, which can be reflected in an object-oriented pattern, can be found in [11]. Moreover, a CASE tool can be tailored to perform an automatic transformation to the pattern. The pattern in turn can be taken into account by the CASE tool in order to generate code for a special framework or toolkit (see section 5).

4

Usage Scenarios

This section presents two usage scenarios in order to illustrate the applicability of UML-G in two of our projects. It demonstrates the practical relevance of UML-G for modeling groupware. The first example is related to a cooperative laboratory environment and focuses on group members and access to shared artifacts. The second scenario is concerned with cooperative hypermedia and complements the first one by combining UML-G with the persistence Boolean tag from standard UML, a UML constraint as well as object and state diagrams. 4.1

CoopLab

This usage scenario origins from an internal project named CoopLab, which is cur3 rently embedded in the L project [32]. In CoopLab we develop a Java-based virtual learning environment for biotech and other kind of experiments [5, 6]. One project goal of CoopLab is the development of a software framework with the aim to simplify the implementation of cooperative virtual laboratories. The framework is called CoopLab because an important aspect of the framework is to enable cooperative learning in virtual labs. Each virtual scenario consists of several workbenches, whereby each one provides a scenario for a special part of an experiment (see Fig. 4). The framework itself is designed according to a Model-View-Controller approach. A corresponding model, view and a controller class implement each lab device or tool.

Towards UML-G: A UML Profile for Modeling Groupware

101

While the controller and the view classes are responsible for user interaction and visualization, the model class implements the internal behavior and functionality of a virtual device or tool. An icepot in a (real world) biotech lab for example has the function to cool down devices like reaction tubes. The icepot, which is implemented in our virtual lab, can carry up to three tubes in different orders (see Fig. 4) and has an analogous function in the virtual lab. The tools and devices, which are in usage by a tutor or student, are visually marked by [Tutor: GM] and [Student: GM<m>] to identify the corresponding group members.

Fig. 4. A Shared Virtual Lab

As a small usage scenario we show the classes IcePot and Tube from the internal model of the framework application and combine it with the classes Tutor and Student in a class diagram by using our shared data modeling extension of UML-G (see Fig. 5). The classes Tutor and Student model the different roles a user can adopt in a virtual lab scenario. The class Tutor implements the role of a Tutor in the virtual lab. Analogous to the real world a tutor has the task to supervise and assist the other users during a virtual experiment. Dealing with an icepot in a cooperative lab scenario, we need a tutor who directs one or more students with inserting one or more reaction tubes into the icepot in order to keep them cooled (virtually), when the experiment protocol requires it. The tutor of such a shared experiment uses the icepot in the virtual lab mainly as a demonstration platform and less for the purpose of fulfilling the next step of the experiment. Re-

102

J. Rubart and P. Dawabi

garding cooperation in a virtual lab it is important for the participating students to be able to observe the actions of the tutor. Vice versa the system should provide the functionality that the students can be observed while doing a working step in the virtual lab. <<shared>> IcePot {lockable, observable} maxNumberOfContainers: Integer containerPos1: Container {access-controllable} containerPos2: Container {access-controllable} containerPos3: Container {access-controllable} fillContainerPos1(Container) fillContainerPos2(Container) fillContainerPos3(Container) addContainer(Container) removeContainer(Container) <<shared>> uses 1 {access-controllable} 1

1

>> ed ar s h s e << us

1

*

directs

1

<<sharedRole>> Tutor

<< s co hare nta d> ins >

0.. 3

<<shared>> uses 1{access-controllable} *

<<shared>> Tube {lockable, observable} *

1

<<sharedRole>> Student

1

<<shared>> uses

Fig. 5. The Class IcePot and some of its Associated Classes

A typical cooperative situation is that a tutor demonstrates a task (for example: “Insert tube A into the icepot”) and the students are able to watch and repeat it. In analogy to real world experiments the tutor needs to be able to observe the actions of the students, whenever he likes to do it. But in contrast, the students only have the possibility to watch the tutor, when they have got the permission. In Fig. 5 you see the class diagram of the class IcePot and the corresponding classes Student and Tutor, which are marked with the stereotype <<sharedRole>>. The associations between Tutor and Icepot as well as Student and IcePot are named uses. Furthermore, both associations are stereotyped <<shared>>. This stereotype for associations means that the associations are shared with respect to visibility and changeability. A Tutor needs to recognize at any time, which objects a student is dealing with at the moment. Besides, he needs to be able to restrict the visibility of his own associations – in this case his interactions – with objects of the virtual lab. For this reason the association between Tutor and Icepot is in addition marked as {accesscontrollable}. The association named directs between the classes Tutor and Student

Towards UML-G: A UML Profile for Modeling Groupware

103

shows the connection between the roles. This association is not stereotyped <<shared>> because it is not supposed to be visible between the users. The class Tube, which is aggregated by IcePot is stereotyped <<shared>> in order to indicate that it needs to be visible for all users, how many tubes are aggregated by an instance of IcePot. The associations between the class Tutor and Tube as well as Student and Tube are also stereotyped <<shared>> so that they are shared with respect to visibility and changeability. In addition, the association between Tutor and Tube is access controlled (compare associations to IcePot). Both, the IcePot and the Tube, are marked as {lockable}. This is due to the fact that a tutor can lock the usage of a virtual tube. This is needed when the tutor demonstrates something and does not want to be interrupted by a student who wants to handle the same shared tube in the virtual lab synchronously. Another tagged value {observable} is attached to the classes Icepot and Tube to indicate that all elements of the classes are observable by all other classes. As a precondition the classes themselves are stereotyped as <<shared>>. In Fig. 5 you can see that the tagged value {access-controllable} is also applied to special attributes. It indicates that these attributes are access controlled. In this case, an instance of the class Tutor is able to restrict the usage. This can be further specified by e.g. OCL constraints. 4.2

XCHIPS

This usage scenario is related to the European project EXTERNAL (“EXTended Enterprise Resources, Network Architecture and Learning) [7]. There, we use shared hypermedia workspaces for supporting dynamic networked organizations in developing and performing joint business processes. For this we have developed the cooperative tool XCHIPS (“eXtensible Cooperative Hypermedia with Process Support”) (21, 30). With XCHIPS, users can cooperatively model and execute business processes. Fig. 6 shows three users working in an XCHIPS session. They have modeled a process with the steps Initial planning, Negotiation, and Approval, surrounded by Start and Finish. In addition, they have assigned responsibilities to the different tasks. XCHIPS shows awareness information regarding who has currently opened which tasks. The Initial planning task for example is currently being worked on by rubart and dawabi. The underlying data model of XCHIPS is a shared hypermedia model. Fig. 7 gives a basic overview over this model and makes use of UML-G. A basic hypermedia model is characterized by a node-link paradigm [16]. Nodes are connected by links. Composites allow nested hypermedia structures. In XCHIPS, we have a special composite Task and a special link Flow to model workflow. A process is represented as a set of shared hypermedia tasks connected by

104

J. Rubart and P. Dawabi

Fig. 6. XCHIPS Browser

shared hypermedia flows. Such a hypermedia-based process representation can contain associated materials because the shared hypermedia structure is not limited to tasks and flows. In this way, process support is combined with information management. All instances of these types are shared. That’s why the general hypermedia class (HMObject) is marked as <<shared>>. <<shared>> HMObject {observable, persistence}

Node

Composite

Link

Task

Flow

Fig. 7. Cooperative Hypermedia Model with UML-G

The subclasses inherit the <<shared>> stereotype. In addition, all instances of HMObject stay persistent. This is important because all processes and related information serve as experiences, which need to be accessible from members of later joint projects so that they can learn from and reuse the experiences. They could for example clone a successful business process and adapt it to the requirements of the new project. In standard UML, a persistence Boolean tag is already defined, which also applies to classes so that it can easily be combined with the UML-G extensions in Fig. 7. In

Towards UML-G: A UML Profile for Modeling Groupware

105

addition to the persistence Boolean tag, we have used the observable Boolean tag on order to express that all changes on instances of HMObject need to be propagated. Combination of a UML Constraint and UML-G 4.2.1 Fig. 6 shows awareness information on the task Initial planning, which means that the referring users have currently opened the task. Fig. 8 shows our Task class with its inherited stereotype and tagged values. Instances of it may be associated with a number of rectangles (boxes) visualizing tasks in XCHIPS browsers. <<shared>> Task {observable, persistence} isOpenedBy: Vector getIsOpenedBy(): String

TaskRectangle

assign to {box.getBottomText() = task.getIsOpenedBy()}

1 task

* box

bottomText: String getBottomText(): String setBottomText(text: String)

Fig. 8. The Tagged Value {observable} Detailed by a Constraint

Each task has an attribute isOpenedBy indicating who has currently opened the task. The {observable} tag models explicitly that changes need to be notified. This includes the information on who has opened the task. To detail this, Fig. 8 uses a constraint, expressing that the bottom text of a task rectangle needs to equal the names of the users who have currently opened the task. Object and State Diagrams Using UML-G 4.2.2 An object or interaction diagram is a collaboration diagram or a sequence diagram. Both focus on messages between objects in special contexts. A sequence diagram points out the temporal order of messages (a message asks an object to execute an operation. Operations are implemented by methods). A collaboration diagram explicitly shows the object relationships. Fig. 9 shows a sequence diagram using UML-G. It presents that a user can create a task. After a task exists, a user may open it. This open message to a task is modeled with <<shared>> in order to express that all users participating in the XCHIPS session share opening a task. This means that, if one user opens the task, it gets opened for the others, too. The {observable} tag makes explicit that the other users are notified about this message. The close message is modeled similarly. Analogously, UML-G can be used on messages in collaboration diagrams. A state diagram shows a sequence of states, which an object can take in its life. In addition, it presents state changes, events that trigger state changes and activities. An activity diagram is a special state diagram that focuses on activities. In these diagrams UML-G can be used on events. A task for example can be in an opened or

106

J. Rubart and P. Dawabi

a user create a task open <<shared>> {observable}

close <<shared>> {observable}

Fig. 9. Sequence Diagram Modeled with UML-G

closed state. Instead of an open message like in the sequence diagram in Fig. 9 an open event could be modeled that is shared by all users accessing the task.

5

CASE Tool Support

UML-G allows high level, implementation-independent modeling of groupwarespecific elements and empowers CASE tools to partially automate the development activities. For this, existing CASE tools, supporting the UML extension mechanisms, can be configured to support modeling with UML-G. If they provide suitable configuration mechanisms or APIs, they can be adapted to generate special code. For groupware development, usually a groupware toolkit or framework is used. After integrating a selected one into an appropriate CASE tool and using the CASE tool’s configuration mechanisms or APIs to adapt the code generation accordingly, code for the used toolkit or framework can be generated from the UML-G models. Commercially available UML CASE tools, such as Rational Rose1, Together2, ojectiF3, Objecteering4 or Visual UML5 (to mention a few), usually provide support for the extension mechanisms of UML. Differences can be found regarding the completeness of this support and with reference to semantic support, whether it is for ex-

1

Rational Software, http://www.rational.com/products/rose/ TogetherSoft, http://www.togethersoft.com/ 3 microTOOL, http://www.microtool.de/ 4 Softeam, http://www.softeam.fr/us/produits.htm 5 Visual Object Modelers, http://www.visualobject.com/ 2

Towards UML-G: A UML Profile for Modeling Groupware

107

ample possible to define a stereotype hierarchy, a reusable set of extensions or whether OCL constraint expressions are verified against the model. For our purposes we have chosen ArgoUML6 since it is an open source UML CASE tool written in Java. This enables us promising future work because we can adapt and extend it in any direction. It also has support for adding to-do comments at certain points in models. Fig. 10 shows the telepointer example from section 3.3 modeled with ArgoUML. On the top left part you can see a hierarchical view of our Examples project. On the upper right part you can see the telepointer class diagram. The bottom right part shows the details of the selected object in the class diagram. Currently, the telepointer class is selected and its tagged values are shown in the details part.

Fig. 10. The Telepointer Example Modeled with ArgoUML

5.1

Code Generation

UML CASE tools usually provide code generation support for different objectoriented programming languages. In addition, some CASE tools allow the adaptation of generating code by providing suitable configuration mechanisms via for example scripts or by providing APIs. This enables special handling of particular UML extensions. For generating code we have selected the Java-based groupware framework DyCE (Dynamic Collaboration Environment) [29] since it is used in our institute. Since DyCE offers an object-oriented interface to modeling shared information, the code 6

Tigris.org community, http://www.argouml.org/

108

J. Rubart and P. Dawabi

generation is quite straightforward. We have adapted and extended the responsible code generation classes of ArgoUML. Fig. 11 shows the generated code for the telepointer class. The telepointer class is generated as a subclass of DyCE’s shared object model. Its shared attributes are generated as DyCE’s shared attributes with get- and set-methods. Note that the way shared attributes are generated and thus the get- and set-methods for them are specific DyCE-code. For the tagged value {lockable} a shared attribute LockedBy is generated that can point to the user who has currently locked the telepointer. Regarding the tagged value {access-controllable} a shared attribute AccessRight is generated pointing to an AccessRight object that encapsulates respective information. And again get- and setmethods are created. With reference to {observable} nothing special is generated for the telepointer class since it is intended to use the observer mechanisms already provided by DyCE’s shared object model. Please note that this is only one way of generating code for one specific underlying framework and programming language. UML-G does not enforce a special implementation.

6

Related Work

Basically, there are two areas of research related to work presented in this paper: Groupware and UML extensions. 6.1

Groupware

Toolkits and frameworks for building groupware, such as in [3, 4, 19, 20, 23, 29], do not provide support for modeling groupware in a manner, which is independent of the toolkit or framework. Typically, some usage examples are provided. However, these examples are implementation related and focus on programming rather than modeling. Sometimes user’s guides include modeling hints, but they are written using the language of the framework or toolkit. Hence, only very low level modeling support is provided there. Modeling support for groupware developers, such as in [24], applies a design pattern from the area of single-user application development [28] to groupware. This design pattern focuses on the separation of application and domain model, whereby the application model is related to user interface elements. UML-G in contrast does not enforce any special design patterns. It provides groupware-specific modeling elements, which can be used in any UML diagram. Moreover, UML-G can help writing down design patterns for groupware in a way that is independent of any framework and toolkit. In addition, it can be extended to include any groupware pattern explicitly (see section 3.4). In [15] a modeling approach is taken for shared information spaces in order to ease their management and support knowledge sharing within the enterprise. A metamodel

Towards UML-G: A UML Profile for Modeling Groupware

109

Fig. 11. Example Code

is proposed that defines the conceptual building blocks of an information space. This modeling approach focuses on organizing information spaces rather than on developing groupware.

110

6.2

J. Rubart and P. Dawabi

UML Extensions

With UML-F [8], working with object-oriented frameworks is supported. It allows the explicit representation of framework variation points. Hence, it is very useful for documenting a concrete framework. By using UML-F, framework developers can make explicit which parts of the system need to be adapted in order to create a valid framework instance. Therefore, application developers (users of a framework) are assisted in framework implementation and instantiation. In contrast to UML-F, UMLG does not model framework variation points. It is not intended to support framework developers in documenting their framework so that it is easier to use for application developers. It directly supports application developers in modeling cooperative applications independent of any framework. Synchronous groupware is related to real-time systems in the sense of fast propagation of other users’ interactions in order to provide workspace awareness [12]. A real-time system must respond to events in real time. The architectural design usually involves organizing the system as a set of interacting, concurrent processes [26]. There are UML extensions supporting real-time systems, part of UML-RT [13, 25]. Such an extension is useful for modeling a toolkit or framework supporting groupware development, such as in [3, 4, 19, 20, 23, 29]. These usually care for concurrency control, network latency and so forth. UML-G in contrast is not intended to support modeling of real-time systems. It is intended to support application developers in modeling their cooperative applications on a semantically high level. Typically, application developers use a toolkit or framework supporting groupware development, but not build one. UML extensions for agent-based systems, which are addressed by Agent UML (AUML), as described in e.g. [1] mainly support different ways of modeling the communication protocols between agents. In contrast, UML-G does not aim at such protocols, but at groupware-specific modeling elements. UMLi [18] is a UML extension for modeling interactive applications (in the sense of human-computer interaction). It explicitly addresses interaction issues in activity and use-case diagrams. In addition, a user interface diagram is introduced for modeling abstract user interface presentations. These presentations can be related to domain objects in UMLi activity diagrams. Since cooperative applications usually are interactive UMLi is nicely combinable with UML-G. Note that you are free to combine different UML extensions in your UML models, if this is meaningful.

7

Conclusions and Future Work

We have proposed a UML profile, called UML-G, for specializing the UML to the domain of groupware development. Standard UML and other related work do not support the explicit modeling of groupware-specific elements from an application developer’s point of view. We have identified core requirements for modeling groupware with reference to shared data modeling. Our proposed extensions address the identified requirements by explicitly representing shared information and roles and

Towards UML-G: A UML Profile for Modeling Groupware

111

actors in cooperative sessions as well as providing further semantics on shared information with the Boolean tagged values {access-controllable}, {lockable} and {observable}. UML-G supports groupware developers in modeling their cooperative applications by making groupware design explicit and therefore, easier to understand. The described usage scenarios, in which we indeed have used UML-G, validate the applicability of UML-G. Our experience shows that UML-G allows to model groupware independently from any concrete architecture of a framework or toolkit. A shared understanding between developers is supported, which abstracts from the latter implementation. UML-G can help writing down object-oriented design patterns for groupware in a way that is independent from any toolkit or framework. In turn, UML-G can be extended to include any groupware pattern explicitly. UML-G allows high level, implementation-independent modeling of groupware-specific elements and enables CASE tools to partially automate the development activities for special groupware toolkits and frameworks. In our future work, we will complement UML-G. As an example, a new part of UML-G addressing the usage of concurrency control can include tagged values, such as {optimistic} and {pessimistic}. For this, we want the community to contribute to it. In order to make this efficient we are in the process of setting up and host community support (http://www.uml-g.org/). Moreover, we will build cooperative tools providing synchronous as well as asynchronous modeling support for UML-G. For this, we will either continue using ArgoUML and create suitable shared data models with DyCE or extend the cooperative modeling tool XCHIPS to support a UML-G template. In addition, we will increase the code generation support.

3

Acknowledgements. This work was partially supported by the L project (funded by the German Ministry of Education and Research under the grant 21B8196B) as well as the EU project EXTERNAL, which is funded by the CEC (IST 1999-10091). Thanks also go to the anonymous reviewers for their detailed comments.

References 1.

2.

Bauer, B., Müller, J.P., and Odell, J.: Agent UML: A Formalism for Specifying Multiagent Interaction. In Agent-Oriented Software Engineering, Ciancarini, P., and Wooldridge, M., eds., Springer-Verlag, Berlin, 2001 (held at ISCE'00, Limerick, Ireland, 2000) 91-103 Bentley, R., Horstmann, T., Sikkel, K., and Trevor J.: Supporting Collaborative Information Sharing with the World Wide Web: The BSCW Shared Workspace System. In: The th World Wide Web Journal: Proceedings of the 4 International WWW Conference, Issue 1, O’Reilly (1995) 63-74

112 3. 4. 5.

6. 7.

8. 9. 10. 11. 12. 13.

14. 15. 16. 17. 18.

19. 20. 21.

22. 23.

24.

J. Rubart and P. Dawabi Burridge, R.: Java Shared Data Toolkit User Guide. User Guide, Sun Microsystems Inc. (1998) Chabert, A., Grossmann, E., Jackson, L., Pietrowicz, S. and Seguin, C.: Java Object-Sharing in Habanero, Communications of the ACM pp. 69-76, Vol. 41, No.6. (1998) Dawabi, P., and Rubart, J.: CoopLab: A Framework for Web-Based Virtual Labs. In: Proceedings of the Workshop Multimedia Computing on the WWW, VL2000, Seattle (2000) Dawabi, P., and Wessner, M.: Combining Instructionist and Constructionist Learning in a Virtual Biotech Lab. In: Proceedings of ED-Media 2001 Tampere, Finnland (2001) EXTERNAL – Extended Enterprise Resources, Network Architectures And Learning, EU Project, IST-1999-10091, New Methods of Work and Electronic Commerce, Dynamic Networked Organisations, http://research.dnv.com/external/ (2000-2002) Fontoura, M., Pree, W., and Rumpe, B.: UML-F: A Modeling Language for ObjectOriented Frameworks. In: Proceedings of ECOOP’00, Cannes, France (2000) Gamma, E., Helm, R., Johnson, R., and Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley (1995) Greenberg, S.: Computer-Supported Cooperative Work and Groupware, Academic Press, London (1991) The Groupware Patterns Project, available at: http://swiki.ipsi.fhg.de/gw-patterns/ (2001) Gutwin, C., and Greenberg, S. Workspace Awareness for Groupware. In: Proceedings of CHI’96, Vancouver (1996) 208-209 Herzberg, D.: UML-RT as a Candidate for Modeling Embedded Real-Time Systems in the Telecommunication Domain. In: Proceedings of <>, Fort Collins, CO, USA, Oct. 28-30 (1999) Keith Edwards, W., and Mynatt, E.D.: Timewarp: Techniques for Autonomous Collaboration. In: Proceedings of CHI’97, ACM Press, Atlanta, GA (1997) Natvig, M.K., and Ohren, O.: Modeling Shared Information Spaces (SIS). In Proceedings of Group'99, Phoenix, Arizona, USA, ACM Press, (1999) 199-208 Nielsen, J. Hypertext and Hypermedia. Academic Press, Inc., San Diego (1990) OMG: OMG Unified Modeling Language Specification V1.3, http://www.rational.com/uml/ (1999) Pinheiro da Silva, P., and Paton, N.W.: UMLi: The Unified Modeling Language for Interactive Applications. In Proceedings of UML 2000, York, UK, A. Evans, S. Kent and B. Selic (Eds.). LNCS Vol. 1939 (2000) 117-132 Prakash, A., and Shim, H.S.: DistView: Support for Building Efficient Collaborative Applications using Replicated Objects. In: Proceedings of CSCW’94 (1994) Roseman, M., and Greenberg, S.: Building Real-Time Groupware with GroupKit, a Groupware Toolkit. In: Transactions on Human-Computer Interaction, 3(1) (1996) 66-106 Rubart, J., Haake, J.M., Tietze, D.A. and Wang, W. Organizing Shared Enterprise Workspaces Using Component-Based Cooperative Hypermedia. In Proceedings of Hypertext’01, ACM Press, Århus, Denmark (2001) 73-82 Rumbaugh, J., Jacobson, I., and Booch, G. The Unified Modeling Language Reference Manual. Addison-Wesley (1999) Schuckmann, C., Kirchner, L., Schümmer, J., and Haake, J.M.: Designing object-oriented synchronous groupware with COAST. In: Proceedings of CSCW’96, ACM Press (1996) 30-38 Schuckmann, C., Schümmer, J., and Seitz, P.: Modeling Collaboration using Shared Objects. In: Proceedings of Group’99, ACM Press, Phoenix, Arizona (1999)

Towards UML-G: A UML Profile for Modeling Groupware

113

25. Selic, B., and Rumbaugh, J.: Using UML for Modeling Complex Real-Time Systems. White paper available at http://www.objectime.com/otl/technical/umlrt.html (1998) th 26. Sommerville, I.: Software Engineering, 6 Edition, Addison-Wesley (2001) 27. Summers, R.: Official Microsoft© NetMeeting™ Book. Microsoft Press (1998) 28. Szekely, P., Luo, P., and Neches, R.: Facilitating the Exploration of Interface Design Alternatives: The HUMANOID Model of Interface Design. In: Proceedings of CHI’92 (1992) 507-515 29. Tietze, D.A. A Framework for Developing Component-based Co-operative Applications. GMD Research Series No. 7/2001, ISBN: 3-88457-390-X (2001) 30. Wang, W., Haake, J.M., Rubart, J., and Tietze, D.A.: Hypermedia-Based Support for Cooperative Learning of Process Knowledge. In: Journal of Network and Computer Applications (2001) 31. Warmer, J.B., Kleppe, A.G.: The Object Constraint Language: Precise Modeling with UML, Addison-Wesley, Reading, Mass. (1999) 3 32. Wessner, M., Dawabi, P., and Haake, J.M.: L – An Infrastructure for Collaborative Learnflow. In: Gerry Stahl (Ed.): Proceedings of the CSCL 2002 (2002) 698-699

Designing the Communications Infrastructure of Groupware Systems Sergio F. Ochoa1, Luis A. Guerrero1, David A. Fuller2, and Oriel Herrera3 1 Department

of Computer Science, Universidad de Chile. Blanco Encalada 2120, Santiago, Chile {sochoa, luguerre}@dcc.uchile.cl

2 Computer Science Department, Pontificia Universidad Católica de Chile. V. Mackenna 4860, Santiago, Chile. [email protected] 3 Informatics School, Universidad Católica de Temuco. Manuel Montt 56 Temuco, Chile. [email protected]

Abstract. In the development of groupware systems a well designed communications infrastructure is required, due to the high complexity of the communication scenario. Also, the design and implementation of coordination and collaboration mechanisms depends on the communications infrastructure. Actually there are no well known guidelines to design this infrastructure. Therefore, this paper proposes an architectural pattern that helps carry out the design of this communications infrastructure. The proposed pattern supports all the groupware systems communication scenarios, taking in account their particularities. This pattern has been used in the design of several groupware applications and a groupware framework with very good results.

1 Introduction A collaborative application or groupware system supports the work performed by a group of collaborators who pursue a common goal. For the attainment of this goal, the groupware system must provide support in three essential aspects: coordination, collaboration, and communication, better known as the three groupware Cs [4]. Communication is the base for reaching coordination and collaboration. Unlike distributed systems, collaborative applications share a common goal, which has to be reached by the collaborators through the coordination of their individual contributions and activities. Due to the existence of this common goal, communication becomes a way of supporting the coordination and collaboration mechanism that permits the group work. Therefore, the design of the communications infrastructure is very important, since there are many other design aspects that depend on it [14]. These are, for example, awareness, sessions and user administration, floor control, and notifications. Considering the essential aspects that have been defined by Ellis, et al. [4], the groupware systems should be designed using a layered architecture [2] (see Figure 1). The reason is that each layer uses services from lower layers to do its work. This is J.M. Haake and J.A. Pino (Eds.): CRIWG 2002, LNCS 2440, pp. 114–133, 2002. © Springer-Verlag Berlin Heidelberg 2002

Designing the Communications Infrastructure of Groupware Systems

115

similar to what happens with the data communication protocols or with operating systems. In this scenario, each layer carries out a specific function and communicates with the other layers through well-defined interfaces. In groupware systems the communication layer should be in charge of providing the communication among the applications. The coordination layer should generate a shared vision of the group work. It coordinates the actions that are carried out individually, and generates a consistent vision of the group activities. Finally, the two superior layers correspond to the definition and the use of the elements that permit collaborative work, from the user viewpoint. Stratified architectures have many advantages, which have been widely discussed [2].

Fig. 1. Layers of a typical groupware system

Typically, in groupware systems, each component of the layers two and three should be designed and implemented over the defined communications infrastructure (or communication layer). Therefore, the implementation, extension or modification capacities of these components depend greatly on: (a) the services provided by the communications infrastructure and (b) the quality of they. Therefore, the infrastructure must be well designed, and isolated from the rest of the collaborative work support media. In this way, it is always possible to add new services to the communication interface, incorporate new communication technologies, and maintain and improve the existing infrastructure, without changing the superior modules of the application. To achieve this, an isolated, modular, and flexible communications infrastructure that permits communication on all the typical scenarios is required. Today, there are no communication architectures that take in consideration the particularities of the groupware systems. Therefore, this article presents an architectural pattern called CAGS -Communication Architecture for Groupware Systems- which proposes a flexible and modular architecture to manage the communication in groupware systems. This pattern takes in account the particularities of this kind of communication which are described in the next section. Section 2 also presents the communication scenarios of groupware systems. Section 3 presents the related works. Section 4 describes the CAGS pattern. Section 5 shows how this pattern supports the typical communication scenarios. Section 6 shows one example of the application of this pattern. Section 7 presents the obtained results. Finally, section 8 states the conclusions of this work.

116

S.F. Ochoa et al.

2 Communication in Groupware Systems In CMC – Computer-Mediated Communication – scenarios there are at least four elements involved: a sender, a message, a channel, and a recipient. The sender is the process that sends messages. The messages are flows of bytes transmitted through a channel. The recipient is a process that receives, and possibly processes the messages. Finally, all these messages are sent through the channel. Usually, every groupware system needs to implement several ways of messages addressing, such as: point-to-point, multicast, and broadcast. Moreover, each one of they can be implemented using a different ways of message delivering, such as: synchronous or asynchronous. We call synchronous communication those instances of communication where the sender can deliver messages to the recipient without explicitly storing these messages in the channel. A special case of this type of communication is audio and video streaming, also called isochronous communication [20], which requires that the messages be generated, transmitted, and received in fixed time intervals. We refer to asynchronous communication when messages sent by the sender may need to be stored by the channel before being delivered to the recipient. Summarizing, the possible communication scenarios in groupware systems are a combination of one message addressing way and one message delivering way. The communications infrastructure of groupware systems is similar to that of the distributed systems, all though there are various differences. The more relevant differences are visible from the design viewpoint. Unlike distributed systems, the communications infrastructure of the groupware systems should be: Isolated. To let the application be independent from the communication medium used. Also, to separate the communication tasks from coordination tasks. In that way, it is easier to design, implement and maintain a good communications infrastructure. Besides, due to the relationship that exists between communication, coordination, and collaboration, it is natural that the first be managed in an isolated way. Complete. To support all the communications scenarios that may be present. In groupware systems, the communications scenarios that need to be supported can change along the time. For example, due to extensions of the application functionality. It can also be due to changes or to the incorporation of aspects that support the collaborative work, for example: awareness, performance, operation monitoring, floor control or security, among others. If the communications infrastructure does not support all the typical communication scenarios of the groupware systems, it will limit the functionality and the expansion capacity of any application implemented over it. For example, to implement a simple chat it is necessary to support only synchronous communication. If the chat implements connection awareness, it is possible to use the same infrastructure to support it. It is possible that after using it, problems of performance are encountered due the high amount of awareness messages in the network. The most obvious solution for this problem is to change the awareness from synchronous to asynchronous. It can be easy to do only if the communications infrastructure is modular and extensible. Flexible and modular. To activate and deactivate communication scenarios according to the application necessity, without prejudice to it. Typically, the

Designing the Communications Infrastructure of Groupware Systems

117

groupware systems do not use all the known communications scenarios, and use only a subset of they. Incorporating the support needed for only the scenarios involved in the application generally is necessary for performance reasons, resource usage, maintenance and application simplicity. Therefore, the communications infrastructure must be complete, but must also be modular and flexible to support the different communications scenarios. This means that it must be possible to activate o deactivate the support for certain communications scenarios, without the rest of the application suffering because of this. In this way, only communication scenarios that are needed will be incorporated, without limiting functionality, nor the extension capacities of the collaborative application. Open. So as not to condition its use to the fact that certain application architectures (e.g. Client/Server) can be used. In that way, the solution viability is guaranteed in any work scenario. Today, the majority of the proposed communications infrastructures condition their usage to certain type of applications, specific domains, or the use of certain software architectures. These characteristics make communications infrastructures of groupware systems are different, but also more demanding than most communications infrastructures of current applications. This is one of the reasons why collaborative systems are difficult to implement, maintain and expand.

3 Related Works In CMC the groupware systems need to manage communication among processes in any of the defined scenarios, but in a modular way. Building mechanisms that make this possible is not an easy task, for until this moment there are no known guidelines to support the design of communications infrastructure in groupware systems. A very used way to represent the design of this kind infrastructure is through an architectural pattern [2]. There are no well known architectural patterns to design the communication in groupware systems, but in distributed systems there are a number of choices (see [18]). Schmidt et al. proposes a pattern language for middleware and distributed application. It is the most complete pattern system in this area. However, it is of little use in the groupware systems area, because, for example, it does not separate the communication services from the coordination services. Typically these architectural patterns do not include the restrictions of groupware systems, because they are designed for distributed systems. On the other hand, there are middleware technologies that carry out the communication in this scenario, like for example, RPC -Remote Procedure Call-, MOM -Message Oriented Middleware- or TP-distributed Transaction Processing[11]. These are not complete, flexible, modular nor isolated, but there are open. This is due to that these technologies were designed to support distributed systems. Actually, the ORB -Object Request Broker- technology is the most used for distributed systems. There are two standards for it: CORBA – Common Object Request Broker Architecture- and OLE/DCOM – Object Linking and Embedding / Distributed Common Object Model –. Similar to those mentioned before, they do not consider the communication restrictions of the groupware systems because they propose solutions for distributed systems.

118

S.F. Ochoa et al.

As a consequence of the lack of support in the development of groupware systems in general, over the last few years, a great number of frameworks to support the collaborative application development have appeared. Among the more known frameworks are: TOP-Ten Objects Platform – [9], Habanero [3], GroupKit [8,17], COCHI – Collaborative Objects for Communication and Human Interaction – [13], and JSDT – Java Shared Data Toolkit – [1]. These implement some elements of CAGS, and therefore, do not incorporate all the communications restrictions mentioned before. In section 4.8 a more detailed analysis of this framework is presented. In groupware systems there are no well known patterns for designing the communications infrastructure. The few patterns that have been defined in this area are focused on the collaborative application design [10]. Therefore, this paper proposes the CAGS architectural pattern as a guideline to design and implement the communications infrastructure of groupware systems. This pattern is the result of more than six years of experience in designing and implementing groupware systems.

4 The CAGS Pattern As Buschmann [2] said, an architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities and includes rules and guidelines for organizing the relationships between them. The CAGS architectural pattern establishes a modular and extensible structure for the overall management of the communication in groupware systems. To specify this pattern the structure proposed by Buschmann will be used [2]. 4.1 Pattern Name CAGS – Communication Architecture for Groupware Systems. 4.2 Context In a groupware system, both the collaborators and some system processes need to exchange messages among themselves. In addition, sometimes it is necessary to keep a record of messages in order to subsequently operate on them. The types of communication that may be found in this scenario are point-to-point, multicast and broadcast. At the same time, these can be synchronous or asynchronous. 4.3 Problem Unlike distributed systems, the groupware systems need communications infrastructures designed in a modular way, that potentially are capable of including all the communication scenarios possible. This infrastructure must also be capable of providing a minimal set of services that permit the implementation of coordination

Designing the Communications Infrastructure of Groupware Systems

119

and collaboration mechanisms of the application. The communication scenarios supported by this infrastructure can change along the time. 4.4 Solution In order to manage the different communication scenarios, taking in account the restriction mentioned in section 2, the architectural pattern called CAGS is proposed. It is based on the layer pattern [2] and its main goal is to facilitate the delivery of a set of communication services that permit the implementation of coordination and collaboration mechanisms over it. To define CAGS we consider a groupware application composed by a work interface, background processes and a communications infrastructure. The communications infrastructure permits the sending and receiving of messages among processes in several communication scenarios. The background processes permit the coordination of all the operations that form part of the collaborative work, directly or indirectly. Examples of these processes are the following: the shared-memory manager, the floor control manager or the session manager, among others. The user interface permits the collaborative work by using the background processes and the communications infrastructure.

Fig. 2. Communication elements of CAGS pattern

The CAGS pattern proposes an architecture with six components: user buffer, event handler, channel, log file, channel status and channel buffer. The user buffer is used for buffering. It is only necessary in applications that synchronize video and audio transmissions. The event handler is the interface manager between the communications layer and the superior layers. It is in charge of receiving those messages whose recipient is a process running on the same computer. Also, it is in charge of capturing the events that should be transmitted, and sending them through the channel to the proper recipient processes. The channel takes care of the message transportation between the event handlers.

120

S.F. Ochoa et al.

As shown in Figure 2, the channel should have three associated elements: a log file, the channel status and a channel buffer. Every message that travels through the channel could be properly stored in a log file. This component has a similar behavior to that of the command pattern [6], and it is useful, for example, to show the messages to a user who logs on late into the work session or to allow for operations such as "undo" and "redo". The channel status stores and maintains information about active applications, computers, processes and recipient groups that are using the communications infrastructure. This information is registered through background processes and is maintained through the event handlers. Once the information is registered as part of the channel status, it can be used to access the groups directly, using a group identifier, for example. If multicast is not available, this is a good way of simulating it. Finally, if during a message distribution, one of the users is not active, and the communication mode is asynchronous, the channel must save the message in the channel buffer in order to attempt a subsequent delivery. This buffer has a similar behavior to that of the producers and consumers pattern [7]. It is essentially used to give persistence to the messages in asynchronous scenarios.

Fig. 3. Object classes diagram for the CAGS pattern

4.5 Structure Figure 3 shows the UML class diagram of the CAGS pattern structure. In this diagram, the six components that form part of the pattern can be identified, as well as the relationships between them, and the relationships with other external components.

Designing the Communications Infrastructure of Groupware Systems

121

The external components, such as work sessions and sessions managers, belong to coordination layer and they show an example of how one coordination component can be linked to the components of the communication layer. The communications infrastructure interacts with the user interface and background processes through the event handlers. On the other hand, these event handlers capture the events and act in consequence. Also, they receive the messages from the channel and send them to the corresponding destination processes. The event handler uses an API to encapsulate all functionality of the communication layer. Thus, when changing the implementation of the communication layer, the superior layer of the collaborative applications will suffer no changes. The user buffer provides temporary storage of messages in order to synchronize the reception of some data types like audio and video. Only in this kind of application this component makes sense. The channel transmits/receives the messages to/from an event handler. It provides a communication media by means of messages for each defined communication scenario (see section 5). There are a number of basic features which the channel should provide, such as:

Correct message delivery and receipt: refers not only to the integrity of data, but also to the message generation and acceptance sequence. For this purpose, the event handler should interact with the channel to guarantee the reliable delivery and retrieval of messages. Message storage: due to the fact that the recipient process is not always available at the moment when it is required, the channel should serve as a message buffer. This service uses the channel buffer to store the messages. Message distribution: refers to the delivery of messages to the proper recipient processes, which conform a work session. It is carried out using the channel status information. Message persistence: if it is necessary, it should be possible to store messages for additional operations upon them. This service can be implemented using the channel buffer and the log file. The channel buffer allows the storage of messages for subsequent delivery. If it is necessary to keep the history of sent messages, the channel sends a copy of the message to the log file component. This log file component maintains all the work history. Finally, the channel status component stores the information about applications, processes, computers and recipient groups that are using the communications infrastructure. The channel status organizes the information in a hierarchical way. The first level corresponds to active applications. The second level corresponds to the computers in which these applications are running. Finally, the third level corresponds to the active processes that are a part of the application. The way through these three information levels has a unique name associated to it and corresponds to a recipient identifier. This identifier is called Recipient_Id and is used to deliver the messages. On the other hand, it is also possible to associate a unique identifier to a set of Recipient_Ids. In that way, it is possible to setup an addressing strategy that permits efficient message distribution. All messages given by background processes or by user

122

S.F. Ochoa et al.

interface to the channel should have a Recipient_Id. The channel on the other hand will be the one in charge of distributing them in the most appropriate way. 4.6 Dynamics Next there is a description of some of the communications scenarios that may be found when using CAGS. These scenarios are part of the pattern dynamics. Scenario I. A user enters a work session through a login process (Figure 4). To start this process Proc1 sends a message to the event handler (E.H.) that requests a login for a work session. The event handler tells the work session that a new user wants to log. The work session validates and in case of success, registers the new user, and returns a response to the event handler. This registration involves the channel notification for it includes the new client and processes into the channel status component. Finally, the event handler tells the process the result of the login operation. To exit a work session, the scenario is similar.

Fig. 4. Entry of a user into a work session through a login process

Scenario II. A background process sends a message to a set of background processes. In Figure 5, a process Proc1 sends a message to its event handler. This event handler sends the message to the channel. The channel responds that it received the message, and proceeds to distribute it to every recipient event handler. Every event handler receives the message and delivers it to the proper process. To carry out an effective deliver of the message, the channel uses the information stored in the channel status. Scenario III. The channel stores all the messages received in the log file. When the channel receives a message, it sends it to the log file before sending it to the recipient event handlers. The log file receives the message and stores it. Then, the channel uses the channel status information to carry out an effective delivery to the recipient event handlers.

Designing the Communications Infrastructure of Groupware Systems

123

Fig. 5. A process sends a message to a set of processes

4.7 Implementation To carry out a CAGS implementation it is necessary to take some decisions. The most important decisions relate to the following: 1. the required functionality of the pattern. It must be decided if the log file is wanted or not, as well as the storage time for the messages in it. For example, last hour, last week, last 100 messages, etc. 2. whether the communication is synchronous or asynchronous, in order to decide if the channel buffer component will be used or not. 3. if audio or video reception (isochronous communication) will be involved. A user buffer could be needed. 4. what messages can be generated both by user interface (UI) and by background processes (BP). It is also necessary to specify what messages can arrive at each kind of process (UI and BP), and what to do with them. 5. whether to use a client-server or a peer-to-peer architecture. The decision made will determine where to store the list of users logged into the work session, as well as their corresponding IP numbers. 6. If a channel buffer or a log file is used, where will they be implemented, and where will the messages be stored. For example, in client-server architecture these two components, as well as the channel component, can be implemented as part of the server, or else, they can be implemented as part of the client. On the other hand, every work session must have at least one channel. It is advisable to create a default channel when a work session is created. The majority of the applications have only one channel. If an application requires several channels, it is necessary to indicate the channel by which the message is going to be sent. To

124

S.F. Ochoa et al.

implement the pattern components, it is necessary to use distributed objects. The consequences of this pattern are part of the section 7. 4.8 Adaptations

The CAGS pattern can be used for the development of groupware systems as well as for the creation of frameworks for the development of such systems. Also, several components of the CAGS pattern are present in most frameworks for groupware application development kits, such as: TOP -Ten Object Platform- [9], Habanero [3], GroupKit [8, 17], COCHI -Collaborative Objects for Communication and Human Interaction- [13], and JSDT -Java Shared Data Toolkit- [1]. Below is a brief description of how these frameworks incorporate some components of the CAGS pattern to implement their communications infrastructure. TOP. The TOP platform operates according to a client/server architecture [9] and it was designed taking in account the CAGS pattern. It does not implement multicast, but it can be easily simulated. TOP makes the channel component act as a server responsible for the distribution of messages. There are also modules in charge of providing: the shared objects persistence, session management, user and floor control. These modules are in the coordination layer and use channel services. The event handler that is part of the channel is divided into two parts, one in the client application and the other in the server. The latter uses an in/out port to allow communication through messages, using the server as an intermediary. TOP allows the development of synchronous and asynchronous, but not isochronous applications. Therefore, the channel implements the channel buffer, but not the log file. This framework separates the communication layer from de coordination layer. Also, it permits the access to the communications infrastructure through a set of predefined services. Habanero. This platform allows only synchronous work, and is used to transform single-user applications into shared applications, and to develop new groupware systems. Habanero does not support multicast, and the channel component is implemented through a server, which is responsible for managing communications. The collaborative applications are implemented as a set of client objects, which interact through a wrapped object. This wrapped object is responsible not only for managing the application events, but also for coordinating the rest of the wrapped objects that form part of it. Communication is not performed by messages but by actions, which are orders distributed for execution. To support asynchronous work, ISAAC – Integrated Synchronous And Asynchronous Collaboration – [12] was developed, which implements an extension of the Habanero’s session model. This new session model implements the log file and the buffers as a part of the model and not as a part of the channel. This framework also does not separate de communication layer from the coordination layer. GroupKit. This allows the development of applications which only support distributed synchronous work. The channel component is implemented by a server,

Designing the Communications Infrastructure of Groupware Systems

125

which manages the transmission of messages by means of a process called registrar. The event handlers are in the client application and they interact directly with the server through an API. Since GroupKit supports only synchronous work, it does not implement either the buffers or the log file. In this framework the communication layer is mixed with the coordination layer. It does not implement multicast, but it can be simulated. COCHI. This framework permits the use of synchronous applications and only does not implement multicast. It uses a client/server architecture so the channel component is implemented through a server, represented by the communication media component. The channel buffer, user buffer and log file components are not part of the framework since it only supports synchronous (and not isochronous) work. The event handler component is divided into two parts: one part is in the client application and the other in the channel (in this case, the server). This framework separates the communication layer from the coordination layer. JSDT. It implements several CAGS components such as the: channel, event handler, user buffer, and log file. The channel is implemented as a server, and access to it is carried out through a client application. In JDST, the event handler, is divided into two parts: one sends messages and the other receives messages. JSDT is part of the message receipt only. Sending messages is the responsibility of the application, because processes are allowed to write directly on the channel, without going through the event handler. The message receipt function of the channel depends on the type of conversation (Channel, ByteArray or Token). In this framework, a user buffer exists for isochronous communication handling, such as audio and video, and can be used in both conversation modes: Channel, and ByteArray. JSDT does not provide asynchronous communication. However, this type of communication can be implemented, creating a channel buffer with the elements supplied by the framework. Typically JSDT does not separate the communication layer from de coordination layer, but a well designed application could simulate the existence of these layers.

5 Support to Communications Scenarios The CAGS pattern should provide a modular and flexible support to all communication scenarios that were defined in section 2. Taking in account the ways of message delivering, the communication can be synchronous or asynchronous. Next, each one of these scenarios is analyzed.

Synchronous Communication Scenario. To support synchronous communication, the following components are needed, as a minimum: an event handler, a channel and the channel status. This is the minimal communications infrastructure to support synchronous communication with message discarding. This means that if the recipient process is not active at the time when the message is distributed, the message will be discarded.

126

S.F. Ochoa et al.

On the other hand, if one works in a synchronous way but allowing replies of small sets of operations, it is necessary to include a log file as part of the communications infrastructure. An example of this is when one works using synchronization points. In this scenario, the shared-object manager is in charge of delivering the states of the shared objects until the last synchronization point, to any collaborator that enters the work session. Then, the communications infrastructure must deliver all the operations done from the last synchronization point to the collaborator. In the case of isochronous communication [20] it is only necessary to add the user buffer to the minimal communications infrastructure. This buffer serves to store the messages received from the channel, since then they will be transmitted to the interface in fixed time intervals. The message addressing way supported in this scenario is the same as that in the asynchronous communication scenario, they are: point-to-point, multicast and broadcast. To carry out each of the addressing ways, the channel status information is used. The point-to-point and multicast communication can be implemented through the Recipient_Ids stored in the status channel. Additionally, each application (not each instance of an application) has by default a special Recipient_Id which it is used to carry out the messages broadcasting. Asynchronous Communication Scenario. On the other hand, in asynchronous communication the minimal infrastructure is composed by: an event handler, a channel, the channel status, a channel buffer. Depending on the information that the messages in the channel buffer have, a log file might be or not be necessary. The way that the messages are addressed is the same as in synchronous scenarios.

6 Pattern Application In this section, it is shown how a simple groupware application, such as a shared whiteboard, can be designed using the pattern. In this example, it can be observed how some of the CAGS pattern elements, which are not present in the JSDT, can be implemented and integrated as specified by the pattern. The application has been built in Java, and was designed based on the following elements (see Figure 6): user interface, GUI listener (background process), consumer (event handler), registry (session manager), work session (session) and channel (channel). The user interface (GUI) allows the user to interact using mouse and keyboard. The user operations are captured using the KeyListener, MouseListener, or WindowListener interfaces. A background process (GUI Listener) which is part of the coordination layer analyzes these operations. Depending on the type of event, and the object upon which the process was performed, this process will be in charge of whether to distribute the performed operation or not. Sending the information directly to the channel carries out this distribution. The channel transports the information, and then uses the recipient’s event handler (consumers) as an intermediary between the target process and the channel. As the application is neither asynchronous nor isochronous, it does not need to implement buffers. Nor does it implement the log file, although in section 6.1, a variant of this application which does use a log file, is presented.

Designing the Communications Infrastructure of Groupware Systems

127

Fig. 6. Example of an application using the CAGS pattern and the JSDT tool

In figure 6, the channel, JSDT server and consumer are part of the communications infrastructure (communication layer). The Registry and the GUI listener are part of the coordination layer and they correspond to the background processes. Finally the GUI is part of the collaboration layer and it corresponds to the interface. It is the classification proposed in the section 4.4 (CAGS solution). In order to support group work, our client application needs the server to have an active instance of the session manager known as Registry. Therefore, the server must verify if the Registry is running, and, if not, execute it. This allows work session, conversation, and user information recording. Then, at least one work session needs to be created, along with one or more conversations (communication channels) within the created session. These three operations can be observed in the following script segment, where the first task performed is the session ID building for the session that is going to be created (1). Later, it will verify if the Registry is running, and if it is not, it will be executed (2). Afterwards, a session (4) and a client for the session (3) are created. Finally, a channel type conversation is created (5), leaving the communications scenario ready to be used by any client application. Operations 1 to 5 correspond to coordination layer services. Operation 5 is the initialization of the communications infrastructure (communication layer). (1)

(2)

url = URLString.createSessionURL(hostname, hostport, sessionType, sessionName); try { /* Is the Registry running? */ if (RegistryFactory.registryExists(sessionType)==false) { RegistryFactory.startRegistry(sessionType); } /* Create a session */ client = new WhiteBoardClient("Server"); wbSession=SessionFactory.createSession(client,url,true);

(3) (4)

/* Create a channel type conversation. Add the client. */ wbSession.createChannel(client,"WBChannel",true,true,false); System.err.println("Setup and bound WhiteBoard server.");

(5) }

The event handler (consumer) will be activated every time a message arrives from the channel, and will execute the dataReceived method to process it:

128

S.F. Ochoa et al. ... /** The WhiteBoardUser for this consumer. */ WhiteBoardUser wbu; ... public synchronized void dataReceived(Data data) { /* Handle the received data. */ wbu.commandLine = data.getDataAsString();

(6) (7) }

The information that travels through the channel is of the data type (6), a proprietary JSDT format. In this application, what is sent/received are the commands or events into string format (7). Once the first script segment is executed, it can be said that the channel is active, because the Registry is running, a session is created, and there is a conversation ready to be used. The only thing left to do is to log the client application into the channel. The simplest way to do this is the following: (a) enable the work interface (GUI), so that the users can use it; (b) log onto the channel, leaving the application interface ready to perform the collaborative work; (c) listen to the events that occur in the interface, and act accordingly (GUI Listener). Then, it is necessary to carry out the login process. For it, the application should create a unique client ID (8). After this, the ID for the session is created to it can be accessed (9), a reference of this session is obtained (10), and the recently created client is added (10). Once the client is logged into the work session, it is necessary to obtain the references of the conversations to be used (11). Finally, it is necessary to register the client as a channel message consumer (12). Thus, the client application remains logged onto the channel, and is ready to begin the collaborative work. private void connect() { ... /* Create a whiteboard client */ (8) client = new WhiteBoardClient(name); /* Resolve the whiteboard session */ try { (9) URLString url = URLString.createSessionURL(hostname, hostport, sessionType, sessionName); (10) session=SessionFactory.createSession(client,url,true); ... (11) channel = session.createChannel(client,"WBChannel", true, true, true); wbConsumer = new WBConsumer(client.getName(), this); (12) channel.addConsumer(client, wbConsumer); ... }

Figure 7 shows two windows of the shared whiteboard application built, which are located on the same computer. It is the result of having used the CAGS pattern to define the communications infrastructure of the collaborative application. It can be observed that the application is modular, which simplifies its maintenance and extension.

Designing the Communications Infrastructure of Groupware Systems

129

Fig. 7. Whiteboard Interface

6.1 Adding The LogFile Component to the Whiteboard As previously stated, the shared whiteboard does not implement the log file and neither does JSDT. Therefore this is an example of how a CAGS component can be implemented or simulated through a design solution. The log file is important for the support of asynchronous work because it stores all the operations executed since the beginning of the session, in a chronological order. These operations are sent to each user that accesses the session later, so he/she can obtain an updated image of the current status of the shared objects. Figure 8 shows the incorporation of the log file to the communications infrastructure of the application.

Fig. 8. Whiteboard application with log file

The log file implementation strategy is simple and consists of adding a “special” consumer to the server (Consumer X). This is a special consumer because it runs a task different from the rest of the consumers involved in the application. The function

130

S.F. Ochoa et al.

of Consumer X is to analyze and conveniently store (in the log file) the messages that run through the channel, and to deliver these messages to any user who connects later onto a session. This strategy can be implemented using any framework that allows the consumer to listen to the commands that run through a channel. The process for adding consumers is the same for clients and servers. To do this, it is necessary to incorporate into the channel, the client used to create it (18) and then register that client as a consumer (19). The rest of the work must be implemented inside the program of this consumer (Consumer X). (18) wbSession.createChannel(client,"WBChannel",true,true,true); ... DrawingRecorder ConsumerX = new DrawingRecorder(ch); (19) ch.addConsumer(client, ConsumerX); ...

One of the functions of this class is to store, in the log file, the messages that run through the channel (20). The other function is to send the stored messages to each new client that connects to the session (21). class DrawingRecorder extends DrawingConsumer implements ChannelConsumer ... /** The list of all events or commands */ private ArrayList event_list = null; public synchronized void dataReceived(Data data) { ... event_list = new ArrayList(); ... (20) event_list.add(evt); ... If ((evt.operation = 1)&&(event_list.size() != 0)) { ... (21) SendToClient(evt.client, event_list); ...

7 Obtained Results The CAGS pattern has been used to design several collaborative applications and also a framework for the development of such applications. This framework was called VisualTop [15] and it is based on TOP [9]. Also, it implements all components of CAGS and it separates the application in the three layers proposed in Figure 1. With VisualTOP, several collaborative applications were developed, like: an asynchronous collaborative editor, an electronic meeting system, a discussion forum and a synchronous desktop conferencing system. Some of these applications have been described in [15]. On the other hand, there are collaborative applications that have been developed using CAGS and others framework like TOP or JSDT. Some of the collaborative applications developed using CAGS and TOP are the following: an asynchronous collaborative editor, a discussion forum, an electronic meeting system, a brainstorming system and a voting system. All of them have been mentioned or briefly described in [9].

Designing the Communications Infrastructure of Groupware Systems

131

Among the collaborative applications developed with CAGS and JSDT are the following: a brainstorming system, a voting system, a chat, a shared whiteboard and a synchronous distributed slider. The major challenge that the developers faced during the development of these applications was giving communications support to the asynchronous scenarios. But, as was showed in section 6.1 this problem could be surpassed. The best collaborative applications, regarding performance, maintainability and extendibility, were those developed with VisualTOP. The natural incorporation of CAGS to the platform causes that the designer does not have to worry about stratifying the application, nor designing the communications infrastructure. Among the advantages that CAGS has contributed to VisualTOP as much as the applications that use this pattern are: Adaptability. The components of the communications infrastructure can be expanded or changed without having to modify the software modules that are supported by this infrastructure. Reduced development time. The logical partitioning into a layered system and the modularity of construction using common services, offer efficiencies through the skill specialization and the component reusability. These practices will improve the system’s quality and reduce lead times for their implementation and modification. Flexibility. The features and capabilities of applications can be modified (e.g., they are scaleable and expandable) without changing the communications infrastructure. On the other hand, the communication scenarios that are parts of the infrastructure can be activated and deactivated according to the application’s necessity, without prejudice to it Maximize Flexibility in Managing the Communications Infrastructure. Changes to the communications infrastructure must be transparent to application programmers. This model permits changes in this infrastructure with little or no modification to the supported applications. Reduce Complexity for Application Developers. Since much of the functionality in new applications will be provided through pre-written and pre-tested software services, the complexity of the collaborative applications development is reduced. Complete Support. The CAGS pattern proposes a communication infrastructure that involves all communication scenarios of groupware systems and it takes in account the restriction mentioned in the section 2. In that sense, any application could be supported. Open Architecture. In order to use the pattern, it is not necessary to use any software architecture in particular. In that way, the solution viability is guaranteed in any work scenario.

8 Conclusions The communications in groupware systems are different to communications in distributed systems. The fact is that the design guidelines for communications

132

S.F. Ochoa et al.

infrastructures of distributed systems can not be applied in groupware systems. In groupware systems the communications scenario is more complex and demanding, due that the communications infrastructure should be: flexible, modular, open, isolated and complete. On the other hand, these characteristics make collaborative systems difficult to implement, maintain and expand. Therefore, a well-designed communications infrastructure is needed. Unfortunately, there are no well-known patterns for designing this infrastructure. The few patterns that have been defined in this area are focused on the collaborative application design [10]. Therefore, this paper proposes an architectural pattern called CAGS – Communication Architecture for Groupware Systems – It is a guideline for designing and implementing the communications infrastructure of groupware systems. This pattern is based on the layer pattern [2]. Due its architecture, CAGS facilitates the delivery of a set of communication services that permit the implementation of a coordination and collaboration mechanism. The CAGS architecture is composed by six components: user buffer, event handler, channel, log file, channel status and channel buffer. With these six components the CAGS proposes a solution to manage the different communication scenarios of groupware systems, taking in account the restriction mentioned in the section 2. In order to demonstrate the applicability of the proposed pattern, this paper shows how the most popular frameworks used for developing groupware systems implement several components of CAGS. Also, we explain step by step how this pattern can be used in order to design the communication aspects of a common groupware application. Several collaborative applications have been designed using this pattern, and also a framework for the development of such applications. This paper presents not only a pattern to handle these scenarios, but also a way to organize computermediated communication in order to easily implement the design aspects that depend on this communication (e.g.: awareness, process coordination or notification). Many of these aspects are critical for the success or failure of a collaborative application.

Acknowledgements. This work was partially supported by the Chilean Science and Technology Fund (FONDECYT), under grants 198-0960 and 100-0870, and also by the Scholarship for Doctoral Thesis Completion of FONDECYT.

References 1. 2. 3. 4.

Burridge, R. Java shared data toolkit: user guide. Sun Microsystems, Inc., 1998. Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, S. Pattern-oriented software architecture: a system of patterns. John Wiley & Sons, 1996. Chabert, A., Grossman, E., Jackson, L., Pietrowicz, S., and Seguin, C. Java object-sharing in habanero. Comm. of the ACM 41, 6. 69-76. June, 1998. Ellis, C. A., Gibbs, S., Rein, G. Groupware Some issues and experiences. Communications of the ACM 34, 1. 38-58. January 1991.

Designing the Communications Infrastructure of Groupware Systems 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.

133

Fuchs, L., Pankoke-Babatz, U., Prinz, W. Supporting cooperative awareness with local event mechanisms: the GroupDesk system. Procs. of ECSCW’95, (Kluwer Academic Publishers), Stockholm, Sweden. 247-262. Sept.11-15, 1995. Gamma, E., Helm, R., Johnson, R., Vlissides, J. Design Patterns: elements of reusable object-oriented software. Addison-Wesley, 1995. Grand, M. Patterns in java. John Wiley & Sons. 1998. Greenberg, S., Roseman, M. Groupware toolkits for synchronous work. Beaudouin-Lafon, ed., Computer-Supported Cooperative Work, Chapt. 6, John Wiley & Sons, 135-168. 1999. Guerrero, L., Fuller, D. A web-based OO platform for the development of multimedia collaborative applications. Decision Support Systems Journal 27, 3. 257-270. 1999. Guerrero, L., Fuller, D. A pattern system for the development of collaborative applications. Information and Software Technology, Elsevier Science B.V., 43, 7, 457-467. May 2001. Information Resource Management. Statewide technical architecture. Chapter 6: application communication middleware architecture. State of North Carolina. Revision July 2001. Jackson, L., Grossman, E. Integration of synchronous and asynchronous collaboration activities, ACM Computing Surveys 31, 2. June 1999. Licea, G., Favela, J. An extensible platform for the development of synchronous groupware. Information and Software Technology, Elsevier Science B.V, 42, 6. 389-406. April 2000. Miranda, H. and Rodrigues, L. Flexible communication suppport for CSCW applications. Procs. of the CRIWG’99, Cancún, Mexico, 338-342. Sept. 21-24, 1999. Pastor, M. VisualTop: a framework to develop groupware systems. Master of Science Thesis. Computer Science Department. Pontif. Universidad Católica de Chile. Nov. 2000. Rhee, I, Cheung, S. Hutto, P. and Sunderan, B. Group communication support for th distributed communication systems. Procs. of the 17 Int. Conf. on Distributed Computing Systems, IEEE CS Press. Baltimore, USA. 43-50. May 27-30, 1997. Roseman, M., Greenberg, S. Building groupware with GroupKit. In M. Harrison (Ed.) Tcl/Tk Tools, O'Reilly Press. 535-564. 1997. Schmidt, D., Stal, M., Rohnert, H. and Buschmann, F. Pattern-oriented software architecture. Vol..2: Patterns for concurrent and networked objects. J.Wiley & Sons. 2000. Tanenbaum, A. Distributed operating systems. Prentice Hall. 1995. Yi, J., Pastor, E. Communication support for cooperative application in open distributed processing systems. Procs. of CRIWG'96, Puerto Varas, Chile, 61-76. Sept., 25-27, 1996.

A Component-Based Architecture to Support Collaborative Application Design Ana P.T. Bacelo Blois and Karin Becker Faculdade de Informática – PUCRS – Porto Alegre – Brazil {anapaula, [email protected]} Abstract. In the Software Engineering field, reuse techniques have presented solutions targeted at increasing quality, and reducing costs and development time. Such expectations motivate the proposition of reusable solutions in various domains, CSCL (Computer-Supported Cooperative Learning) among them. In this paper, we analyze the contributions and limitations to the CSCL field of two striking reuse techniques: components and object-oriented frameworks. Based on this analysis, we present some initial ideas on a component-based architecture to support the design of CSCL applications. The main goal is to allow a designer to primarily focus on the design of his application, based on the selection, adaptation and binding of components targeted at collaborative applications.

1 Introduction Reuse is considered the key for achieving quality, reducing costs and increasing productivity, and two striking reuse techniques are object-oriented (OO) frameworks [6] [12] and components [3] [4] [11]. CSCL (Computer-Supported Cooperative Learning) is one of the areas interested on these potential benefits, and a number of generic environments, frameworks and components for developing CSCL applications are available. Some of them address cooperative applications in general (e.g. [8] [9] [10]), whilst others are targeted at the CSCL domain (e.g. [7] [16] [19]). In this paper, we present some initial ideas on a component-based architecture to support reuse-based design of CSCL applications. This architecture is motivated by the difficulties involved in the reuse of frameworks [1], as well as the potentiality of component-based technology for supporting the design of new applications. The main goal is to allow a CSCL application developer to primarily focus on the design of his application, based on the selection, adaptation and binding of components targeted at collaborative applications. Components are adequate to this goal because they provide well-defined interfaces, with hidden implementations. However, their weak point is extensibility, and therefore, the architecture assumes the combined used of components and frameworks, where the latter is used to implement the former. The rest of this paper is structured as follows. Section 2 addresses component and OO framework technologies and Section 3 discusses their advantages and limitations in the CSCL field. The potentials of component-based reuse to the CSCL field is illustrated in Section 4 through related work in other areas. The component-based architecture to support the design of CSCL applications based on reuse is addressed in Section 5. Conclusions and future work are presented in Section 6.

J.M. Haake and J.A. Pino (Eds.): CRIWG 2002, LNCS 2440, pp. 134–143, 2002. © Springer-Verlag Berlin Heidelberg 2002

A Component-Based Architecture to Support Collaborative Application Design

135

2 OO Components and FRAMEWORKS Reuse Technologies A framework is a reusable design of all or part of a system that is represented by a set of abstract classes and their interaction protocol [6] [12]. A framework offers an application skeleton that can be customized by a developer, who refines the abstractions provided by the framework, create and initialize objects, and connect them to define the global behavior of the application. Frameworks are described in terms of a programming language, possibly accompanied by documentation orienting on their reuse, although in practice the lack of documentation is a chronicle problem of reusable artifacts [17]. According to the expected customization process, frameworks are classified as white-box and black-box [6]. White-box frameworks are considered harder to apply, since they subsume extensive use of inheritance, which requires the understanding of programming internal details. Black-box frameworks are easier to apply, since one only needs to know the interface of the expected objects. On the other hand, they are harder to design, because one has to provide flexible interfaces that represent a comprehensive set of reuse situations. Components are self-contained, clearly identifiable artifacts that describe and/or perform specific functions and have clear interfaces, appropriate documentation and a defined reuse status [17]. Although this definition is broad enough to include all types of artifacts (e.g. source code, designs), most works focus on the deployment aspect of components and their ability to be combined to form larger system [4] [11] [14] [17]. Component-based systems rely on a component model on which to base the deployment and communication of components. Well-known infrastructure component models (also called component frameworks) are CORBA, Enterprise Java Beans, and DCOM. Component-based development (CBD) is primarily considered an assembly and integration process [4], in which: a) potentially interesting components are gathered, analyzed in detailed and selected; b) selected components are adapted to a particular context; c) adapted components are assembled via some form of common infrastructure. Adaptation in components can be performed through various white-box and black-box techniques [2] (e.g. wrappers, mediators, translators, OO techniques). The extension or modification of behavior for new, unforeseen aspects is more difficult to perform if the component implementation is hidden and inaccessible. Although OO frameworks and components are independent technologies [3][11], research efforts have been directed towards the complementary nature of these technologies for achieving effective reuse [14].

3 CBD and OO Frameworks in CSCL The CSCL domain is interested on the potential benefits provided by OO frameworks and components in terms of quality and productivity, and a number of generic environments, frameworks and toolkits for developing CSCL applications are available. Some of them address the collaborative domain but can be adapted to educational settings, whilst others are specifically targeted at this domain. Component technology is mostly available through specific CSCL configurable environments, such as AulaNet [7] and WEBCT [19]. This type of system can be regarded as a specific-purpose component model, in which components useful for

136

A.P.T. Bacelo Blois and K. Becker

educational purposes can be tailored and plugged (e.g. chat, email, discussion lists). A common characteristic of these environments is the restrictions they impose on the inclusion of new components, or extensions to existing ones, since the tailoring is limited to a few, non-crucial aspects (e.g. size, color). Thus, they are easy to adapt as long as application developers (in this case, mostly educators) resign themselves to the components offered by the model. The need for more open approaches is highlighted by Rochelle et al. [16], who describe some experiences using generalpurpose component models such as Java Beans. However, application developers would be focused on the technical challenges of implementing and plugging components (i.e. Beans) in this component framework, and restricted to that particular technology, without support for the overall design of their application. OO frameworks exist for the development of collaborative applications, which can be adapted to the CSCL context, and some considerations on their reuse are reported in [1]. Frameworks for this domain can be divided into two main categories, based on the abstraction level of the classes they provide: 1) frameworks that offer high level abstractions, based on concepts that frequently appear in these applications (e.g. user, session, role), and 2) frameworks that provide infrastructure abstractions for this domain (e.g. communication, synchronization, distribution, concurrency, etc). TOP [9] is an example of the former category, whereas Habanero [10] and Groupkit [8] are examples of the second one. Since frameworks represent reusable designs, the main challenge in developing a new application is to map one’s application in terms of these generic designs, extending existing classes and complementing with new ones whenever necessary. However, since frameworks are expressed as a set of programming classes, frequently this mapping involves implementation issues mixed with design ones. Additionally, the lack of documentation further difficult the application design activity, since one has to understand code in order to map his application into the abstractions of the framework. Considering the two types of reusable solutions discussed above, it is possible to notice that little support, if any, is offered to the application design phase. The goal of the design phase is to detail a software solution for a problem investigated and detailed in the analysis phase. One has to identify which available reusable elements may correspond (in isolation or combination) to abstractions of the domain, necessary extensions and/or modifications, and how they can be combined to achieve the overall goal of the application. Performing these tasks with various concerns in mind, in particular programming ones, introduces additional difficulties, limiting the expected benefits of reuse

4 Related Work Some interesting proposals for application design support based on reuse that are not specifically related to the CSCW/CSCL field can be found in the literature. They are presented here in order to illustrate the potential of benefits of CBD applied to earlier phases of application development. Jung and Biersack [13] propose a component-based architecture for the design and implementation of software communication systems. The architecture includes domain components targeted at the specification of communication processes among software through distinct, heterogeneous communication protocols. These

A Component-Based Architecture to Support Collaborative Application Design

137

components (e.g. entry, worker, etc) are targeted at the main aspects of a communication protocol, such as message processing and interface with the network. The reuse of these components is supported by a visual binding tool that allows the specification of the communication protocol at hand in terms of the interfaces defined for these domain components. Through the tool, the designer selects, configure and connects the necessary components. The visual biding tool hides the technical aspects of connecting Beans by providing a more abstract, domain-oriented view that focus on connecting protocol definition components. Mathews and Collins-Cope [15] address components for the design and implementation of applications in the financial domain. Components are organized in a multi-layer architecture, which addresses different aspects of this class of applications. The first layer organizes activity components (e.g. financer, credit line). This layer represents the activities to be performed through the system, organized as activity components, use cases, application controllers and user interfaces. These elements manipulate business components organized in the second layer of the architecture, which represent domain objects (e.g. account, profile, financial instrument). The third layer handles persistence components, which provide a set of services that handle the technical aspects of interfacing the application with a database system. To support the application development process through the reuse of these components, the authors also suggest a number of methodological directives involving the overall application development process. These works illustrate a number of interesting features of component technology. First, they provide interfaces with hidden implementations that are more easily connectable than classes/instances in OO frameworks, since not necessarily they are expressed in terms of programming languages, nor require advanced technical skills for their comprehension and binding. Second, components do not necessarily express abstractions in terms of code, nor are directly related to a specific component framework. These component frameworks can underlie the implementation of a specific component model in a transparent manner. Third, domain components can be organized architecturally, such that the distinct concerns and abstraction levels to be handled by an application developer can be organized and isolated. Finally, the design and implementation of a specific application can be oriented by guidelines or more sound methodological support. These characteristics can be contrasted with the current state of the art of CDB in the CSCL area described in Section 3.

5

A Component-Based Architecture to Support Collaborative Application Design

5.1 Motivations and Goals In this paper, initial ideas are presented considering a component-based architecture to support the design of CSCL applications. Presently, definitions on what constitutes a CSCL application and the basic requirements for this domain have reached no consensus [1]. Thus, we assume that the striking feature of applications in this domain is the computer-mediated communication, cooperation and information sharing in learning environments. This architecture is motivated by the difficulties involved in the reuse of frameworks, as discussed in Section 3, as well as the potentiality of

138

A.P.T. Bacelo Blois and K. Becker

component-based technology for supporting the design of new applications, as illustrated in Section 4. The main goal is to allow a CSCL application designer to primarily focus on the design of his application, based on the selection, adaptation and binding of domain components. Components are more adequate than frameworks to this goal because they focus on interfaces, and not on implementations. Their binding is established through a specific component model, which can range from technical infrastructure-oriented model (e.g. CORBA, Enterprise Java Beans), to specific domain or goal-oriented component model, the latter with the aim of hiding the technical aspects involved. Components are also self-contained, and this independence allows abstractions to be encapsulated according to various granularities. However, their weak point is extensibility, and therefore the architecture assumes that many advantages can be obtained in combining framework and component technologies to overcome this limitation. It is assumed that the provision of components and their reuse to develop specific applications are responsibilities of people (or teams) with distinct profiles, referred to as component developer and application designer. The former has a more technical profile, extensive experience with programming and component models/frameworks, and possibly familiarity with one or more frameworks targeted at the CSCL/CSCW domain. The latter has a deeper comprehension of the characteristics of the application, and a fair amount of technical skills to understand and apply components, possibly by suggesting extensions to their interfaces. Thus, both profiles are qualified in activities underlying software engineering and CBD in general, and they vary in their specific skills related to programming, frameworks knowledge, component infrastructure knowledge and modeling knowledge. They also have to interact a lot with each other in the sense that the activity of application designers are input for the definition of new components, and conversely, the available components are the primary input to the application design activity. The proposed architecture has the following specific goals: œ To enable an application designer to focus on the design activity of CSCL applications, without technical infrastructure or programming concerns; œ To distinguish between the role of application designer, responsible for designing a specific application through the reuse of components, from the component developer role, who specify and implement a family of adaptable components targeted at the domain; œ To provide CSCL domain components and simple means of integrating them to design new applications, based solely on components interface description and appropriate documentation; œ To base the binding of components on a communication model that abstracts (i.e. hide) technical infrastructure concerns, possibly through a visual binding tool; œ To provide a general architecture that provides separation of concerns, with regard to the various types of elements and activities involved in the development of CSCL applications, with well-defined interaction protocols; œ To benefit from the extensibility of frameworks to implement executable components, and to extend existing ones to meet new requirements; œ To establish the mapping between design and executable components, so as to generate, as automatically as possible, the corresponding implementation of an application designed through the binding of components.

A Component-Based Architecture to Support Collaborative Application Design

139

Figures 1 and 2 presents the overall scenario of the proposed architecture. Figure 1 concentrates on the activities from the Component Developer’s perspective, whereas Figure 2 describes the architecture from the Application Designer´s point of view.

Application Designer 1 Construction of design components and interface specifications

1

Design Components COLLABORATIVE EDITOR

2 Implementation of executable components that conform to interfaces

Chat Java

(DIS)CONNECTION

ENVIRONMENT

Executable Components

2

Component Developer

CONTROLLER

CHAT

EMAIL

USER

COMMUNICATION NEWS

VOTING

1

Support Components

Activity Components

E-mail Framework1

Framework 1

Voting Framework1

Environment Framework1

Disconnect Framework2

(Dis)connection Java

User Java

Framework 2 Programming Language (e.g. Java )

Fig. 1. Activities of the Component Developer Role

5.2 Component Types Components in this architecture can be classified according to two dimensions: abstraction level and purpose. The first dimension distinguishes between design components and executable components. Design components have clear interfaces that describe the services provided, and are expressed using UML [14]. The goal is to highlight what a component does and how it can be plugged to other components. Besides interface specification, appropriate documentation is an integral part of design components [17]. Each design component can have different implementations, i.e. corresponding executable components. Design components are thus similar to the notion of adaptable component [5], which represents a family of similar interchangeable software components. Executable components can be implemented using programming languages or CSCL/CSCW frameworks (e.g. [9][10]). They can be either open source (reveal their internal details) or closed source (executable code). In case variations on the interface and/or behavior implementation are needed, the former type can be more easily extended (e.g. using traditional OO mechanisms). In case of closed source components, adaptations are more difficult or limited, and wrappers and mediators are commonly employed techniques [2]. The second dimension is the purpose of components with regard to the CSCL domain, where two types of components can be identified: activity components and support components. Activity components represent common tools used to perform collaborative tasks in learning environments. Possible examples in this category are email, chat, news, collaborative editor, structured discussion, voting, agenda, etc. They are referred to as activity components for they provide services targeted at performing collaborative interaction, such as communication, cooperation or information sharing. Support components aim at the specification of how activity

140

A.P.T. Bacelo Blois and K. Becker

components can be integrated in a collaborative environment, so as to fulfill the overall goal of the learning application. Among the support services identified so far are: a) the creation of a cooperative learning environment; b) the creation of users acting in this environment, the type of activity they are to perform, and their specific roles in these activities; c) the communication (exchange of objects and information) between activity components; d) the establishment and control of how users cooperate and collaborate through activity components (e.g. order of activities, rules). One of the aims in distinguishing activity and support components is to render the former independent of context. They represent activities performed in the CSCL domain, which can be viewed in different granularities (activity vs. basic operations for performing such activities). Support components are used to integrate them in a number of different ways, each of them requiring a distinct kind of support. Another goal is to make the component adaptation (extension, modification) task, particularly of activity components, easier. Indeed, the support required may remain the same regardless if new activity services are offered, or if they are performed differently. In this research, we do not focus on activity components: as the domain evolves, new forms of interaction will be proposed for this domain [1]. We assume that the examples mentioned above are representative of the domain, and new ones can be included at will. Our concern is the definition of a kernel of support components, which are generic and representative enough of the integration possibilities and requirements in the collaborative domain. At the present stage of our research, based on the support services identified above, the defined support components are Environment, User, Communication, (Dis)Connection, Controller. Further investigation is required to confirm the need for those services, their coverage with regard to the domain, their ortogonality, as well as their precise role as activity component integrators. Figure 1 presents the activities underlying component development process comprising both design and executable components (activities 1 and 2). Notice that the Application Designer influences on the development of new or modified design components, by expressing their requirements in terms of specific applications. 5.3 Application Development Figure 2 highlights the proposed architecture according to the application designer point of view. It details the activities to be performed by this role, the type of components handled in each activity, and the relationship between activities and their outputs, as well as among activities. According to the proposed architecture: (1) based on an informal specification of his target application (e.g. a set of requirements, a set of use cases), (2) the designer selects the possible design components that can be reused to design his application. Those components represent on the one hand the various collaborative activities to be performed (i.e. activity components). On the other hand, the candidate support components necessary to integrate them must also be selected, which can be a less trivial task. These components must be analyzed, and the suitability of their interfaces must be verified. In case interfaces must be adapted, we assume that the application designer must interact with the component developer to solve this problem. Having selected the components, (3) the designer can then integrate activity components through the support components, so as to specify the collaborative characteristics of his application. The next task (4) is to bind the

A Component-Based Architecture to Support Collaborative Application Design

141

appropriate executable component to the configured design components used to design the application, and several options may be available. Another scenario is that, although the interface of the design component is suitable, none of the existing executable components are adequate, for instance, because some modification on how the behavior is performed is necessary, or because another implementation platform is required. In that case, we assume again that interaction with the component developer is required. The final result is a skeleton of the final application, in which adaptations and refinements are necessary (e.g. refinement of an open source component). Once all components are fully implemented, the application can be executed according to the underlying component model. Application Designer

Specific Application Requirements

chat environment

Meeting Room Talk on-line

Application Design

Talk through e- mail

2

1 Informal Specification

Access

Design Components Executable Components

Designed Application

communicacion

user

3

Selection of components for application design

Activities Components

e-mail

4 Binding of design components to executable components Support Components

Generic Solutions E-mail Framework1

Chat Framework1

Chat Framework2

Controller Programming Language

Controller Framework2

5

Application Skeleton Generation and Refinement (programming, adaptations, extensions) Meeting Room Meeting Room 6 Talk on-line Talk through e-mail Chat Frameworks 1 E-Mail Framework 1 Final Application Access PL

Access

Fig. 2. Activities of the Application Developer Role

This development scenario implies several research issues, among them: a) tools adequate for selecting and inspecting candidate components; b) the consolidation of the support components proposed, and the identification of integration characteristics that convey to the choice/need of certain support components; c) tailorability of activity design components and the static and/or dynamic aspects that can be specified through the support components (e.g. control flow, object flow, properties inherent to each type of support, etc); d) visual tools enabling the tailoring and integration of design components; e) types of adaptations that can be performed by each role, with the corresponding tool support; e) selection criteria for executable components and corresponding tool support; f) compatibility and integration issues between components developed with different frameworks/programming languages; etc. 5.4 Expected Results The research issues that concluded the previous section are far too complex and ambitious to be considered at once. Therefore, more concrete, short terms goals were

142

A.P.T. Bacelo Blois and K. Becker

defined to verify the suitability of the architecture with regard to the settled goals. In a short term, the following results are expected: œ identification of a set of representative activity components; œ identification of a set of support components that are representative of the integration issues in both collaborative applications, and component binding in general. The initial set proposed in this paper must be validated, consolidated, and their coverage, ortogonality and expressiveness must be proven; œ definition of the component instantiation process for both activity and support components; œ definition of the possible component composition and adaptation techniques; œ definition of the binding process between design and executable components; œ generation of an application skeleton from the reuse and binding of reusable components, which can be refined, extended or modified; œ proposition of a visual binding tool to support the selection and binding of design components, which hides the details of a particular infrastructure component model framework. It should be clear that many of the technical issues highlighted above transcend the CSCL domain, in that they correspond to open issues in the CBD research itself. But we are looking for (possibly) partial answers to those issues in restraining our concerns to the CSCL field, the domain components proposed for that domain and their specific adaptation and integration requirements.

6 Conclusions and Future Work In this paper, we discussed the advantages and limitations, with regard to the CSCL field, of two reuse technologies: OO frameworks and components. Framework technology is more extensible than component technologies, but in practice more difficult to apply: one has to dig into code in order to understand the framework, and map his application in terms of offered abstractions. Components focus on interfaces and can be expressed in more suitable notations than programming languages (e.g. UML). Despite independent technologies, one research direction has been to exploit their synergy. In the CSCL field, component technology has not been exploited in its full potentiality. We have presented some initial ideas on an architecture targeted at the component based design of CSCL applications. This architecture is based on the premisse that effective reuse can only be observed if a minimal set of requirements are met, particularly: focus on the application design activity; possibility of delaying implementation concerns for a later development phase; provision of useful reusable elements at the appropriate abstraction level; suitable mechanisms for understanding, adapting and binding reusable elements for configuring a new application; existence of appropriate environment support and methodological guidelines. Separation of concerns is one of the key ideas behind this architecture, and it is represented in a number of features, among them, the distinction between: design and execution components; support and activity components; component developer and application designer roles; design component integration and design and executable components binding, to mention a few. The proposed architecture raises a number of complex and ambitious research issues, and some of them, detailed in Section 5.4, have been

A Component-Based Architecture to Support Collaborative Application Design

143

prioritized to verify the suitability of the architecture for the achievement of the settled goals and identified problems.

References [1]

[2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19]

Becker, K.; Blois, A. Considerations on the application of object-oriented reuse th technology to the Computer-Supported Cooperative Learning Domain. In: 7 International Workshop on Groupware, 2001, Darmstadt. IEEE Press. p.164-169, Proceedings, 2001. Bosch, J. Superimposition: a component adaptation technique. Information and software technology, v.41, n.5, p.257-273. March 1999. Brown, A; Wallnau, K. The Current State of CBSE, IEEE Software, v.15,n.5, p.37-46, Sept-Oct. 1998. Brown, A.; Short, K. On Components and objects: the foundations of component-based development. In: 5th International Symposium on Assessment of Software Tools and Technologies, 1997, Pittsburgh. IEEE Press. p.112-121, Proceedings, 1997. Campbell, G. Adaptable Components. In: International Conference on Software Engineering, IEEE Computer Society Press. p. 685-686, Proceedings, 1999. Fayad, M. et al. Building application frameworks: object-oriented foundations of framework design. John Wiley & Sons, 1999. 664p. Fuks, H., Gerosa, M.A., Cunha, L.M. & Lucena, C.J.P. Groupware Technology for Cooperative Learning via the Internet, Electronic, In: International Conference on Engineering Education - ICEE, Oslo, Norway, Proceedings, 2001. Groupkit: Available at: http://cpsc.ucalgary.ca/projects/grouplab/groupkit. Guerrero, L.; Fuller, D. A Web-Based OO Platform for the Development of Multimedia Collaborative Applications. Decision Support Systems.v.27,n.3, p.255-268, Dec. 1999. Habanero. NCSA Habanero· 2.0 API. Available at: http://havefun.ncsa.uiuc.edu/ habanero/API/. Hopkins, J. Component Primer. Communications of the ACM, v. 43. n.10, p.27-30, Oct. 2000. Johnson, R. Frameworks = (Components + Patterns). Communications of the ACM, v.40. n.10, p. 39-43, Oct. 1997. Jung, M.; Biersack, E. A component-based architecture for software communication systems. In: Seventh IEEE International Conference and Workshopon the Engineering of Computer Based Systems, 2000, Edinburgh, IEEE Press, p.36–44. Proceedings, 2000. Kobryn, C. Modeling Components and frameworks with UML. Communications of the ACM, v.43. n.10, p. 31-38, Oct. 2000. Matthews, H.; Collins-Cope, M. Components in Financial Systems. International Workshop on Component-Based Software Engineering. Available in: http://www.sei.cmu.edu/cbs/cbse2000/papers/index.html. Roschelle, J. et al. Developing Educational Software Components. Computer, v.32, n.9. 50-58p. Sept. 1999. Sametinger, J. Software Engineering with Reusable Components. Springer, New York, 1997. 271p. Szypersky, C. Component software: beyond object-oriented programming. AddisonWesley, New York, 1999. 411p. Webct. Available in: http://www.webct.com/

Before Getting There: Potential and Actual Collaboration 1,4

2

3

Alberto L. Morán , Jesus Favela , Ana M. Martínez-Enríquez , and 1 Dominique Decouchant 1

Laboratoire “Logiciel, Systèmes, Réseaux”, Grenoble, France {Alberto.Moran, Dominique.Decouchant}@imag.fr 2 Ciencias de la Computación, CICESE, Ensenada, B.C., México [email protected] 3 Depto. de Ing. Eléctrica, CINVESTAV-IPN, D.F., México [email protected] 4 Facultad de Ciencias, UABC, Ensenada, B.C., México

Abstract. In this paper we introduce the concepts of Actual and Potential Collaboration Spaces. The former applies to the space where collaborative activities are performed, while the second relates to the initial space where opportunities for collaboration are identified and an initial interaction is established. We present a characterization for Potential Collaboration Spaces featuring awareness elements for the potential of collaboration and mechanisms to gather and present them, as well as mechanisms to establish an initial interaction and associated GUI elements. We argue that by making this distinction explicit, and characterizing Potential Collaboration Spaces, designers of groupware can better identify the technical requirements of their systems and thus provide solutions that more appropriately address their users concerns. We illustrate this concept with the design of an application that supports Potential Collaboration Spaces for the PIÑAS web-based coauthoring middleware. Keywords. Potential and Actual Collaboration Spaces, Potential Collaboration Awareness, Casual and Informal Interactions, PIÑAS, Doc2U.

1

Introduction

Managing information about collaborative efforts is very important to actually support collaborative work. Previously, this kind of information management has been addressed implicitly or explicitly under the form of session, meeting and conference management. Examples of these include the use of startup and run-time architectures for establishing and managing multi-user sessions in Rendezvous [38]; the use of a conference management module to maintain a synchronized state for two or more collections of application processes (or conferences) in MMConf [9]; the concept of session management based on user activities and the use of a publish/subscribe model to disseminate this information in Intermezzo [15]; the work on the user awareness protocol that recorded the presence of users on Web pages [36]; the utilization of rooms with persistent documents and tools in TeamRooms [41]; and the use of the NSTP protocol to maintain and communicate a centralized state of “things” in “places” in the Notification Servers [37]. J.M. Haake and J.A. Pino (Eds.): CRIWG 2002, LNCS 2440, pp. 147–167, 2002. © Springer-Verlag Berlin Heidelberg 2002

148

A.L. Morán et al.

Furthermore, providing information about collaborative efforts to users while they collaborate is also very important. This has been addressed mainly under the form of providing awareness information, conceived as focused and general awareness [20], informal awareness [25, 43], workspace awareness [23], peripheral awareness [39] and conversational awareness [47], to name a few. Also, these categories have been grouped and classified into macro-level and micro-level awareness, and characterized into an analytical awareness framework [47]. More recently, workspace awareness had been further detailed in a specialized framework [24]. As evidenced by these previous works, maintaining and providing information about the collaborative effort to users while they actually perform the work has been considered very important. However, the ability to discover opportunities for collaboration and establish initial contact to be able to initiate or launch the actual collaborative work has received little attention, until recently. Some exceptions to this includes work on Media Spaces: RAVE, Portholes, and CRUISER [20, 14, 19]; Informal communication and awareness studies by Kraut and Streeter [30], Whittaker et al., [48], Whittaker [51], and Isaacs et al. [28]; and systems: Peepholes, and Piazza [22, 27]. More recently another important body of work on casual, informal and lightweight interactions: TeleNotes, LambdaMoo MUD, Babble, ConNexus, WebWho, and Hubbub [50, 7, 4, 17, 46, 44, 29], has, more explicitly, addressed the issue of establishing initial contact to be able to start or launch the actual collaborative work. In this paper, we call attention to the importance of conceptually separating the actual collaboration space where collaborative activities are performed, from the initial space where the potential for collaboration is identified and an initial interaction is established. To do so we introduce the concept of Potential Collaboration Spaces, defined by the marriage of two sets of elements, those of awareness that afford discovering the potential for collaboration, and those of interaction to establish initial contact and effortlessly move from this potential space to the actual place where collaborative activities will take place.

2

Potential and Actual Collaboration Spaces

Traditionally, most groupware models and systems consider a unique Global Collaboration Space where collaborative activities are identified, initiated and performed. This has lead to the development of systems, toolkits, and frameworks [e.g. 41, 2, 21] that adequately support specific collaborative efforts, which use session, conference or meeting management mechanisms to specify the way in which people join together in collaboration [15, 31]. On the other hand, there is ample evidence supporting the need for seamless transitions between the spaces where individual work is performed and those where collaborative work takes place [13, 35, 41, 29]. Fig. 1 shows the representation of an instance of collaboration, where individuals can move from performing individual work to working as a group, and vice versa, as required by their situation. As mentioned earlier, we propose to conceptually separate the traditionally Global Space into Actual and Potential Collaboration Spaces, to better support identifying, initiating and performing collaborative work. On one hand, Actual Collaboration Spaces are designed to efficiently support the

Before Getting There: Potential and Actual Collaboration

149

three axes of ongoing collaboration [6]: allow users to concentrate in communicating about their work, in coordinating their actions to optimize the group’s performance, and in producing the results expected from the collaborative activity. On the other hand, Potential Collaboration Spaces are designed to allow users to discover, identify and create opportunities to establish or re-establish the initial interaction that may or will result in further interactions to accomplish collaborative work or to resume a previous ongoing collaborative effort. Perform individual work not_interested / ignore don’t_engage / ignore Identify * potential for collaboration

suspend

interested resume

Perform collaborative work

Establish * initial interaction

finish

engage

finish

Fig. 1. Identifying the potential for collaboration, and establishing the initial interaction are usually made while performing individual work.

As both kinds of spaces allow for collaboration, they share some or most of their elements and characteristics, however, the kind of collaboration that each space aims to support results in one case in highlighting some of these features, while in the other case results in moving them silently to the background, if not removing them from it at all, while highlighting others. Thus, Potential Collaboration Spaces aim to provide the user with enough pertinent information, not only from the current context of work, but also from outside of it, to identify, create, establish or re-establish that initial interaction that will lead them to collaborative work in Actual Collaboration Spaces. Furthermore, in Actual Collaboration Spaces, the information provided must come from the current context of work, because information coming from outside that context can, and most certainly will, result in interruptions (perhaps undesired) of the current focused collaborative work. Finally, Actual Collaboration Spaces, conceived as Global Spaces, had been previously classified and characterized based on general aspects such as time/space (synchronous vs. asynchronous, co-located vs. remote) and application-level functionality (communication, coordination or production oriented) [16]. Further characterizations exist based on more particular aspects for the support of actual collaboration (e.g. workspace and conversational awareness [23, 24, 47]). However, these latter characterizations are not well suited for Potential Collaboration Spaces, as they were conceived focused on Actual Collaboration Spaces, and a more adequate characterization is required. In the following section, we present and describe our proposal to characterize Potential Collaboration Spaces.

150

3

A.L. Morán et al.

Features of Potential Collaboration Spaces

The two most important features that Potential Collaboration Spaces support are Awareness for Collaboration and Initial Interactions, which allow users to become aware of the potential for collaboration, and to establish the initial interaction that may lead to actual collaborative work, respectively. For this reason, we need to i) identify the elements of awareness required to detect the potential for collaboration, ii) the kinds of mechanisms available to gather and present these elements, as well as iii) the kinds of interactions that fulfill the requirements for establishing that initial interaction and iv) their mechanisms. As a first step, following an approach based on the one used by Gutwin and Greenberg [23, 24] and Vertegaal et al. [47] we use the 5Ws questions– “Who, What, Where, When, and hoW” – to establish the core awareness elements that make up a Potential Collaboration Space and that provide the features just mentioned. That is: When present in a Potential Collaboration Space, a user needs to know WHO is available for potential collaboration, and optionally, WHERE are they and WHAT are they doing, to determine WHEN is the adequate moment to contact or “interrupt” them, and HOW we should do it, so we are not inadequately intrusive or disturbing? In these previous studies, information is gathered considering past and present situations on a shared workspace. In our case, in contrast, we extend the scope to gather information not only from the shared space, but also from individual spaces. Additionally, we include the use of information on future situations, relying on information stored in calendar and scheduling applications as an estimate of what might happen. Present situation information serves as a means to allow a user in the Potential Collaboration Space to handle the potential for collaboration for synchronous situations, since what is important in the first place, is to become aware of the presence of “reachable” individuals, whether in a shared space (same space), or in other different shared or individual spaces (different spaces). Information about past and future situations, allow users in the Potential Collaboration Space to handle the potential for collaboration for asynchronous situations, as what is important in this case, is becoming aware of others by i) finding “traces” or “footprints” of past presence or activity whether in a shared place (same space) or in mutually accessible objects in different shared or individual places (different spaces); and ii) by finding information about “probable” availability of others in the time to come (same and different spaces). 3.1

Relevant Elements and Questions to Define Potential Collaboration Spaces

Based on the 5Ws approach, we identify relevant elements and questions to determine the information that makes up a Potential Collaboration Space. The information will be gathered from individual or collaborative environments of others, from the point of view of the current user, with the aim of becoming aware of their presence and availability in those spaces to establish the initial interaction, and to determine the appropriate timing for that interaction.

Before Getting There: Potential and Actual Collaboration

151

Table 1 depicts a basic set of elements and questions for present, past and future situations that will provide us with information to make up a Potential Collaboration Space that supports awareness of the potential for collaboration. Specific instances of collaboration spaces do not have to include all of them or be limited to the elements identified here, as this basic set does not intend to be exhaustive, but a starting set from where to select specific elements, or that can be extended according to specific requirements. Table 1. Elements of potential collaboration awareness and corresponding questions for present, past, and future situations. Category Who

What

When Where

Element Presence Identity Authorship Other people Actions Intention Artifact Abilities History Expectations Location Gaze View Reach

How

Activity level

Question Who [ is / was / will be ] present or “near” by? Who they [ are / were / will be ]? Who [ is / was / will be ] doing that? Who [ do / did / will] they work or communicate with? What [ are / were / will ] they (currently / be) doing? What goal [ is / was / will be ] the action part of? What object [ are / were / will ] they (be) working on? What [ can / could / will ] they (be able to) do? When that had happened? When it will happen? Where [ are / were / will ] they (be)? Where [ are / were / will ] they (be) working? Where [ are / were / will ] they (be) looking? Where [ can / could / will ] they (be able to) see? Where [ can / could / will ] they (be able to) reach or make changes? How active [ are / were / will ] they (be)?

Once a basic set of elements to provide awareness support for the potential of collaboration has been established, we identify the mechanisms used to gather and present this information to the user. 3.2

Obtaining and Presenting Information to Support Awareness of the Potential for Collaboration

Traditionally, models of awareness have considered the existence of an explicit “pool of objects shared by a community of users as a shared space” [40, 23, 24]. With that explicit shared space in place, the actions of its users are represented and made available to other users of the application or workspace [op. cit.]. In our current approach we propose to extend the scope of these models to consider not only those objects that are explicitly shared and that form part of an explicit shared space, but also those that, although “mutually accessible”, are not considered part of it, because they are not shared at all, or because all efforts have been made to provide us with the illusion of exclusive ownership and access to the objects by hiding any evidence to the contrary. To illustrate our case, let’s consider some simple examples: 1. A Multi-user computer where all users though sharing the system are provided with the illusion of accessing an “individual virtual” computer of their own.

152

A.L. Morán et al.

2. A database managed by a DBMS that enforces the ACID (Atomicity, Consistency, Isolation, and Durability) properties on it to ensure mutually exclusive access for certain operations and results. 3. The traditional WWW, that although shared by millions of users, which navigate around from their individual spaces without being aware of others, remains to them a lonely place. In these examples, at the user’s level of abstraction, the use or access to the objects is considered as being mutually exclusive, and the objects per se are not considered as being shared. However, at a meta-level, there is (or could be) an entity that manages, and some times even enforces, multiple accesses to the objects in a mutually exclusive way, and that knows that the object, at a certain degree of granularity, is being shared, and by whom, among other things. In this way, we identify the existence of such meta-level and propose to take advantage of the information that can be gathered using it, not necessarily to share individual objects or spaces, but to share the specific information to identify the potential for collaboration among users. Thus, users remain in different shared or individual spaces but are able to obtain enough information for them to become aware of others and to initiate an interaction and the appropriate time to do it. Once this extended scope has been defined, we briefly describe the approach proposed based on the awareness model of Benford et al. [3] and Rodden [40]. Initially, we define the aura of an object within an environment. The aura is the sub-space or function which effectively bounds the presence of an object within a given medium or set and which acts as an enabler of potential interaction. Later, the environment must provide the necessary support to detect the collisions of auras of different objects in specific mediums, as when such collisions occur, the interaction between the colliding objects becomes a possibility, and the environment must put the involved objects in contact. Once the potential for interaction has been determined by means of aura collisions, the objects themselves are responsible for controlling the resulting contact, which is achieved based on quantifiable levels of awareness between them. The level or strength of awareness between two objects A and B is a function of their respective focus and nimbus. The focus is a function that projects the presence of other objects to you: “the more an object is within your focus, the more aware you are of it”, while the nimbus is a function that projects your presence to other objects: “the more an object is within your nimbus, the more aware it is of you”. Finally, based on the resulting awareness level, decisions can be made on whether to present this information to the users, and on how to present it. Mechanisms to Implement Aura and Aura Collisions Specific mechanisms to define object auras and detect aura collisions can be of two kinds, explicit or implicit. Explicit mechanisms (also known as active mechanisms [13]) are those that rely on information provided actively by users, and hence, require explicit actions from them in addition to those related to their main activity. An example of explicit mechanisms is the use of user directories, built with profiles that users provide when creating an account for a specific system (e.g. Yahoo, and Hotmail). Another example is the use of explicit evidence left by users on

Before Getting There: Potential and Actual Collaboration

153

artifacts or places (“Calling cards” on documents in I2I [5] or “post-it notes” on objects or rooms in TeamRooms [41]). The system uses this information to “match” users (create the aura and detect the collisions) based on the specified interests or preferences. On the other hand, implicit mechanisms (also known as passive mechanisms [13]) are those that rely on information collected by the system while users perform their main activity. Further, implicit mechanisms can be sub-classified in artifact-based, activity-based or place-based. In each of them, using the same artifact, performing the same activity or being in the same place are used by the system to determine aura and aura collisions. Examples of implicit mechanisms are the use of on-the-fly profiles and directories based on the content of the documents they use as in I2I [5], the places they visit as in Livemaps [8], and the tasks they perform as in Piazza [27]. Mechanisms to Present Information on the Potential for Collaboration Specific mechanisms to present information on the potential for collaboration as a result of aura collisions allow users to become aware of opportunities for collaboration, and perhaps motivate them to initiate interaction. Evidence in the literature points out that this kind of information should be presented in the least intrusive way to the users, so that they are not distracted from their main activities [19, 45, 10, 29]. Furthermore, these mechanisms should allow for lightweight means of obtaining the information and deciding how to respond to them or even ignore them effortlessly. Awareness information on the potential for collaboration can be presented directly as it was obtained or can be further processed to remove some of the “direct” information and presented in an abstract way [39]. Direct methods of presenting this information include those used in media spaces that provide any combination of live or intermittent audio and video information as in Cruiser [19], RAVE [20], Portholes [14], Montage [45], Piazza [27] and Thunderwire [26] among others. When used in this way, users are in charge of perceiving and processing the data to obtain the required information. Although in this approach some data processing is left to the users, it is done with little or no effort as we as users normally do that kind of processing in our daily lives. However, we must be careful when using this approach, as presenting this kind of information doesn’t scale well when the amount of sources increases; also audio information can be very intrusive and easily invade the space of others, and video information may require considerable screen real state. Finally, its use might easily lead to unwanted revelations [43]. On the other hand, abstract methods for presenting this information, that although may require more cognitive effort from users to learn and interpret the information as something has been removed or hidden, allow to highlight the important or desired aspects of the information, to concentrate an increasing amount of information on the same display element, and to better manage screen real state, among others. Examples of this kind of representation include those of radical abstraction: audio and video data abstracted to wave sounds, temperature changes, rotation and cloud animations [39], and other less radical: the use of animated icons to represent social activity [1], and interaction attempts [45]; animated bar charts to denote amount of interactions [1] or activity meters [29]; social network graphs [1] and social proxies [4, 17] that denote not only amount of activity, but also semantic relevance of message content;

154

A.L. Morán et al.

contact lists that provide presence and status information by means of text lists or iconified images [27, 41, 46, 29], and sounds to denote activities or changes on the states of objects [33, 29] among others. 3.3

Establishing the Initial Interaction

The second feature of Potential Collaboration Spaces is their capability to provide the means to establish an initial interaction that might lead to actual collaborative work. In the previous section we have discussed which elements of awareness make up a Potential Collaboration Space, how this information is gathered and how it can be presented to the user. This information provides a context that might motivate the user to initiate an interaction with a potential collaborator known to him or not. Now we need to identify and establish the kind of interactions that can or will be used, which are the characteristics of such interactions, and which mechanisms can be used to establish them. Regarding the kind of interactions, Isaacs et al. [28], classified them as Formal or Informal, based on the type of interpersonal communication used to establish it. Formal interactions are those that require planning in advance by all involved parties, and are also known as Scheduled interactions. Informal interactions are those that are not scheduled in advanced. These kinds of interactions are further classified into Intended or Unintended. Intended interactions are those that occur when one person seeks out another to discuss a specific topic, but where there is no pre-arranged plan to talk. Unintended interactions are sub classified into Opportunistic and Spontaneous interactions. Opportunistic Interactions are those that occur when one person happen to see another and remembers that they wanted to discuss a particular topic. Finally, Spontaneous interactions occur because two people happen to see each other and get into a conversation on a topic not prepared by either person. Potential collaboration spaces must provide support for all these kinds of interactions, to let users choose the one that best fits their current needs. However, we also consider that informal interactions are the ones that best fit our purpose of establishing or re-establishing an initial interaction just after identifying the need or the potential for collaboration. Characteristic of Initial Interactions Regarding the characteristics of informal interactions Whittaker et al. [48] identified them as being brief, unplanned, frequent, often dyadic, frequently supported by shared objects such as documents, intermittent, and lacking of formal openings and closings, and dependant on physical proximity. Further studies challenged the last of these characteristics, and offered lightweight technological communication solutions, which have been successfully used by remote collaborators to a certain extent. For instance Whittaker et al. [50], noted the importance of supporting conversational threading, one way drop communications, quick connections, context preservation and regeneration as well as support for shared objects to successfully support lightweight (or informal) interactions. Churchill and Bly [7] on the other hand, found that supporting these lightweight interactions allowed people to engage in quick interactions that function as a mechanism to convey continuous presence in an

Before Getting There: Potential and Actual Collaboration

155

effortless and implicit way. Nardi et al. [34] identified what they called outeraction, a set of communicative processes outside the exchange of information in which people reach out to others in patently social ways to enable information exchange, including the negotiation of availability of others to initiate conversation, the maintenance of a sense of connection with others within an active communication zone and the ability to switch media in the course of a single communication event. Isaacs et al. [28] identified additional uses of this initial interaction in the workplace and discussed how they achieved their objectives. These include: Tracking people, taking or leaving messages, making meeting arrangements, document delivery, giving or getting help, and reporting progress and news. Another characterization of the initial interaction has been made based on the types of interactants and their group membership. The types of interactants include [28]: Project group members, cross-functional group members, peer group members, and external group members. Finally, a further characterization has been made based on the types of interactants and their frequency of interaction. It includes Interactants, which are sub classified into Frequent interactants and Non-frequent interactants [48]. Additionally we propose to include Non-interactants – the people with whom we haven’t established any interaction yet, and that represent not already discovered collaborators. Mechanisms to Establish the Initial Interaction The mechanisms to establish the initial interaction are heavily related to those used to present information on the potential for collaboration. Usually, the GUI elements used to launch the initial interaction are the ones used to present the availability, status, or location of the other user, or the mutually accessible artifacts to both of them. They provide a lightweight and effortless mechanism to contact others, and to move from an individual space to a shared space. Also, it is recommended to include several communication channels instead of only one, so that users have the possibility of choosing through which of them to contact other users as required by their current preferences or requirements – richer communication medium, synchronous or asynchronous nature of the interaction, or the need for an Actual Collaboration Space to perform collaborative activities. Moreover, as with mechanisms to provide awareness on the potential for collaboration, this kind of information should be unintrusive to the users. Examples of the mechanisms used to establish initial interactions include the use of image buttons and image matrices associated to the visual presentation of live video or images as in RAVE [20], Portholes [14], Montage [45], and Piazza [27]. The use of default actions associated to the select event of elements of contact lists as in Piazza [27], Montage [45], Babble [4, 17], I2I [5], ConNexus [46] and Hubbub [29]; The use of buttons and button toolbars of additional communication channels associated to the presence, availability, status, or location of the other user as in RAVE [20], Montage [45], Piazza [27], Livemaps [8], ConNexus [46], ContactMap [49], and Hubbub [29]; The use of abstract representations of mutually accessible artifacts as Post-it or Stickup notes in Montage [45], Teamrooms [41], Piazza [27], the Notification Collage [43], TeleNotes [50], and Calling Cards I2I [5]; and simple note icons as in BSCW [2], ConNexus [46], and Hubbub [29] among others.

156

3.4

A.L. Morán et al.

Considerations Regarding Privacy and Intrusiveness

Until now, we have not addressed two major concerns associated with Potential Collaboration Spaces: Privacy and Intrusiveness. Privacy issues result from the fact that becoming aware of the potential for collaboration requires obtaining and providing information about the 5w’s – Who, What, Where, When and hoW [19, 45, 51, 39, 5, 29]. For the people providing the information, there is the tradeoff between being available to others and controlling the kind and amount of information provided by them to convey that availability. On the other hand, for the people obtaining the information, there is always the tradeoff between being informed about the activities of others, and being distracted of whatever is their primary activity. Intrusiveness issues [45, 51, 34, 29] result from the fact that usually the time and topic that are convenient for the initiator of the interaction, aren’t the most convenient for the recipient, resulting in interruptions on the work being done. Several mechanisms have been proposed to deal with both of these issues as awareness information and the interruptions resulting from initial interactions are very important to get involved in collaborative work [42]. Regarding privacy, these mechanisms include limiting the amount of information or the amount of channels used to obtain it as in media spaces [48, 39], the use of individual and group access permissions {allowed, not allowed} enforced by the system and access modes {do not disturb, busy, etc.} socially interpreted and applied by the users as in Montage, Piazza and Hubbub [45, 27, 29], enforcing reciprocal membership and permissions as in instant messaging systems [29], providing double-blinded mechanisms to establish contact as in I2I [5], and explicitly be warned and requiring acceptance resulting in turning on or off this feature as in Portholes, Piazza and Livemaps [14, 27, 8]. Regarding intrusiveness issues, mechanisms include different methods of displaying the notification: pop-up and fade-in/fade-out windows [19, 45], changing and appearing images and icons in GUI components [14, 45, 27, 2]; playing sounds [39, 29]; and determining when the effect of the interruption is minimal based on the kind of interruption or on the kind of task or stage of the activity that the intended receiver is performing [10], among others. Finally, it must be clear that there is no unique solution or mechanism to properly deal with privacy and intrusiveness, as people tolerate different levels of privacy violations or intrusions from different kind of people or based on the current situation they are involved [28].

4

Using Collaborative Spaces in the Design of Groupware

As an example of our approach, we present the process followed to design an extended version of Doc2U [32], the current application implementing a Potential Collaboration Space for PIÑAS [11]. PIÑAS is a middleware platform aimed to support collaborative authoring of documents on the Web by providing a set of specialized services for the naming, identification, and management of authors, resources, sessions, and applications in a replicated architecture. As a first step in the design, we considered the main functionality of our Potential Collaboration Space: i) detect the potential for collaboration, ii) start initial

Before Getting There: Potential and Actual Collaboration

157

interactions, and iii) launch applications implementing Actual Collaboration Spaces; and explicitly separated it from that of the Actual Collaboration Spaces intended to support collaborative authoring of documents, including support for: i) specific writing activities (brainstorming, research, initial plan, write, edit, review/annotate), ii) focused awareness on them, and iii) seamless transitions among them, to name a few. This step, allowed us to concentrate our efforts on the specific characteristics needed to provide that functionality and design an application by means of the following steps, as outlined in section 3: • Specify the mechanisms to implement aura and aura collisions on designated objects, • Select elements of potential collaboration awareness and related mechanisms, • Select mechanisms to start interactions, and • Select GUI components to present information on awareness of the potential for collaboration and made interaction mechanisms available. 4.1 Designing the Potential Collaboration Space Currently, our Potential Collaboration Space provides support to automatically discover an adequate moment when potential collaborators are available to collaborate. The support to automatically discover unknown potential collaborators based on certain user’s criteria is planned for a further iteration. Specifying Mechanisms to Implement Aura and Aura Collisions The mechanisms used to implement aura and aura collisions are based on explicit approaches. The objects within PIÑAS that (currently) have auras are users and resources. The information to construct the aura of an object is obtained from the information explicitly provided by the user at registration time – when creating a user account in the PIÑAS platform – or when adding a resource to the repository. Aura collisions are modeled by means of “symmetrical subscriptions” negotiated between objects. Based on these subscriptions, the focus of one object is associated to the nimbus of the other, and vice versa, enforcing the symmetry of the subscription. This way, the possibility of interaction among subscribed elements is achieved. As a result of these symmetrical focus-nimbus associations, there are only two possible levels of awareness between every two objects: Aware (subscribed) and Not Aware (not subscribed). Thus, when object A is aware of object B, and by symmetry, object B is aware of object A, information on the potential for collaboration is provided to both objects. Otherwise, if object A is not aware of object B, and vice versa, no information is provided. Additionally, other mechanisms are used to obtain information to identify the potential for collaboration, these mechanisms include: • A space-based implicit mechanism that monitors changes in the availability (online or offline) of users and resources inside the space. • A space-based explicit mechanism that monitors changes in status (normal available, do not disturb, busy, in chat, away, etc.) of users inside the space.

158

A.L. Morán et al.

• An artifact-based implicit mechanism that monitors changes in the status (idle, partially available, locked, locked and reserved, etc.) of resources in the space. • An artifact-based implicit mechanism that monitors changes on user activity (reading, writing, annotating, etc.) on the resources they use, as well as changes (updated, read, etc.) generated by this activity on the artifact. Selecting Elements of Potential Awareness and Related Mechanisms The next step is to select the elements of awareness to be included, as well as the mechanisms to obtain and provide the information on them (see Table 2). Table 2. Potential awareness elements and mechanisms to obtain and provide them. Element Presence

Identity Authorship Other people Actions

Intention Artifact Abilities History Expectation s Location Gaze View Reach Activity level

Mechanism to obtain it Implicit – users and resources – place based and artifact based respectively Explicit – info provided by users at registration Implicit – activity based (operations on artifacts) Explicit – information specified in projects Implicit – activity based (operations on artifacts) Explicit – information specified in projects Implicit – activity based (operations on artifacts) Explicit – based on roles and permission in projects Implicit – activity based (operations on artifacts) Not considered Explicit – provided by user at login Not considered Not considered Explicit – based on info specified on projects Explicit – status provided by user at “run” time

Mechanism to present it Abstract – not radical – text / icons associated to contact / resource lists; status bar for own presence; audio associated to events Abstract – not radical – contact lists; application bar for own identity Abstract – not radical – text associated to resource lists Abstract – not radical – project contact lists Abstract – not radical – icons associated to resource lists; audio associated to events; pop-up notifications Abstract – not radical – text (description) associated to project Abstract – not radical – pop-up text lists / icons associated to resource lists Abstract – not radical – text / icons associated to project description Abstract – not radical – pop-up text lists associated to resource lists Not considered Abstract – not radical – text associated to contact lists Not considered Not considered Abstract – not radical – text (description) associated to project resource list Abstract – not radical – text / icons associated to contact / resource lists; status bar for own status; audio associated to events

Selecting Mechanisms to Start Interaction and Related GUI Components Once the elements of awareness for collaboration, had been defined, it is necessary to specify the mechanisms that will be provided to start interaction. Also, it is necessary

Before Getting There: Potential and Actual Collaboration

159

to specify the particular GUI elements that will be used to present the information, and the mechanisms to start the interaction. This information is presented in Table 3. Table 3. GUI components associated to the mechanisms to start interaction. GUI Component Contact list

Audio cue Project window

Project’s contact list

Project’s resource list

Resource list

Pop-up text list Pop-up and fade-in/out dialogs Availability and Status bar

Awareness Component – Mechanism to present it Identity – Element in contact list Activity level, Presence – Icon associated to elements in contact list Activity level, location, presence – Text associated to elements in contact list Actions, activity level, presence – Audio associated to event Intention – Text (overall / specific goal descriptions) associated to project window Other people – Element in project’s contact list Abilities – Text and Icons associated to elements in project’s contact list Reach – Text (description) associated to elements in project’s resource contact list Actions, artifact, presence – Icon associated to elements in resource list Authorship, presence – Text associated to elements in list Artifact, History – Associated to elements in resource list Actions, Activity level, Presence – Floating around to give notifications Activity level, Presence – Text and icons

Mechanism to start interaction

Default action (send synchronous message) associated to selected element. By means of Bar and Pop-up Menus and a Button Toolbar: Send synchronous or asynchronous instant messages, start chat session, start custom applications to/with selected potential collaborators N/A – Informational only

N/A – Informational only

Button to add potential collaborators to the project by explicitly providing their contact information or by searching them through the User Directory service Button to remove potential collaborators from the project Button to add resources to the project by explicitly providing them or by searching them through the Resource Management service Button to remove resources from the project Default action (send command) associated to selected element. Bar and Pop-up Menus and a Button Toolbar: Send synchronous or asynchronous instant messages, start chat session, start custom applications to/with all potential collaborators “reachable” by means of the selected resource N/A – Informational only, however interactions can be started by means of the mechanisms associated to resource element Buttons to initiate additional interaction mechanisms or to change the communication mechanism. N/A – Informational only

160

A.L. Morán et al.

Finally, the information presented in this section, defines a Potential Collaborative Space, and can be used to guide the implementation of an application. To illustrate this, an example is presented in the following section. 4.2 Current Implementation of the Potential Collaboration Space in PIÑAS The initial collaborative application used by PIÑAS, an extended version of Doc2U [32], our Instant Messaging and Presence Awareness tool, implements the previously described Potential Collaborative Space, and allows coauthors to: • Join the Collaborative Space inhabited by users and resources, • Be peripherally aware of potential collaborators and resources present in the Collaborative Space, • Interact (sending messages or commands) with potential collaborators and documents (respectively), • Launch additional applications implementing Actual Collaboration Spaces, such as Alliance [12] and COARSY [18], to collaborate with specific users on resources. The implementation of this Potential Collaboration Space was distributed among client and server modules of PIÑAS. Aura representations of objects and the mechanisms to represent aura collisions were implemented on the server side: • Aura representations of users and resources are provided by means of the user management service and the document management service, respectively. • The mechanisms to represent aura collisions as well as the implicit mechanisms to gather information are provided by means of the session management service, which manage not only the presence of users, but also the presence of documents, and by using its symmetric publish and subscribe notification mechanism. Other modifications involving GUI elements were made on the client side. The modules concerned were the Project Management tool, and the Doc2U client. To demonstrate some of the implemented functionality, we will present and describe several components of their GUI. We start with elements of the Project Management tool (see Fig. 2) used to define the collaborative project. Basically, the information and mechanisms provided include: • Title (Fig. 2A) and Description (Fig. 2B): These are used to give information on the context of the project, as well as overall and specific goal descriptions (Intention). Users provide this information explicitly at project creation / modification time. • Contact (author) list (Fig. 2C): Contains all current potential collaborators that participate in the project (Other People) as well as the permissions given to each of them (Abilities) to work on resources. Additional buttons allow adding collaborators (explicitly identified or found through the User Directory in the user

Before Getting There: Potential and Actual Collaboration

161

management service), and removing them from the project. Users explicitly provide this information. • Document list (Fig. 2D): Contains a list of the resources – documents – available in the project (Reach). Additional buttons allow adding other resources (explicitly identified or found in the document management service), and removing them from the project. Users explicitly provide this information.

(A) (B)

(C)

(D)

Fig. 3. GUI components used to present potential awareness elements and mechanisms of interaction in the Project Management tool: A) Title, B) Description, C) Contact List, and D) Document List.

Further functionality is available through the main window of Doc2U (Fig. 3) that provides most of the information and mechanisms of the Potential Collaboration Space. The information and mechanisms provided include: • Application bar (Fig. 3A): This is used to present information on the current user of the tool (Identity). The system obtains this information from the user profile. • Button toolbar (Fig. 3B): Besides common operations on collaborators / resources, it gives access to the mechanisms to send synchronous / asynchronous messages, start chat sessions with collaborators selected from the contact list and start custom applications to communicate / work with selected collaborators (own Abilities). • Contact and Document lists (Fig. 3C, 3F): Present a list of potential collaborators (Identity) and resources from which notifications are received (Artifacts). Depending on their availability (Presence) they can be placed in the online or offline sub-lists. Additionally, activity, status and location text and icons (Fig. 3D, 3G, 3I) are associated to list elements and dynamically updated as their state changes (Activity level and Location). To start interaction, the user only has to select a potential collaborator or document and use the default mechanism available, or select an additional mechanism by means of the Button toolbar (Fig. 3B) or the associated Pop-up menu (Fig. 3E). The information is gathered by the system using implicit space and artifact based mechanisms.

162

A.L. Morán et al.

• Pop-up menu (Fig. 3E) and Menu bar (Fig. 3H): Hierarchically organize common operations on collaborators / resources, they give access to the mechanisms to send synchronous / asynchronous instant messages, start chat sessions with selected collaborators from the contact list and start custom applications to communicate / work with selected collaborators (own Abilities). • Sound Cues (not a GUI element) and Pop-up notifications (Fig. 3J): Notify about the change on status or activity of potential collaborators and resources (Actions, Activity level, and Presence). Additionally, by means of buttons, pop-up notifications provide default elements to start an interaction or change the kind of interaction effortlessly. The information is gathered by the system using implicit space and artifact based mechanisms. • Availability and status bar (Fig. 3K): Present the current user settings for availability and status (own Presence and Activity level). Users explicitly provide status information at run-time.

(A) (B) (C)

(H) (I)

(D) (E) (F) (G)

(J)

(K) Fig. 4. GUI components used to present potential awareness elements and mechanisms of interaction in the main Doc2U window: A) Application bar, B) Button toolbar, C) Contact List, D) Contact availability and status icons, E) Pop-up menu, F) Document list, G) Document activity and status icons, H) Menu bar, I) Contact location and status text, J) Pop-up notification, and K) Availability and status bar.

4.3 Implications for the Design of Groupware We believe that our current approach considering the existence of Potential and Actual Collaboration Spaces has several implications on the design of groupware. These implications are on two levels: those related to the design of groupware in general, and those specific to the design of Potential Collaboration Spaces. Regarding the design of collaborative systems in general, designers can:

Before Getting There: Potential and Actual Collaboration

163

• Explicitly decompose the functionality of the traditional “Global” Collaboration Space into that required to i) discover the potential for collaboration and starting an initial interaction, and that to ii) support other more focused collaborative tasks. • Based on this decomposition, concentrate themselves in designing the specific features that each Collaboration Space is aimed to support, one space at a time. • Once their design is made, build groupware applications i) as an aggregation of modules or components implementing independent Potential and Actual Collaboration Spaces, or ii) build them in the traditional way overlapping them partially or completely. On the other hand, for the design of Potential Collaboration Spaces, designers can: • Further decompose the functionality into support to i) discover the potential for collaboration, and ii) start an initial interaction. • Follow the proposed approach, consisting in specifying i) the mechanisms to implement aura and aura collisions on designated objects, ii) the elements of potential awareness to be included, as well as iii) the related mechanisms to gather and present them, iv) the kinds of interaction and the mechanisms to start them, and v) the GUI components to be used. • Use the identified and proposed sets of i) elements of potential awareness, ii) kinds of interactions, iii) related mechanisms to both of them and iv) GUI components, as a starting point for the design of their Potential Collaboration Spaces, and from there, reduce them or extend them as needed by their current requirements.

5 Discussion and Conclusions Managing and providing information about current collaborative activities is very important to actually perform collaborative work. However, it is also important to identify opportunities of collaboration and starting an initial interaction to get into collaborative work. In this paper we highlight the existence of conceptually separated spaces that allow users i) to become aware of the potential for collaboration and establish an initial interaction that might lead to more focused collaboration; and ii) to actually perform collaborative work. Based on this, we introduce the concepts of Potential and Actual Collaboration Spaces, and identify some of the features and mechanisms of awareness and interaction required to characterize Potential Collaboration Spaces. We consider that by conceptually separating these spaces, and characterizing the Potential Collaborative Space, designers and developers, will more appropriately select which elements and mechanisms of awareness and interaction to include, thus better satisfying the requirements of users of both kinds of Collaboration Spaces. Furthermore, designers and developers could decide to implement in their applications each kind of space independently or by overlapping them, either completely or partially, or even allow applications to automatically adapt and dynamically customize themselves to provide combinations of these options based on implicit or explicit user preferences or run-time conditions. To illustrate the advantages of conceiving groupware using this approach, we define a sample Potential Collaboration Space and describe its implementation as an

164

A.L. Morán et al.

extended Doc2U application, our current implementation of a Potential Collaboration Space for the PIÑAS platform. Also, we identified a set of design implications that enable the development of groupware that better support identifying, initiating and performing collaborative work. Finally, we consider that this approach improves upon previous work in that: • It integrates and expands upon a diversity of observations, models and mechanisms of awareness and interaction. • It addresses Potential Collaboration Spaces and concentrates on two specific features of them: Potential collaboration awareness, and initial interactions. • It provides a starting point from where designers and developers can choose which potential awareness and interaction elements and mechanisms to include in their applications, and how to combine them, to better support the activities performed in both Collaboration Spaces.

Acknowledgements. This work was supported by ECOS and ANUIES (project M98M01); by CONACYT (project 33067-A); by CNRS-CONACYT (projects 9018 / E130-505 and 10395 / E130-706); and by SEP-SESIC and UABC (grant P/PROMEP:UABC-2000-08), with the scholarship UABC-125 provided to the first author. Finally, we would like to thank three anonymous reviewers for their insightful comments on this paper.

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

Ackerman, M. S., Starr, B.: Social Activity Indicators: Interface Components for CSCW Systems. In Proc. UIST’95. ACM Press. New York NY (USA), Nov 15-17 (1995) 159168. Appelt, W.: WWW Based Collaboration with the BSCW System. In: Proc. of SOFSEM'99, LNCS 1725, Springer Verlag, Milovy (Czech Republic), Nov 26 - Dec 4. (1999) 66-78. Benford, S., Bowers, J., Fahlén, L. E., Greenhalgh, C.: Managing Mutual Awareness in Collaborative Virtual Environments. In: Proc. VRST’94. ACM Press, Singapore, August 23-26 (1994). Bradner, E., Kellogg, W. A., Erickson, T.: The Adoption and Use of ‘Babble’: A Field Study of Chat in the Workplace. In: Proc. ECSCW’99. Kluwer September (1999) 139-158. Budzik, J., Bradshaw, S., Fu, X., Hammond, K. J.: Supporting On-line Resource Discovery in the Context of Ongoing Tasks with Proactive Software Assistants. International Journal of Human-Computer Studies, Vol. 56, No. 1, January (2002) 47-74. Calvary, G., Coutaz, J., Nigay, L.: From Single-User Architectural Design to PAC*: a Generic Software Architectural Model for CSCW. In: Proc. of CHI'97, ACM Press, Atlanta, Georgia (USA), March 22-27 (1997) 242-249. Churchill, E. F., Bly, S.: It’s All in the Words: Supporting Work Activities with Lightweight Tools. In: Proc. GROUP’99. ACM Press, Phoenix AZ (USA) Nov 14-17 (1999) 40-49. Cohen, D., Jacovi, M., Maarek, Y. S., Sorokova, V.: Livemaps for Collection Awareness. International Journal of Human-Computer Studies, Vol. 56, No. 1, January (2002) 7-23.

Before Getting There: Potential and Actual Collaboration 9. 10. 11.

12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28.

165

Crowley, T., Milazzo, P., Baker, E., Forsdick, H., Tomlinson, R.: MMConf: An infrastructure for building shared multimedia applications. In Proc. CSCW’90, ACM Press, Los Angeles CA (USA). October 7-10 (1990) 637-650. Czerwinski, M., Cutrell, E., Horvitz, E.: Instant Messaging and Interruption: Influence of Task Type on Performance. In: Paris, C., Ozkan, N., Howard, S., Lu, S. (ed’s.): OZCHI 2000 Conference Proceedings. Sydney, Australia, December 4-8 (2000) 356-361. Decouchant, D., Favela, J., Martínez-Enríquez, A. M.: PIÑAS: A Middleware for Web Distributed Cooperative Authoring. In: Proc. of the 2001 Symposium on Applications and the Internet (SAINT'2001), IEEE Computer Society and IPJ Information Processing Society of Japan, San Diego, California (USA). January 8-12 (2001) 187-194. Decouchant, D., Martínez, A. M., Martínez, E.: Documents for Web Cooperative Authoring. In: Proc. CRIWG'99, 5th CYTED-RITOS Intl. Workshop. on Groupware, IEEE Computer Society, Cancun (México), September 15-18 (1999) 286-295. Dourish, P., Belloti, V.: Awareness and Coordination in Shared Work Spaces. In: Proc. CSCW’92. ACM Press, Toronto (Canada) November 1-4 (1992) 107-114. Dourish, P., Bly, S.: Portholes: Supporting Awareness in a Distributed Work Group. In: Proc. CHI’92, ACM Press, Monterrey CA (USA) May 3-7 (1992) 541-547. Edwards, K.: Session Management in Collaborative Applications. In: Proc. of CSCW'94, ACM Press, Chapel Hill, NC (USA). October 22-26 (1994) 323-330. Ellis, C. A., Gibbs, S. J., Rein, G. L.: Groupware: Some Issues and Experiences. Communications of the ACM, Vol. 34, No. 1. January (1991) 38-58. Erickson, T., Smith, D. N., Kellogg, W. A., Laff, M., Richards, J. T., Bradner, E.: Socially Translucent Systems: Social Proxies, Persistent Conversation, and the Design of “Babble”. In: Proc. CHI’99, ACM Press, Pittsburgh PA (USA) May 15-20 (1999) 72-79. Favela, J., Ruiz, D.: Collaborative Authoring and Reviewing over the Internet. WebNet Journal: Internet Technologies, Applications & Issues, Vol. 3, No. 3 (2001) 26-34. Fish, R. S., Kraut, R. E., Root, R. W., Rice, R. E.: Video as a Technology for Informal Communication. Communications of the ACM, Vol. 31, No. 1. January (1993) 48-61. Gaver, W., Moran, T., Maclean, A., Lövstrand, L., Dourish, P., Carter, K., Buxton, W.: Realizing a Video Environment: EuroPARC’s RAVE System. In: Proc. CHI’92, ACM Press, Monterrey CA (USA). May 3-7 (1992) 27-35. Greenberg, S. and Roseman, M.: Groupware Toolkits for Synchronous Work. In: Beaudouin-Lafon, M. (ed.): Computer-Supported Cooperative Work (Trends in Software 7), Chapter 6. John Wiley & Sons Ltd, ISBN 0471 96736 X. (1999) 135-168. Greenberg, S.: Peepholes: Low Cost Awareness of One's Community. In Companion Proc. CHI'96. ACM Press, Vancouver BC (CA) April 13-18 (1996) 206-207. Gutwin, C. and Greenberg, S.: Workspace Awareness. CHI'97: Workshop on Awareness in Collaborative Systems, organized by Susan E. McDaniel and Tom Brinck, Atlanta, Georgia, March 22-27 (1997). Gutwin, C., Greenberg, S.: A Descriptive Framework of Workspace Awareness for RealTime Groupware. Computer Supported Cooperative Work, The Journal of Collaborative Computing, Kluwer Academic Press (2001). Gutwin, C., Greenberg, S.: Supporting Awareness of Others in Groupware. In Companion Proc. CHI'96. ACM Press, Vancouver BC (CA) April 13-18 (1996) 205. Hindus, D., Ackerman, M. S., Mainwaring, S., Starr, B.: Thunderwire: A Field Study of an Audio-Only Media Space. In: Proc. CSCW'96, ACM Press, Boston MA (USA) November 16-20 (1996) 238-247. Isaacs, E. A., Tang, J. C., Morris, T.: Piazza: A Desktop Environment Supporting Impromptu and Planned Interactions. In: Proc. CSCW'96, ACM Press, Boston MA (USA) November 16-20 (1996) 315-324. Isaacs, E. A., Whittaker, S., Frohlich, D., O'Conaill, B.: Informal Communication Reexamined: New Functions for Video in Supporting Opportunistic Encounters. In: Finn, K.E., Sellen, A.J., and Wilbur, S.B. (eds.): Video-Mediated Communication. Lawrence Erlbaum, New Jersey NJ (1997) 459-485.

166

A.L. Morán et al.

29. Isaacs, E., Walendowski, A., Ranganthan, D.: Hubbub: A Sound-enhanced Mobile Instant Messenger that Supports Awareness and Opportunistic Interactions. In: Proc CHI 2002. ACM Press, Minneapolis MN (USA) April 20-25 (2002) 179-186. 30. Kraut, R. E., Streeter, L. A.: Coordination in Software Development. Communications of the ACM, Vol. 38, No. 3. March (1995) 69-81. 31. Kristoffersen, S., Ljungberg, F.: An Empirical Study of How People Establish Interaction: Implications for CSCW Session Management Models. In: Proc. CHI’99, ACM Press, Pittsburgh PA (USA) May 15-20 (1999). 32. Morán, A. L., Favela, J., Martínez, A. M., Decouchant, D.: Document Presence Notification Services for Collaborative Writing. In: Proc. CRIWG'2001, 7th Intl. Workshop. on Groupware, IEEE Computer Society, Darmstadt (Germany). September 6-8 (2001) 125-133. 33. Mynatt, E. D., Back, M., Want, R.: Designing Audio Aura. In: Proc. CHI’98, ACM Press, Los Angeles CA (USA) April 18-23 (1998) 566-573. 34. Nardi, B. A., Whittaker, S., Bradner, E.: Interaction and Outeraction: Instant Messaging in Action. In: Proc. CSCW 2000. ACM Press, Philadelphia PA (USA) December 2-6 (2000) 79-88. 35. Newman, R., Newman, J.: Social Writing: Premises and Practices in Computerized Contexts. In: Sharples, M. (ed.): Computer Supported Collaborative Writing. Springer Verlag, (1993) 29-40. 36. Palfreyman, K., Rodden, T.: A Protocol for User awareness on the World Wide Web. In: Proc. CSCW’96. ACM Press, Cambridge MA (USA) November 16-20 (1996) 130-139. 37. Patterson, J. F., Day, M., Kucan, J.: Notification Servers for Synchronous Groupware. In: Proc. CSCW’96. ACM Press, Cambridge MA (USA) November 16-20 (1996) 122-129. 38. Patterson, J. F., Hill, R. D., Rohall, S. L.: Rendezvous: An Architecture for Synchronous Multi-User Applications. In: Proc. CSCW’90. ACM Press, Los Angeles CA (USA) October 7-10 (1990) 317-328. 39. Pedersen, E. R., Sokoler, T.: AROMA: Abstract Representation of Presence Supporting Mutual Awareness. In: Proc. CHI’97, ACM Press, Atlanta GA (USA) March 22-27 (1997). 40. Rodden, T.: Populating the Application: A Model of Awareness for Cooperative Applications. In: Proc. CSCW'96, ACM Press, Boston MA (USA) November (1996) 8796. 41. Roseman, M., Greenberg, S.: TeamRooms: Network Places for Collaboration. In: Proc. CSCW'96, ACM Press, Boston MA (USA) November 16-20 (1996) 325-333. 42. Roucenfield, M., Hughes, J. A., Rodden, T., Viller, S.: Working with “Constant Interruption”: CSCW and the Small Office. In: Proc. CSCW’94. ACM Press, Chapel Hill NC (USA) October 22-26 (1994) 275-286. 43. Rouding, M., Greenberg, S.: Using the Notification Collage for Casual Interaction. In: ACM CSCW 2000: Workshop on Shared Environments to Support Face-to-Face Collaboration. Philadelphia PA (USA) (2000) http://www.edgelab.sfu.ca/CSCW/workshop_papers.html. 44. Segerstad, Y. H., Ljungstrand, P.: Instant messaging with WebWho. International Journal of Human-Computer Studies, Vol. 56, No. 1, January (2002) 147-171. 45. Tang, J. C., Isaacs, E. A., Rua, M.: Supporting Distributed Groups with a Montage of Lightweight Interactions. In: Proc. of CSCW'94, ACM Press, Chapel Hill NC (USA) October 22-26 (1994) 23-34. 46. Tang, J. C., Yankelovich, N., Begole, J., Van Keek, M., Li, F., Bhalodia, J.: ConNexus to Awarenex: Extending Awareness to Mobile Users. In: Proc. CHI 2001. ACM Press, Seattle WA (USA) March 31-April 4 (2001) 121-128. 47. Vertegaal, R., Velichkovsky, B., Van Der Veer, G.: Catching the Eye: Management of Joint Attention in Cooperative Work. SIGCHI Bulletin, vol. 29, num. 4, October (1997).

Before Getting There: Potential and Actual Collaboration

167

48. Whittaker, S., Frohlich, D., Daly-Jones, O.: Informal Workplace Communication: What is it like and How Might We Support it. In: Proc. CHI’94. ACM Press, Boston MA (USA) April 24-28 (1994) 131-137. 49. Whittaker, S., Jones, Q., Terveen, L.: Managing Long Term Communications: Conversation and Contact Management. In: Proc. of HICSS 2002, Hawaii (USA) January 7-10 (2002). 50. Whittaker, S., Swanson, J., Kucan, J., Sidner, C.: TeleNotes: Managing Lightweight Interactions in the Desktop. In: ACM Transactions on Computer Human Interaction, Vol. 4, No. 2, June (1997) 137–168. 51. Whittaker, S.: Rethinking Video as a Technology for Interpersonal Communication: Theory and Design Implications. International Journal of Man Machine Studies. Vol. 42 (1995) 501-529.

Intelligent Awareness in Support of Collaborative Virtual Work Groups Rosa Alarcón and David Fuller Pontifical Catholic University of Chile, Computer Science Department, Vicuña Mackenna 4860, 6904411, Santiago, Chile {ralarcon, dfuller}@ing.puc.cl

Abstract. Collaborative Virtual Work Groups (CVWG) are small groups of people that perform tasks, share responsibilities, goals and decisions but are distanced in terms of space, time and cultures, and maintain their connections through technology. Collaborative Systems support them enabling a shared environment and informing of its state and changes through a mechanism called Awareness. In this paper we argue that these changes and their consequences can be understood in an ontological work context (we call it “semantic awareness”). This approach allows us to infer the relevance of the awareness information and control its delivery. To do so, we determine a user context (location, device, preferences), which allows us to infer the user willingness to be exposed to this information. The mechanism is enabled through a Multi-Agent System (MAS), where an agency represents each user’s perception and actual context. We also present a case study and discuss the obtained results.

1 Introduction Current computer network improvement and the possibility of remaining networked, has encouraged the organizations to assign tasks to Collaborative Virtual Work Groups (CVWG). They are small groups of people that perform specific tasks, share decisions, goals and responsibilities, but are distanced in terms of space, time and cultures, and maintain their connections through communication technologies [1], [2]. The main advantage of these groups resides in their flexibility, fast conformation, reorganization and breakup, besides the use of work expertise without incurring in reallocation costs. They need to react rapidly to changes in their environment and face the uncertainty and distrust imposed by their fragmented environment [3], [4], so they must overcome their infrastructure and time differences in order to coordinate actions, maintain formal and spontaneous interactions and keep informed of the project’s daily activities [5], [6]. Collaborative systems allow them to share software artifacts, objects and selfrepresentations enabling a virtual shared environment. The state of this environment

J.M. Haake and J.A. Pino (Eds.): CRIWG 2002, LNCS 2440, pp. 168–188, 2002. © Springer-Verlag Berlin Heidelberg 2002

Intelligent Awareness in Support of Collaborative Virtual Work Groups

169

and its changes are rendered to the user through a mechanism called Awareness, that due to the nature of CVWG, needs to be highly proactive (called passive awareness). The actual approach consists of manifesting the user’s interest in being notified automatically of changes in predetermined objects in the environment [7], [8]. But, when the environment is dynamically constructed, those objects are created on the fly, so the notification can even be nonexistent. Also, if there is a temporal distance between the team members, it can fail to reach the user in the appropriate time or can overload him or her if the number of events is too high. In this paper we propose a semantic approach, in the sense that every object in the shared environment correspond to a work context ontology1, so that when an action attempts to change the object’s state, we infer the relevance of the resulting event and its consequences from this ontological context. In addition, we define a user context that comprises a series of electronic places (logical and physical devices) or contact points as well as a preferences profile. 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 the event. The awareness mechanism is conceptualized 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 [9], [10], [11]. A MAS system can be seen as a collection of possibly heterogeneous agents. The proposed MAS constitutes an awareness server composed of heterogeneous agents, organized as agencies responsible for delivering user awareness information (one agency per user). Every agency comprises a pair of intelligent agents. One of them is responsible for estimating the relevance of events perceived in the shared environment, according to the proposed work context ontology. The other one is responsible for scheduling the information delivery according to the designed user context. Each agent’s knowledge is maintained in its own separate knowledge base, so they keep a partial view of the shared environment. Each agent within the agency behaves cooperatively as their actions complement each other. Agents’ communicative interaction follows the conventions described by FIPA2 ACL (Agent Communication Language) standard. FIPA ACL describes a language in which communicative acts can be expressed; those acts are based on Searle’s speech act theory [12] grounded in a logical framework. Agents interchange logical propositions, actions and objects referencing elements of work and user ontologies.

1

2

An ontology is an explicit formal specification of the terms in the domain and the relations among them [13]. FIPA (Foundation for Intelligent Physical Agents) is a non-profit organization aimed at producing standards for the interoperation of heterogeneous software agents. See http://www.fipa.org/ for further details.

170

R. Alarcón and D. Fuller

Our aim is to build ubiquitous collaborative applications, in the sense that the awareness mechanism can encounter the user, rendering the shared environment to him or her proactively. Based on the proposed MAS we implemented an awareness server (AwServer) and developed a case study application: a collaborative web Scheduler (CScheduler). The ontologies and their main inference criteria are presented in section 2. In section 3, we present the proposed MAS architecture. The MAS implementation and the case study are presented in section 4. Finally, in section 5 we discuss the results.

2 Semantic Awareness Dourish and Belloti [14] define awareness as “an understanding of the activities of others, which provides a context for your own activity”. As pointed out by [15]: “awareness is a state of mind of a user .... that it involves the activities of others and that it provides a backdrop (‘context’) for own activities ... while awareness mechanisms are techniques employed by a system to achieve this state of mind” Despite there is not a precise definition, we can imply that the objective of the awareness mechanism is to support the maintenance of a shared context by the group members, so they can understand how his or her actions fit into the team’s overall goals in order to coordinate their actions [16]. But we can distinguish, at least, two kind of context related to the awareness mechanism: a work context in which the group members’ actions are interpreted and is to some extent common to group members; and a user context that involves the actual state of the user when he or she perceives the awareness information (that is, interacts with the awareness mechanism). Passive awareness is a strategy to build awareness mechanisms, whose objective is to maintain the user informed of events without requiring him or her to make a conscious effort to do so (i.e. sending notifications through a messaging system, a mail system or something alike) [14], [17]. Due to the physical and temporal distance, the interactions that occur within a CVWG are mainly asynchronous. In this scenario, passive awareness is best suited to keep the team up-to-date to the shared environment’s actual state. The drawback of this approach is that it requires the user to explicit his or her interest in a predetermined object (subscription), a task that the users are not always willing to perform [18]. If a designer predetermines those objects, the mechanism could be too rigid or unable to adapt to the team development. A naive approach consists of observing every object in the shared environment, notifying any change occurred. The evident inconvenience is an information overload that neither guarantees the awareness information reception (the user can be out of reach) nor its coherent perception (if the mechanism employs different channels). Additionally, the user context is neither static nor homogeneous. So that shared environment’s unexpected situations of use (i.e. delays in document reading due to

Intelligent Awareness in Support of Collaborative Virtual Work Groups

171

time or technological infrastructure differences) are potential sources of misunderstandings, information loss and casual interaction opportunities lost [19]. The underlying problem consists of determining the relevance of events occurred in the shared environment, and recognizing the context in where they are perceived. We face the problem by defining a work context ontology and a user context. Work ontology allows us to interpret the events and to define a set of rules in order to derive their relevance and consequences. User context allows us to schedule the delivering of awareness information, concerning the events taken place, in terms of user’s electronic location and time where the user is willing to perceive the information. To infer the user willingness we consider the relevance of the information, the user’s preferences and the interaction capabilities of his or her actual electronic location. The next sections present the ontological contexts in detail.

2.1 Work Context Ontology. The Workflow community characterizes work context through an explicit model of business processes. This model comprises tasks, schedules, actors, software tools and information sources and allows to determine the current activities, as well as activities’ state, history and related events [20], [21], [22], [23]. This approach has a main drawback because it requires a detailed and anticipated model of the underlying process that is impossible to obtain from CVGW teams, because they conform a heterogeneous environment and do not follow strictly a standard procedure but act according to their needs and team evolution [24]. Although their contexts are built dynamically, their main components remain the same. According to Haake [25], these components define 3 categories: Content (software tools and shared objects), Processes (activities and their schedules) and People (people and teams). So that, work context would emerge from the dynamic articulation of these components, that is, the dynamic creation of relationships between them. Those relationships define the semantics associated with work practice: roles, authority and responsibility, available resources, task precedence, etc. [26], [27], [28]. That is, the components and their relationships define a work ontology (Fig. 1). Fig. 1 presents the ontology components and their relationships. We also present there the generic operations Add, Update and Delete, and an additional operation called RegisterLocalVocabulary. This last one represents the operation of extending the ontology vocabulary in order to specialize it according to a specific collaborative application. For example, in the study application (CScheduler), defining a specific activity like fix_appointment requires defining the domain specific concepts “appointment”, “Free”, “answer” (appointment confirmation), etc., in order to define activity preconditions and effects or goals (i.e. “Free (me, invitee)”). This is important because a precondition fail must be of interest of the Activity responsible (the team as a whole or a Boss) as well as an Activity goal achieved. Those are considered logical consequences of an Activity element (fix_appointment) addition.

172

R. Alarcón and D. Fuller

Fig. 1. Content or SoftwareArtifacts component comprises a set of Applications and a generic Repository of shared objects; Process component consists of a ProjectPlan composed of Activities and Subactivities. Person component is implemented via an Organization that includes Teams assigned to accomplish an Activity and Person instances as Team members. The generic operations are also presented (AddElement, UpdElement and DelElement)

Relevance. Events taken place in the shared environment are seen as the result of performing any of the generic operations (Add, Delete, Update) over some ontology component instance. The semantics associated with each operation depends on the component itself (a Delete operation performed over a Person involves a notification sent to the Person itself, but also to the user that makes the call, to the team where the Person belongs, to his or her Boss, etc.). Those operations are seen as transformation operations [29], executed explicitly or as a logical consequence (implicit) derived from the semantic relationships of the ontology elements. In relation to human awareness, artifacts have associated transformation operations that are performed when the artifact is used. If an artifact works well (success), it allows us to focus our attention on the main activity objective, thus the artifact is transparent to us (its salience is low) until it fails (failure), then it renders itself to us gaining our attention (its salience is high) [29], [30]. According to this theory, we determined some salience or relevance rules considering the result (success or failure) of performing any of the envisioned generic operations over some instance of an ontology element (Table 1). We take into account the event originator, which is the user that originates the operation (me or a partner); because the transformed artifact exists in the shared environment from which the operation is requested, but also, in each partner’s environment. For example, if a user calls an operation, which is executed successfully, the event’s salience is low. That is to say, the shared environment worked well for the user, it fulfilled his or her expectations. But the salience of the event is higher for his or her partners, because for them the event is unexpected.

Intelligent Awareness in Support of Collaborative Virtual Work Groups

173

Table 1. Relevance criteria of events generated when a transforming operation is executed considering its result and the perspective from which it is perceived: the event relevance to me (if I request the operation) and the relevance that it has to my partners (if I request the operation). The scale from minor relevance to a higher one is: none, low, medium, high, sure

Operation AddElement UpdElement DelElement

Result Success Failure Success Failure Success Failure

Relevance to me Low High Medium High Low Medium

Relevance to a partner Medium None High Low Sure None

2.2 User Context E_Place. User context is currently a hot topic of research in the area of context-aware computing [31], [32]. In this community, user context is described in terms of the user’s current location taking into account the social - at home, at office, etc. – (Office Assistant [33], GeoNotes [34]), physical - light, noise, etc. – (Tangible Bits [35]) and informational - guided tours, tourist maps, etc – (CoolTown [36], Tourist Guide [37]) characteristics of the user’s current physical environment. In relation to user location, our focus is on defining electronic places (e_Places), which, resembling abstract contact points, describes the user’s location in terms of its interaction capabilities and allow us to reach or contact the user. Those represent the collection of physical and logical devices available to the user, considered as a whole the awareness mechanism interface [38], [39] (i.e. an e-mail via cellular phone, a collaborative application running in a desktop computer, a private messaging system, a WAP system, an SMS system, a beeper, etc.). Fig. 2.A presents some properties that characterizes the class (or concept) e_Place. The features describe the electronic place in terms of content, location and interaction capabilities. Each e_Place is related to an electronic address (e_Address). Fig. 2 presents three examples: an email address (eMailAddress), an URL (URLAddress) and a network address described in terms of socket’s host and port (SocketAddress). These types are arbitrary and could easily be replaced by an URI (Uniform Resource Locator). For example, the collabAppPlace represents a socket where the collaborative application could listen the awareness mechanism in order to allow the collaborative application’s developer to integrate the awareness information in the application interface. The WebPlace represents a Web based collaborative application (a Web site). The cellular_MailPlace and cellular_SMSPlace are associated with web services delivery so they have URLAddresses. An e_Place’s content includes its format (string or byte), length and content body (the content itself). An e_Place’s location comprises the device where it resides (a desktop computer, a cellular, a PDA, etc.), its e_Address, in order to be contacted; and a method that implements de content delivery through the e_Place.

174

R. Alarcón and D. Fuller

Fig. 2. An e_Place (A) is an electronic place that resides in a physical device (a desktop computer, a cellular, a PDA, etc.), has an electronic address (e_address) and a content delivery method. Additionally an e_Place is described in terms of its interaction capabilities, those are: portability, degree of synchrony provided and delivery methods (pull, push or both). We present some e_Places as examples (B), these are: eMailPlace, WebPlace, collabAppPlace, privMessagingPlace, cellular_MailPlace and cellular_SMSPlace

The e_Place’s interaction capabilities correspond to the interaction modes that an e_Place affords, and is described by its portability, its delivery method (push, pull or both) and its degree of synchrony. The degree of synchrony is an index that establishes a measure of potential synchrony that could be achieved when an interaction between the awareness mechanism and a user through that e_Place occurs. That is, the greater the index, the shorter the delay between communicative actions.

Fig. 3. Examples of E_Places ordered by their synchrony index. E_Places resides in a portable device or in a fixed one. The example devices are a desktop computer and a cellular phone

Fig. 3 presents an e_Places’ example ordered according to their synchrony capability. A negative index represents an asynchronous characteristic and a positive index a synchronous one. E_Places residing in portable devices are considered to have a

Intelligent Awareness in Support of Collaborative Virtual Work Groups

175

higher synchrony capability than those residing in fixed devices. The presented e_Places resides in a desktop computer and a cellular phone as the figure shows, although the user could have more than one fixed device or portable device at a time. Fig. 2.B presents some e_Places as examples. The e_Places in order of synchrony capability are: eMailPlace, WebPlace, collabAppPlace, privMessagingPlace, cellular_MailPlace and cellular_SMSPlace. Perceptual schedule. E_Places approach, allows us to build ubiquitous collaborative applications, in the sense that the awareness mechanism can encounter the user in some of those e_Places rendering the shared environment to he or she proactively. The e_Place’s inherent interaction capabilities (synchrony) allow us to prescribe an appropriate time and interaction mode to deliver the awareness information taking into account the relevance of that information in the work context. We do so via a schedule that relates the information with an appropriate e_Place (location selection) and an appropriate time (time selection) where the information will be perceived (it could be delayed). Location selection. The appropriate e_Place is inferred considering the relevance of the information in the work context, but also, the e_Place from where the user requested the operation (event source) and his or her current e_Place. The event’s relevance indicates the degree of required synchrony (i.e. associating “urgent” events with e_Places with higher synchrony index). The event source and the current e_Place describe the coupling level of the interaction (coupled or uncoupled) [24]. That is, if event source and current user location correspond to the same e_Place, then the ongoing interaction is likely to be a coupled one. The selection criterion, in this case, is to direct the awareness information to the event source (Table 2). Table 2. E_Place selection criterion for delivering the awareness information assuming that the user has the following e_Places options: “eMail”, “Web”, “collabApp”, “privMessaging”, “cellular_Mail” and “cellular_SMS”, in increasing disturbance degree order. The criterion takes into account the coupling level of the interaction, the current user location (one of his or her e_Places), the disturbance associated with the e_Place, and the work relevance (Table 1) to choose an e_Place

Relevance low medium high sure low medium high sure

Coupling coupled coupled coupled coupled uncoupled uncoupled uncoupled uncoupled

Required interaction synchronous synchronous synchronous synchronous asynchronous asynchronous synchronous asynchronous

Current Location collabAppPlace collabAppPlace collabAppPlace collabAppPlace WebPlace Cellular Cellular Cellular

Delivery collabAppPlace collabAppPlace collabAppPlace privMessagingPlace eMailPlace eMailPlace cellular_MailPlace cellular_SMSPlace

176

R. Alarcón and D. Fuller

An exception is considered for the case related to events with the highest relevance level (sure). In this case, the criterion is to consider the next e_Place in the synchrony order that resides in the same device, in order to favor coupling interactions (privMessagingPlace in the example). When the current interaction is uncoupled, the criterion is to direct the awareness information to an asynchronous e_Place. Obviously, selected e_Places must have the capability of supporting push technology. WebPlace is the first asynchronous e_Place, but as is a regular Web site, lacks the push capability. For this reason, it is not eligible and the selected e_Place must be the eMailPlace. The exceptions are those events with higher relevance (high and sure). In these cases, the criterion is to favor synchronous interaction (because they are urgent) so the selected e_Places have the higher synchrony index (cellular_MailPlace and cellular_SMSPlace respectively). For example, when the user is outside the collaborative application, the e_Place is chosen according to the event relevance (uncoupled interaction), but when he or she is in the application, the mechanism will prefer the e_Place associated with the collaborative application allowing coupled interactions. When events are the result of inference processes (implicit operations) we assume that the event source is the current user location, in order to favor coupling interaction. Time selection. On the other hand, the delivery schedule of awareness information must take into account the appropriate time where the information will be perceived. For synchronous interaction, the chosen time is the closest to the actual (now), while for asynchronous interaction, the time is chosen according to user preferences. User preferences have been studied in the area of interface agents, indicating that they can be established from the semantics that user actions have in a specific application [9], [10], [39].

Fig. 4. The WEventNotification is scheduled (NotificationSchedule), and render through an e_Place, considering its origin, the user currentLocation, his or her Availability patterns, PerceptualHistory (coherence) and UserReaction. The e_Place modeling is also presented

Intelligent Awareness in Support of Collaborative Virtual Work Groups

177

The user preferences are recorded in an availability profile based on relevance and time intervals (i.e. “Available (high, 8, 21)”). When an asynchronous interaction is required, notifications are scheduled to the closest available time for the notification’s relevance (i.e. 8am if currently is 7 am). Work events are scheduled for being perceived through e_Places according to availability preferences (Fig.4). An acknowledgement must be sent indicating that the notifications have reached the user. Otherwise, the notification will increase its urgency level and another e_Place with a higher degree of disruption will be chosen. When more than one event are scheduled to an e_Place, their precedence order is determined by their arrival order. As the user acknowledges the notification receipt, the event becomes part of the Perceptual History log, and the User Reaction is recorded in order to correct or reinforce agents’ assumptions.

3 Architecture An agent can be seen as a software process that controls its actions (autonomy), perceives its environment (react) and can take the initiative to perform a behavior (proactive) in order to accomplish tasks on behalf of its user. A MAS can roughly be considered as a system composed of multiple and possibly heterogeneous agents. MAS’ control can be distributed, so the agents that compose it must communicate among them (social abilities) in order to cooperate and accomplish their goals [9], [10], [11]. Finally, agents require an execution environment that put at their reach, the necessary sensorial information to perceive their environment (sensor) and act upon it (effector). In this section we describe the architecture of the proposed awareness mechanism. Environment. Both work and user context ontologies represent the knowledge of two types of agents, a work and a user context agent, WCA and UCA respectively (See grayed boxes in Fig. 5). A pair of these agents works in a cooperative fashion, conforming an Agency, which is associated to a single user. The agency is responsible for rendering the awareness information to the user according to the relevance of the information (inferred for WCA) and the user’s current location and preferences (inferred for UCA). A third agent, called Proxy Agent (PA) has the responsibility to put at the reach of every agency the capability of perceiving the shared environment events (sensor) and act upon it (effector). The collection of agencies conform an Awareness Server (Fig. 5). In Fig. 5, we present the interactions between the main components of the proposed architecture. WCA and UCA agents are represented by small heads labeled WCA and UCA respectively, which has above a gray box representing each agent’s knowledge. WCA’s knowledge is structured according the work context proposed in this paper (Fig. 1); which comprises the general work ontology (labeled as “project knowledge”)

178

R. Alarcón and D. Fuller

as well as a particular instance (labeled “domain specific knowledge”) related to a specific collaborative application (the CScheduler in this case). UCA’s knowledge is structured according to the user context proposed which is detailed in Fig. 4. In both cases we remark the kind of inference rules that apply; for WCA relevance rules are concerned as well as inference rules related to the collaborative application’s specific domain. For UCA, the inference rules are related to the determination of the user availability, user location and notification (preferred e_Place and time).

Fig. 5. Every user has an associated agency comprising a WCA agent (Work Context Agent), that infers the relevance of events occurred in the shared environment, and a UCA agent (User Context Agent), that determines the e_Place and time where the notification will be delivered. Events are propagated (perceived) to the agency through messages received by a PA agent (Proxy Agent) that broadcasts them to the entire agents’ society

When an event occurs in the shared environment, it is propagated to the Agency through the PA agent (an ACL message is sent to the PA agent). If the event is related to work ontology (work context operation), PA broadcasts the message to every WCA agent. If the event is related to user ontology (user context operation), then PA sends the message to the UCA agent that conforms the user’s Agency (unicast). The communication between WCA and UCA (work event) occurs inside the Agency (unicast). User’s responses to Agency notifications are also directed to the respective agent (unicast). The awareness server can be centralized, containing all the agencies that represent each user. It can also be distributed in local servers containing the user agency, as every agent acts based on its own knowledge base (a partial view of the situation). In both cases, a single PA agent or a collection of them can be instanced, but only one agency must be assigned to every user.

Intelligent Awareness in Support of Collaborative Virtual Work Groups

179

Coordination. Agent coordination within an agency is implicit in the sense that each WCA and UCA agents’ behavior is designed to complement each other, so they do not need to engage in negotiations in order to fulfill their responsibilities. Coordination is achieved through message interchange, at knowledge level. Agents’ communicative interactions follow social conventions (protocols) defined by the FIPA ACL language, which is based on Searle’s speech act theory [12] grounded in a logical framework. Communication occurs as an attempt of informing the agent’s beliefs, desires or intentions (BDI) state or as an attempt to alter the agent’s interlocutors’ BDI state. Messages expressed in FIPA ACL are associated with a communicative act that is described in terms of a performative (that is the communicative act type), a specific content and an ontology that is used to interpret the message content. Messages have precise associated semantics: the content could be logical propositions, actions or rules referencing elements of work and user ontologies. Behavior. Communication is directed, and is established between PA and WCA agents (work context operation), PA and UCA agents (user context operation), UCA and PA agents (awareness notification) and WCA and UCA agents (work event) (see Fig. 5 and Fig. 7). In the first and second cases, the PA agent acts in its role of agency’s sensor. That is, PA observes the shared environment and propagates the transformation operations occurred to the agency, by requesting WCA and UCA to perform them over the instance ontology elements of their respective knowledge bases. In the third case, PA acts in its role of agency’s effector. That is, PA is requested by UCA to effectively notify the user of an occurred event. Finally, in the fourth case, WCA informs to the UCA agent that the former has inferred the occurrence of an event in the shared environment as a direct or indirect consequence (inferred) of a transformation operation execution. So the types of involved communicative acts are directive (requesting an action) and assertive (informing a mental state). Finally, agents must politely acknowledge their requests for action or information consequences. When an action cannot be accomplished, its failure and possible causes must be informed to the requester. If an agent does not understand a message due to ontology ignorance, it must be informed to the requester. Knowledge representation. Agents’ knowledge related to the devised ontologies is maintained in a separate knowledge base (KB). That is a KB for WCA and another for UCA agent. Facts are asserted in each KB when a transforming operation is requested trough PA or as a result of each agent’s inference processes. Agents’ inference process (relevance and perceptual scheduling) corresponds to a rule-based system, where an inference engine is associated to the agent and its respective KB.

180

R. Alarcón and D. Fuller

Facts related to the result of performing some transforming operation (events) by the agent (WCA or UCA) are asserted into the knowledge base. The defined rules derive the consequences of asserting facts (forward chaining). Agents record or remind their inferences in order to keep the user informed of them. Agents react to their inferences initiating a behavior that has as scope the agency (informing their mental) or the awareness mechanism (state or requesting).

4 Implementation We built an implementation of the proposed MAS system (AwServer) and a collaborative study application (CScheduler). In this section we introduce them. Both work and user ontology, were developed, as well as a LocalVocabulary that specializes the work ontology according to the semantics of CScheduler. We also built the WCA, UCA and PA agents, their behavior and reasoning mechanism. 4.1 AwServer Tools. AwServer was built over JADE3, a Java based agent development environment that conforms to FIPA standards, so it provides the services defined by FIPA architecture (see [40] for further detail) as well as some tools to develop agents. Fig. 6 presents one of these tools, the sniffer agent, that shows the messages interchanged between agents (right area). JADE provides the agents’ execution platform called an agents’ container, which is a JVM (Java Virtual Machine) running in a host computer. Agents developed over JADE are multitasking processes where tasks (or behaviors) are executed concurrently. Message communication is asynchronous and supports some of the FIPA ACL protocols. JADE also support ontology management and mobility. As FIPA ACL is an abstract content language, it requires an instance language. We chose FIPA SL (semantic language) instance, which defines a syntax message and the REQUEST and INFORM performatives, all supported by JADE. As the reasoning mechanism we used the Java based inference engine JESS4. JESS is an expert system that repeatedly applies a set of rules to a collection of facts and can interoperate with Java applications. In order to fulfill their responsibilities, WCA, UCA and PA agents perform a series of behaviors defined in section 3. Below we present the agents’ behavior implementation as well as an outline (Fig. 7).

3 4

Java Agent DEvelopment Framework. See http://sharon.cselt.it/projects/jade/. Java Expert System Shell. See http://herzberg.ca.sandia.gov/jess/

Intelligent Awareness in Support of Collaborative Virtual Work Groups

181

Fig. 6. Screenshot from JADE’s sniffer agent showing the messages interchanged between the PA agent and the agencies of three users: Juan (wjuan and ujuan agents), Pablo (wpablo and upablo agents) and Maria (wmaria and umaria) when attempting to fix an appointment of CScheduler. Top boxes, in the right side represent agents, arrows represent the messages interchanged and are labeled with the message’s performative

Fig. 7. PA agent acts in its role of sensor (API behavior) and effector (Notification behavior). WCA behavior includes performing transformation operations (GenericOperationExecution) registering the LocalVocabulary (RegisterLocalVocabulary), executing an Activity (ExecutionActivity) and informing UCA of an occurred event (EventAlert behavior). UCA actions also include performing transformation operations, as well as keeping the current user location updated (SetUserLocation) and requesting the PA’s effector behavior (EventNotification). Both WCA and UCA, also reminds the inferred events or notifications

182

R. Alarcón and D. Fuller

PA behavior implementation. PA agent propagates the changes in the shared environment through an API based on FIPA ACL syntax messages (API behavior). As agents run in a JVM, that is the entire agents’ container is executed as a Java application, the API is implemented as a socket server. PA receives the messages sent from the collaborative application and determines the appropriate receiver agent type (WCA or UCA agent type). Then PA broadcasts the message to every other agency in the society. The message also includes the user who makes the request (actor) and the e_Place from where is requested. Since the generic operations were developed as part of the ontologies, PA has the capability of “speaking” in both ontologies. API messages performative correspond to FIPA REQUEST. PA is also responsible for delivering the notification message (Notification behavior), that is to say, it executes the delivery method (Fig. 2) defined for the e_Place determined for UCA (i.e. open network connections, sending mail, etc.). Finally, as the notifications must be acknowledged, the PA implements a Waiting behavior, which is an execution suspension until a responding message arrives. This is possible because ACL message has a conversation id field, which is used to reply and build a conversation thread. WCA behavior implementation. WCA agent receives PA’s operation requests and reacts to them initiating a GenericOperationExecution behavior. That is, the agent performs the operation (AddElement, UpdElement or DelELement an element requested) and asserts the resulting action (success/failure) in its own knowledge base. As the shared environment constitutes a domain specific application and is built dynamically, it requires a particular vocabulary and a project instance (i.e. what kind of activities?, what kind of e_Places?). For this reason, the API also implements a RegisterLocalVocabulary behavior. Also, WCA supports the execution of ontological Activities defined in the LocalVocabulary by describing the activities in terms of logical preconditions and consequences (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. JESS is a reasoning engine that runs repeatedly trying to apply the rule set every time that a new fact is asserted. When a rule applies or fires, JESS notifies the event to WCA. The agent records the event (RemindEvent behavior) and sends a message to UCA informing that a new work event has occurred (WEventNotification, see Fig. 4). UCA behavior implementation. UCA agent also receives PA’s operation requests and reacts to them initiating its own GenericOperationExecution behavior. That is, UCA performs the requested operation and asserting the resulting action in its own knowledge base. As the user moves through different e_Places (logging in and out or interacting through them), UCA performs a location updating behavior (SetUserLocation behavior). That is, updates the user current e_Place.

Intelligent Awareness in Support of Collaborative Virtual Work Groups

183

In a similar fashion to WCA, the JESS engine associated with UCA fires rules requesting to perform a notification. UCA records the notification to be executed (RemindNotification behavior) and sends a message to PA requesting it to deliver a notification (EventNotification behavior). Reasoning. As described, both agents implement their reasoning capabilities through JESS. The rules based on criteria depicted on Tables 1 and 2 are defined in the engine when agents are created. Facts are defined by templates or constructs, and rules are applied based on pattern matching techniques. That is, we defined a series of patterns formed by facts occurrence. For example, if there is an event resulting from an AddElement operation, and the event result is success and I am the operation caller, then the event relevance is low. When a pattern is matched, then the rules are applied or fired. 4.2 CScheduler The study application is a collaborative scheduler, CScheduler, whose main objective is to allow their users to fix appointments between two or more of them. In order to accomplish this objective, we developed two versions of the scheduler, and associated each of them to two different e_Places for coupled interactions. For asynchronous interactions, five e_Places were built. On the other hand, work ontology was instanced through a LocalVocabulary (domain specific knowledge) which implements basic concepts, predicates and functionality related to the scheduler. In this section we describe the e_Places, the work context instantiation and the linkage between AwServer and CScheduler. E_Places. We developed two versions of this application, a Java based and a Web based version (Java servlets) and we associated them to two different SocketPlaces. Both of them have associated a SocketAddress (Fig. 2.A) where they can be contacted. So that, when the user is in the shared environment, his or her actions are recognized as a coupled interaction and the awareness information is derived to these channels (Fig. 8.A, 8.B, 8.D). The other five e_Places were dedicated to enable asynchronous interactions, those are: an eMailPlace (Fig. 8.C), an additional SocketPlace used as a private desktop messaging (Fig. 8.E) and three URLPlaces associated with Web services for message delivery (SMS, cellular mail and ICQ). For each e_Place, we also implemented the methods associated with the content delivery (Java Mail, Java URL and Java socket invocation).

184

R. Alarcón and D. Fuller

Domain specific knowledge. As well as user ontology needs to be instantiated through the specification and construction (content delivery methods) of e_Places, work ontology needs to be instantiated through the specification of concepts, predicates and functionality (activities) related to a particular domain, CScheduler in this case. Work ontology was instanced through a LocalVocabulary, a class that contains the definitions of basic concepts (“appointment”, “answer”, etc.) and predicates (“Free”, “Busy”) related to the scheduler domain (Fig. 1.). A special remark needs to be done in relation to activity definition (i.e. “fix_appointment”). As we argue in section 2.1 an activity definition involves the definition of its preconditions (“Free (me, invitee)”) and effects or goals (“Busy (me, invitee)”), as well as a start and duration time. So that, if an activity doesn’t fulfill its preconditions when startup and hence fails to start, the consequences will be notified automatically to the responsible, in our case the user who “creates” the “fix_appointment” activity (the inviter). Nevertheless the activities are characterized in a particular domain, its conceptual definition allow us to infer logical consequences.

Fig. 8. Screenshots from CScheduler. A) The Java based application version, B) The Web based version, C) A notification received through the user eMailPlace, D) The notification through the SocketPlace associated with B) and E) The notification through the Monitor (an independent SocketPlace)

Awareness mechanism. Once the ontologies were instanced, we launched an agency for each user (“juan”, “pablo” and “maria”). Actions taken place in the applications (Fig. 8.A, 8.B, 8D, 8E) are propagated to the PA agent by sending ACL messages referred to the ontologies and the generic operations (Add, Delete, Update). For example, we request to add a “fix_appointment” activity in order to fix an appointment. As a result, the agency schedules the activity to start “now”, then WCA validates the predicates representing preconditions (i.e. “Free (me, time_interval)” AND “Free (invitee, time_interval)”), if preconditions are satisfied, it executes the

Intelligent Awareness in Support of Collaborative Virtual Work Groups

185

activities’ ExecutionBody method and verifies if the effects or goals are achieved (i.e. “Busy (me, time_interval)” AND “Busy (invitee, time_interval)”). As the relationships among an activity, its preconditions, effects and execution (validation, execution and verification) are defined at an abstract level (work ontology), the JESS engine fires logical consequences, rate its urgency and determine the e_Place whereto send the event notification. Fig.8 presents notifications received when attempting to fix an appointment, through the Monitor (E), an e-mail (C) and the SocketPlace associated with the Web version (an Http response). Fig. 6 presents the exchanged messages in the background between the three agencies representing users “juan”, “pablo” and “maria” and the PA agent when attempting to fix an appointment.

5 Discussion and Future Work The devised architecture enabled us to build a collaborative application with a proactive awareness behavior, where the environment can reach the user, taking into account his or her preferences as well as the relevance of the event in the work context. We believe that the approach would permit the collaborative application developer to implement complex policies from the relevance and availability criteria, as well as permitting the user to tune those criteria according to his or her actual preferences (they change in time). However, the chosen knowledge representation does not allow us to define stronger restrictions to the relationships between ontology elements (i.e. transitive relationships, numeric quantifiers, etc.), so the logical expressions are not complex enough to allow a latter dynamic context construction. In addition, the approach demands a large effort from the user to explicit his or her availability preferences and is not able to adapt to changes in work and user context; that is the rules are not inferred or learned. Finally, the user context’s elements User Reaction and Perceptual History are not currently implemented. These elements are very important because they will allow the agency to adapt to user preferences dynamically. In order to accomplish these objectives, our next step consists of employ OIL (Ontology Inference Layer) [41] for a richer ontology representation, as well as to experiment with FACT (Fast Classification of Terminologies) [42] for deriving rules. FACT is a server that provides inference services based on concepts (ontology elements) classification. Concepts must be expressed in OIL, which is based on description logics (DL). DL allows the expression of logical propositions in modal and temporal logics. Based on those changes we plan to include machine-learning techniques to infer relationships between work context elements, and to recognize availability preferences in order to allow the agency to adapt to the teams’ changes. Finally we plan to include another agent to the agency in order to create an agencyuser interface. This will allow the user and the developer to perform queries and tune

186

R. Alarcón and D. Fuller

the criteria, and the agency to explain its reasoning, but also to receive negative feedback from the user in order to adjust the agency’s inference processes.

References 1. Palmer, J., Speier, C.: Teams: Virtualness and media choice. In: International Journal of Electronic Commerce. 3, 1, (1998) 27-48. 2. Lipnack, J., Stamps, J.: Virtual teams: Reaching across space, time, and organizations with technology. John Wiley and Sons, Inc. New York, (eds) (1997). 3. Jarvenpaa, S., Leidner, D.: Communication and Trust in Global Virtual Teams. In: Journal of Computer-Mediated Communication, Vol.3 (4) (1998). 4. Steinfield, C., Jang, C.: Supporting Virtual Team Collaboration: The TeamSCOPE System. In: Proc. of GROUP’99. Int. ACM SIGGROUP Conf. on Supporting Group Work (1999). 5. Galegher, J., Kraut, R.: Computer-mediated communication for intellectual teamwork: A field experiment in group writing. In: Proceedings of CSCW’90 (1990) 65-78. 6. Kraut, R., Galegher, J., Egido, C.: Relationships and Tasks in Scientific Research Collaboration. Human Computer Interaction. 3 (1) (1988) 31-58. 7. Leland, M., Fish, R., Kraut, R.: Collaborative Document Production Using Quilt. In Proceedings of CSCW 88, (1988) 206-215. 8. Appelt, W.: WWW Based Collaboration with the BSCW System. In Proceedings of SOFSEM’99, Springer Lecture Notes in Computer Science 1725, (1999) 66-78. 9. Maes, P.: Agents that reduce work and information overload. Communications of the ACM, 37 (7) (1994) 31-40. 10. Nwana, H.: Software Agents: An Overview. Knowledge Engineering Review, Vol.11, N.3 (1996) 1-40. 11. Wooldridge, M., Jennings, N. R.: Intelligent Agents: Theory and Practice. In: Knowledge Engineering Review Volume 10 Nro 2. Cambridge University Press (1995). 12. Searle, J. L., Speech Acts. Cambridge University Press (1969). 13. Gruber, T.R.: A translation approach to portable ontology specification. Knowledge Acquisition. Vol. 5 (1993) 199-220. 14. Dourish, P., Belloti, V.: Awareness and coordination in shared workspaces. In Proceedings of CSCW ’92 (1992) 107-114. 15. Sohlenkamp, M.: Supporting Group Awareness in Multi-User Environments through Perceptualization. GMD Research Series; No. 6. (1999) 16. 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. 17. Gutwin, C., Greenberg, S.: A framework of Awareness for Small Groups in Shared Workspace Groupware. Technical Report 99-1, Department of Computer Science, University of Saskatchewan, Canada (1999). 18. Grudin, J.: Groupware and social dynamics: Eight challenges for developers. Communications of the ACM, 37,1 (1994) 92-105. 19. Belloti, V., Edwards, K.: Intelligibility and Accountability: Human Considerations in Context Aware Systems. Human Computer Interaction. Vol. 16. Special Issue on ContextAware Computing (2001). 20. De Michelis, G.: Computer Support for Cooperative Work: Computers Between Users and Social Complexity. In: Zucchermaglio, Bagnara, Stucky (eds.) Organizational Learning

Intelligent Awareness in Support of Collaborative Virtual Work Groups

21.

22.

23.

24.

25.

26.

27. 28.

29.

30. 31.

32. 33.

34. 35.

36. 37.

187

and Technological Change, NATO Series, Berlin: Springer Verlag, Vol.141 (1995) 307330. Agostini, A., De Michelis, G., Grasso, M., Prinz, W., Syri, A.: Contexts, Work Processes and Workspaces. In: CSCW: The Journal of Collaborative Computing. Vol.5, N°2-3 (1996) 223-250. Haake, J., Wang, W.: Flexible Support for Business Processes: Extending Cooperative Hypermedia with Process Support. In: Information and Software Technology, Vol. 41, No. 6 (1999) 355-366. Carlsen, S.: Conceptual Modeling and Composition of Flexible Workflow Models. PhD Thesis, Information Systems Group, Dep. of Computer and Information Science, Norwegian University of Science and Technology, Trondheim (1997). Schlichter, J., Koch, M., Bürger, M.: Workspace Awareness for Distributed Teams. In Proc. Workshop Coordination Technology for Collaborative Applications, Singapore (1997). Haake, J.: Structural Computing in the Collaborative Work Domain?. In: Reich, S., Anderson, K., (eds): Open Hypermedia Systems and Structural Computing. Proc. of the 6 Int. OHS Workshop and 2 Int. SC Workshop. Lecture Notes in Computer Science, Vol. 1903, Springer-Verlag, Berlin Heidelberg New York (2000) 108-119. Wang, W., Haake, J.: Tailoring Groupware: The Cooperative Hypermedia Approach. In: Special Issue on Tailorable Systems and Cooperative Work in CSCW: the Journal of Cooperative Computing (1999). Wang, W., Rada, R.: Structured Hypertext with Domain Semantics, ACM Transactions on Information Systems, Vol. 16, No. 4 (1998) 372-412. Uschold, M., King, M., Moralee, S., Zorgios, Y.: The Enterprise Ontology. In: Uschold, M., and Tate, A., The Knowledge Engineering Review, Vol. 13. Special Issue on Putting Ontologies to Use (1998). Bannon, L., Bødker, S.: Beyond the Interface: Encountering Artifacts in Use. In: Carroll, J.M. (ed.) Designing Interaction: Psychology at the Human-Computer Interface. Cambridge University Press. NY. (1991) 227-253. Winograd, T., Flores, C. F.: Understanding computers and cognition: A new foundation for design. Norwood, NJ: Ablex (1986). Dey, A., Abowd, G., Salber, D.: A conceptual framework and a toolkit for supporting the rapid prototyping of context-aware applications. Human Computer Interaction Vol.16. Special Issue on Context-Aware Computing. (2001). Yan, H., Selker, T.: Context-aware office assistant. In: Proceedings of the 2000 Int. Conference on Intelligent User Interfaces, New Orleans. ACM Press. (2000) 276-279. Schilit, N., Adams, N., Want, R.: Context-aware computing applications. In: Proc. of IEEE Workshop on Mobile Computing Systems and Applications, IEEE Computer Society Press (1994) 85-90. Persson, P.: Social Ubiquitous Computing. In CHI 2001 Building the Ubiquitous Computing User Experience, Position Paper Ishii, H., Ullmer, B.: Tangible Bits: Towards seamless interfaces between people, bits and atoms. In Proceedings of the CHI '97 Conference on Human Factors in Computing Systems. New York, NY: ACM Press. (1997) 234-241 Barton, J., Kindberg, T.: The Cooltown Experience. In CHI 2001 Building the Ubiquitous Computing User Experience, Position Paper Davies, N., Mitchell, K., Cheverest, K., Blair, G., Developing a Context Sensitive Tourist Guide. In: First Workshop on Human Computer Interaction with Mobile Devices.

188

R. Alarcón and D. Fuller

38. Lieberman, H., Selker, T.: Out of Context: Computer Systems That Adapt To, and Learn From, Context. IBM Systems Journal 39, No. 3-4 (2000) 617-32. 39. Abowd, G., Mynatt, E.: Charting Past, Present, and Future Research in Ubiquitous Computing. In ACM Transactions on Computer-Human Interaction. V.7 N.1 (2000) 29-58. 40. Bellifemine, F., Poggi, A., Rimassa, G.: JADE – A FIPA-compliant agent framework. Proceedings of PAAM 99, London (1999) 97-108. 41. Bechhofer, S., Horrocks, I., Patel-Schneider, P., Tessaris, S.: A proposal for a description logic interface. In P. Lambrix, A. Borgida, M. Lenzerini, R. Möller, and P. PatelSchneider, (eds), Proc. of the International Workshop on Description Logics (DL'99) (1999) 33-36. 42. Horrocks, I., FaCT and iFaCT. In P. Lambrix, A. Borgida, M. Lenzerini, R. Möller, and P. Patel-Schneider, (eds), Proceedings of the International Workshop on Description Logics (DL'99) (1999) 133-135.

The 3-Ontology: A Framework to Place Cooperative Awareness Edmundo P. Leiva-Lobos and Eliana Covarrubias Universidad de Santiago de Chile, Facultad de Ingeniería, Departamento de Ingeniería Informática, Avenida Ecuador 3659, Santiago, Chile {epleiva, eliana}@diinf.usach.cl

Abstract. Understanding and supporting cooperative awareness in CSCW have no definitive answer. Actual awareness models have addressed spatial aspects of interaction rather than other forms of awareness. While technology has privileged event notification by specialized servers it is not clear how both spatial and temporal aspects can be met together in a coherent framework. This paper presents a framework called 3-ontology which takes events, places, and communities as starting points to conceptualize cooperative awareness. Each element in the 3-ontology represents a perspective to cope with cooperative awareness. Technologically, this model has been mapped to a software architecture called JAZZ which has a pool of shared data with 3 servers representing each element of the model. From the client side, this arrangement allows us always to gather information from any cooperative system relative to 3-ontology. So, one way to prove the generality of our cooperative awareness formulation is to see how other models can be mapped to our model.

1

Introduction

When somebody using backpacks disturb those waiting in a corridor, they cannot see that she/he is having an awareness problem. In fact, backpack users are unaware of this prosthesis since no sensor is posted on it to inform physical contact with others. Using this metaphor, awareness support is similar to putting suitable sensor within cooperative application in order to expand our sense of being aware-of. Cooperative Awareness (CA) support is a key concept for the reduction of costs associated to cooperation. The provision of awareness information to cooperative applications has been recognized as an important element to solve problems caused by computer mediated interactions. Awareness works as a glue that allows groups to be more effective than individuals [17]. However, to give a single definition of awareness seems difficult [9], awareness appears in the literature with several and contrasting definitions, and particularly hard is to give a conceptualization for software purposes. Despite these difficulties, one can refer to awareness in terms of models (spatial) and technology (event promotion) associated with it. In this paper, we offer a theoretical framework that takes these elements into considerations, and which we explore in the next section.

J.M. Haake and J.A. Pino (Eds.): CRIWG 2002, LNCS 2440, pp. 189–199, 2002. © Springer-Verlag Berlin Heidelberg 2002

190

2

E.P. Leiva-Lobos and E. Covarrubias

Models of Awareness

The CSCW literature has signalized the space as main locus of discourse about awareness models. In fact, The most notable representative of this approach is the socalled Spatial Model of Interaction, SMI [2]. The relevant notions in this approach are presence in a shared workspace, mutual orientation, vicinity of artifacts and activities of others. The first formalizations of these notions have been captured and applied to Virtual Reality [3], [4], [9] and later refined and generalized by [15], [16], [19], [1]. For example, the Rodden’s SMI generalization [15] is based on embodiment of users into a space, which is a model that represents the behaviour of the cooperative application. Some problems can be observed regarding SMI and its generalizations, so called spatial models. The mechanisms of awareness in spatial models can not privilege but awareness of presence and gesticulation cues left by users in such space. These approaches usually deal with real-time applications rather tan asynchronous ones. This implies that users of cooperative applications have obstacles to do temporary switches in real situation of work. We can rescue however from spatial models, the notion of vicinity of resources present in Rodden, Simone and Bandini as CoBrow [18], a cooperative web based technology. Vicinity allow us to define the notion of transparence and visibility of work. This allows users to avoid cognitive overloading provoked by current GUI world [12]. This subject is described in more details later in the paper.

3

Supporting Awareness

If we recognize awareness as a fundamental element in any type of coordination then we need to make it explicit in order to develop cooperative application [16]. At least, this is the direction taken by toolkits for CSCW such as Corona [10], Lotus NSTP [13], Aw-Manager [19] and Worlds [12]. In the same vein, Rodden and co-authors [14] have analyzed, under the umbrella of ‘notification servers’, different awareness architecture problems related to scalability and performance of event notification servers. This work uses a formal HCI machinery and status-event analysis to create a lexicon of awareness support, integrating also the interaction pace problem that this poses. Adding state and events, this work tries to overcomes the dichotomy of state in a shared space and event promotion. However, this work fails to address visibility and transparence. Most literature about awareness equates awareness support with making work visible to others. We claim that CA support is effective when applications render visible the context in certain occasions and absolutely transparent in others.

4

Separating Concerns

The basic idea followed by awareness support is to extract the awareness mechanism behind cooperative applications. Metawebs, awareness engines and cooperative toolkits are all examples of how cooperative applications and awareness mechanisms

The 3-Ontology: A Framework to Place Cooperative Awareness

191

have been separated. For example, the following figure shows the separation used in CoDesk [16]: Application Level

Environment Level

Awareness Level Fig. 1. Awareness supporting in CoDesk

Although there are a great number of proposals with different approaches about CA, all agree that it is necessary to monitor application (and hence user manipulation) and environmental events. The reason for this is that they have be selected, recorded and distributed to the components concerned in the cooperation. Toolkits in CSCW often use metaphors for separating the semantic of application from awareness promotion. For example, NSTP [13] uses the keyword ‘place’ to denote the space where cooperation evolves, and ‘things’ to mean the inhabitant of that space. What ‘place’ and ‘things’ actually means semantically depend on the specific client applet activation (Java Applet). Meanwhile in Corona’s case [10] we have ‘groups’ instead of ‘places’ and ‘members’ in place of ‘things’. Another option is the policy adopted by AW-Manager [19]. The awareness services supported by this engine depend on the level of visibility of the application behaviour. Here, cooperative application and awareness engine are physically separated but semantically related. The application generates a simple log of events that are consummated by the engine and the awareness information is managed by human actors cooperating through the application. In the latter case, awareness information could be promoted also taking into consideration the behaviour of the application components. The AW-Manager contains a configuration module devoted to the definition and adaptation of awareness mechanisms according to the execution of RDM model and a runtime module. The Runtime module interacts with the target application. This module receives from the application the notification of facts, relevant from the awareness point of view. Then it activates the awareness mechanisms accordingly and it sends back to the application the awareness information which is subsequently given to the appropriate actors/components involved in the application.

5

Problems with Current Formulations

The common factors supporting formalizations in spatial models are the notions of presence, activity and attention at some workspace representation. Thus, the concept of place is broader than simply the environment’s spatial organization and threedimensions. By itself, however, the notion of space is far too simplistic to include time and culture. Hence other aspects of shared interaction are not addressed in spatial

192

E.P. Leiva-Lobos and E. Covarrubias

models. On the other hand, notification servers and toolkits have a weak conceptualization on what awareness means and usually they use a mix between space and events promotion. So, in both theoretically and technologically, CA lacks a general framework that goes beyond of a naive notions of space and events of common interest. People see the world as already structured and unified. Our background affect what we perceive or the context in which we perceive it. Thus, the words “attention” and “context” appear as decisive concepts to define awareness. These concepts are discussed in the next section.

6

Looking for a Definition

The dictionary defines awareness as ‘having perception, knowledge or realization’; as synonyms, it includes, ‘informed’ and ‘conscious’. Analyzing these terms, Greenberg and Johnson (1997) explain ‘people must perceive certain types of awareness information in their environment, know how to interpret its meaning in their particular context, and realize how to apply that information’. Although highly influenced by cognitivism, the above definition is useful since it distinguishes the relevant terms for awareness formulation: an environment, perception, knowledge and realization. This definition is not sufficient. However, what is peculiar about CA is the creation of social meanings rather than isolated ones. The tasks are collective and belong to a cooperative environment. Thus, we can define CA as a mean for reaching inter-subjective comprehension among persons, intelligibility in a cooperative ensemble of what is happening, where and with whom. Simone and Bandini suggest splitting the concept of awareness in two: in ‘sentience to, elementary consciousness of’ and ‘having knowledge of’. The first meaning is connected to a contingent situation where people are co-located. Instead the second meaning is related to the context surrounding the situation. On the basis of this distinction awareness can be divided in attentive and contextual. First, attentive awareness is embodied (or enacted) cognition. It derives from the fact that our social skills are expressed through the physical world in order to maintain cooperation with others. Attentive awareness is directly associated with people bringing their movements and gestures (their behaviour in general) to the attention of others. Primary metaphors are those regarding a large part of cognitive unconsciousness derived and learned from sensor-motor experiences: spatial metaphors are a typical example. It is the type of awareness most empirically researched so far in CSCW and its most remarkable formulation is the spatial model of interaction [2]. On the other hand, contextual awareness is a more abstract concept. It is connected to the context where artefacts, action and communication take place (resources in general). In fact, our awareness of something is always affected by the context in which we perceive it. Although this is well known, there is a clear lack of theories for tackling contextual awareness in CSCW. The aim of our 3-ontology is to fill this theoretical gap.

The 3-Ontology: A Framework to Place Cooperative Awareness

7

193

Theoretical Formulation: The 3-Ontology

Philosophically speaking, ontology is related to intelligibility of the world and the fundamental way of making sense of things. In computing, ontology is usually used to describe concepts and relationships that make entities exist within a specific domain. Both meanings are applied in our formulation. From our point of view, CA is a mean for reaching inter-subjective comprehension among persons and intelligibility in a cooperative ensemble. Taking in account these definitions it is not difficult to connect ontology with awareness. However, we have to incorporate a third element: the work context. We claim that CA is entirely correlated with the work context [1]. This realization about the importance of the work context poses, besides, many difficult questions. What are the relations between artifacts, places, individuals, and the social groups to which they belong? What exactly is a context? If the individual is no longer central, what is the suitable unit of analysis? In the following section we present a possible answer to these questions. 7.1

Placing the Context

A context encompasses each artifact, resource, action or communication in major containers that make sense to users. We propose communities, events and places as such containers. In others words, the context where cooperating actors are situated is tripartite: spatial, temporal and cultural. The spatial context is constituted by all the artifacts populating the physical or electronic space. The temporal context is constituted by the history of cooperative processes actors perform and by their expected future. Finally, the cultural context is constituted by actors shared views and practices, i.e., it is characterized by their community of practices. The figure 2 shows that places can contain objects, as well as by other places. Often the difference between places and objects is not absolutely clear, however, both can be represented by maps and both have of physical or electronic nature. On the other hand, events happen in a given time and in a place. Events are located in an trace or historical context in which they acquire sense. Each event is part of a situated plan that can be considered in itself an event since they have a nested character. Finally, we claim that communities inhabit places and are protagonists of events that happen. A community can also be defined directly, or as a community which occupies a place or as a community which participates in an event. Notice that, the communities are constituted, in addition, recursively since a community can be part of others than contains it. Furthermore, portrait is concept used to represent both communities and the people who belong to it. The recursive nature observed in locus place, event and community allows us to speak of different levels of aggregation and to give account of the generative nature of the presented theoretical model. In few words, the representation of locus for awareness expressed in maps, traces and portrait favour the separation of two aspects: one relative to the cooperative application itself and other referred the required information to support awareness on it.

194

E.P. Leiva-Lobos and E. Covarrubias constituted by

Portraits

Community

inhabit

belong to

belong to participate in

constituted by

Place

People

constituted by

happend in surround

Event

Maps Object

Traces

Fig. 2. Locus of the 3-Ontology

In order to avoid the use of the expression “meta information” we have preferred to use the terms maps, traces and portrait. This does not correspond to an accidental distinction, on the contrary, it corresponds to the idea of using them to divide cooperation and its respective awareness support by explicit meta levels. 7.2

Explicit Meta Level

Supporting meta level (‘application conscience’) or reflection about the application operation is required when cooperation changes from routine to improvisation. In fact, computational reflection is required when the work evolves with diverse scales of time according to Dourish [6] and [7]. This author claims that the user’s view of relationship between the state of system and the state of activity is rooted in some belief about how the system works. So, it is very important for the user to know the story that the ‘system’ tells about the operation of itself. In this approach an ontology of system operation is needed (meta level) to answer not only the question what a thing is (usual abstraction in software engineering) but also how, when and where such a thing is. This information about the system has to capture the underlying structure of cooperative work and where it connects with the system’s states. This is precisely the motivation of our ontology about CA. Throughout the paper we have also claimed that cooperative awareness is not just a matter of context visibility. It must be complemented with a notion of transparence in order to avoid cognitive overloading by cooperating actors. 7.3

Awareness Modalities: Visibility and Transparence

In this paper we have mentioned that CA support is not simply a problem of the visible context. Rather, this must be complemented with a notion of transparence that in order to release human actors of information overload.

The 3-Ontology: A Framework to Place Cooperative Awareness

195

The visibility is a modality of awareness when a rupture of expected events (a breakdown) occurs in our comfortable being in the world. While the transparence is a modality of awareness that can be more characterized like a state than an event. In other words, when the transparency is embodied we are subsumed completely by the task on which we are focused. For example, artefacts of public use (documents, files, etc.) are clear instances of the visibility of explicit knowledge. However, an actor’s tacit knowledge or know-how (abilities embodied in a context) is transparent. Visibility and transparency can be placed in a tripartite context where the cooperative actors are located. The place context, that is constituted by the devices that are within the space which they occupy, can be visible or transparent. In the same way, the event context can be seen as a history of visible cooperative processes or being transparent. Finally, also the community context, that corresponds to certain social practices, can be visible or transparent.

7.4

Proposal Generality

One way of proving the generalization of our formulation of CA is to be able to locate cooperative applications and to circumscribe them in terms of this new proposal. To achieve this, we use a polar cartography that reunites the distinctions of our formulation, as you can see in the following figure: Community Visibility

Transparence

Place

Event

Fig. 3. Cooperative awareness cartography

Each axis acts like a pole of attraction; that is, the closer a proposal is to a pole the more influence it has. As usual, we use the categories of community, event and place as meridians. Meanwhile the categories of visibility and transparence intersect the previous ones acting as true parallels. This cartography locates the most prominent models and positions about awareness in last six years in the area of CSCW. The details can be found in Leiva-Lobos’s doctoral thesis [11]. The author in his doctoral thesis studied 8 proposals, using this polar map, each one of them occupies a portion of the territory. In summary, the studied proposals were the following: the original spatial model of Benford [2]; the model of Rodden et al. [14]; the Aether model [16]; the reaction/diffusion model

196

E.P. Leiva-Lobos and E. Covarrubias

(RDM) of Simone and Bandini [19]; the model of Dourish [7]; the model of Dix [5] with its original feedthrough; the MILANO system [1] and finally, the proposed JAZZ model that will be briefly presented in the next section.

8

Technological Mapping

E-mail systems are by excellence the most recognized cooperative applications in CSCW. So, we will use it to demonstrate the practical value of the proposed model. 8.1

E-mail System by 3-Ontology Perspective

Let us consider the following generic communication using an e-mail system: A sends an e-mail message to B. From B’s viewpoint, the recipient could be interested in to seek information at least in three aspects. First, who is A? Second, is this message the first or is it a response to another one? Finally, what folder is the message in? Each question has a particular projection in our 3-dimensional formulation of the work context. The first is in relation to people involved in the conversation, most generally to the community of persons of which this sender is part. The second question is a typical process issue. In this the user wants to situate the e-mail message in a flow of enacted communicative events. The third question is an electronic space location concern. People inhabit physical and electronic places, and looking for an email message belongs to the last category. In addition, replay mechanism is an good example of transparence in e-mail system. In this case users need not worry about the sender’s electronic address since the mailer makes available this information transparently for users. Entire above example motives the idea of extracting awareness information from cooperative applications behaviour (see section 4) and letting available to a software architecture. This is possible by reflexive architecture (see section 7.2) since it allows separating the cooperation relative semantic from its respective awareness promotion. 8.2

MILANO Accomplished with JAZZ

The architecture JAZZ [16] was designed on the bases of the 3-ontology and it adopts its formulation. It was tested by a cooperative application called MILANO [1]. In addition, it adopts the reflective architecture of Dourish [6] to capture the cooperative events from MILANO. The events are gathered from the application, reified and distributed from a local context handler to a pool of three interconnected remote servers which are specialized in events, communities and places respectively. Given to the character of co-determination presented in 3-ontology, the servers ring must maintain a common data base inspirited in locales metaphor [12]. This arrangement facilitates the changes of contexts between each 3-ontology locus. Nevertheless, each server is responsible of specific services of awareness to the

The 3-Ontology: A Framework to Place Cooperative Awareness

JAZZ Architecture

197

Server of Presence

Meta Level Server of History Server of Context

3-Ontology Context Object

Organizational Server

WP-Locales

Local Context

Milano Object

Base Level Mailbox

To-do List

Network Infrastructure

Fig. 4. High level architecture of JAZZ

participants of the cooperative application. More indeed, the services of the community are connected with the promotion of the identity and the possibility of expanding its frontiers. The services of the place give to information of the presence of others and the access to the resources in the place, whatever they being of nature physical or electronic. Finally, the services associated to the time favour the continuity of the work between sessions of connection. In addition, the server of history incorporates event notification between the participants. Transparency in the cooperative application is supported by software agents which work in the background by monitoring and collecting information of the system operation and the user manipulation. The information collected uses a notion of artifact vicinity inspired in Rodden works on generalization of SMI [15]. In that way, applying a distance notion, the user brings forth the nearest artefact [18] to current work context; avoiding this way the cognitive overloading that large contextual information involves.

9

Conclusion

The 3-ontology is a theoretical proposal to give a holistic solution to the problem of CA when the human interaction is mediated by computers. This proposal incorporates a new lexicon that allows to circumscribe any action that is carried out in cooperative work. Indeed that characteristic allows us to unite different available knowledge islands on awareness. The subject of integration is mandatory; specially at this moment in which we appreciate partial and fragmented technological results about CA. In this line, the interoperability is necessary, but no sufficient to achieve such integration. First we needed a solid theoretical framework to locate the technology on awareness support. This work goes in that direction and tries to inspire the new technological support on this key factor of the human cooperation. The research outlined presented here implies changes, even deeper in CSCW. New methodologies for developing software have to take in account the experience of being aware-of. Even, as designers of cooperative applications we must see ourselves

198

E.P. Leiva-Lobos and E. Covarrubias

being aware of being aware of others. In other words, a second order of reflection in methodological level emerge from the technological, as JAZZ proposal, at theoretical level. Not only our position as researcher and designers must be different but also the way in which we develop cooperative applications must change radically to consider seriously the phenomenology of experience of work altogether.

References 1.

2.

3.

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

11. 12.

13.

Agostini, A., De Michelis, G., Grasso M.A., Prinz, W. and Syri A.: Contexts, Work Processes and Workspaces. In: Computer Supported Cooperative Work. The Journal of Collaborative Computing. Vol. 5, N° 2-3. Kluwer Academic Publishers, Amsterdam (1996) 223-250 Benford, S.D. and Fahlén, L.E.: A Spatial Model of Interaction in Large Virtual Environments. In: De Michelis, G., Simone, C. and Schmidt, K. (eds.): Proceeding of the 3rd European Conference on Computer Supported Cooperative Work ECSCW’93. Dordrecht: Kluwer Academic Publishers, Milano, Italy (1993) 109-124 Benford, S.D., Bowers, J., Fahlén, L.E. and Greenhalgh, C.: Managing Mutual Awareness in Collaborative Virtual Environments. In: Singh, G., Feiner, S.K. and Thalmann, D. (eds.): Proceeding ACM SIGCHI Symposium on Virtual Reality Software and Technology VRST’94. World Scientific Publishing Co, Inc., River Edge, NJ (1994) 223-236 Carlsson, C. and Hagsand, O.: DIVE: A Platform for Multi-User Virtual Environments. In: Computer & Graphics, Vol. 17, N° 6, (1993) 663-669 Dix, A.: Computer Supported Cooperative Work: A Framework. In: Rosenberg, D. and Hutchinson, C. (eds.): Design Issues in CSCW. Springer Verlag, London (1994) 9-26 Dourish, P.: Accounting for System Behavior: Representation, Reflection and Resourceful Action, Technical Report ECP-1995-101. Cambridge Laboratory, Rank Xerox Research Centre, Cambridge (1995) Dourish, P.: Open Implementation and Flexibility in Collaborative Toolkits (Ph.D. thesis). Department of Computer Science, University College , London (1996) Greenberg, S. and Johnson, B.: Studying Awareness in Contact Facilitation. In: McDaniel S.E. and Brinck, T. (eds.): Proceedings of the ACM CHI’97 Workshop on Awareness in Collaborative Systems. ACM Press, Altlanta, Georgia (1997) Greenhalgh, C. and Benford, S.D.: MASSIVE: A Collaborative Virtual Environment for Teleconferencing. In: ACM Transaction on Computer-Human Interaction, Vol. 2, N° 3. ACM Press, (1995) 239–261 Hall, R.W., Mathur, A., Jahanian, F., Prakash, A., Prakash, A. and Rassmussen, C.: Corona: A Communication Service for Scalable, Reliable Group Collaboration Systems. In: Proceedings of the ACM Conference on Computer Supported Cooperative Work CSCW’96. ACM Press, (1996) 140-149 Leiva-Lobos, E.P.: 3-Ontology: An Integral Support for Cooperative Awareness (Ph.D. thesis). Department of Computer Science, University of Milan, Italy (2000) Mansfield, T., Kaplan, S., Fitzpatrick, G., Phelps, T., Fitzpatrick, M. and Taylor, R.: Evolving Orbit: A Progress Report on Building Locales. In: Hayne, S.C. and Prinz, W. (eds.): Proceeding of the International ACM SIGGROUP, Conference on Supporting Group Work: The Integration Challenge GROUP’97. ACM Press, Phoenix, Arizona (1997) 241-250 Patterson, J.F., Day, M. and Kucan, J.: Notification Servers for Synchronous Groupware. In: Proceedings of the ACM Conference on Computer Supported Cooperative Work CSCW’96. ACM Press, Boston (1996) 122-129

The 3-Ontology: A Framework to Place Cooperative Awareness

199

14. Ramduny, D., Dix, A. and Rodden, T.: Exploring the Design Space for Notification Servers. In: Proceedings of the ACM Conference on Computer Supported Cooperative Work CSCW ’98. ACM Press, Seattle (1998) 227-235 15. Rodden, T.: Populating the Application: A Model of Awareness for Cooperative Applications. In: Proceedings of the Conference on Computer Supported Cooperative Work CSCW’96. ACM Press, Boston (1996) 87-96 16. Sandor, O., Bogdan, C. and Bower, J.: AETHER: An Awareness Engine for CSCW. In: Schmidt, K. (eds.): Proceeding of the 5th European Conference on Computer Supported Cooperative Work ECSCW’97. Dordrecht: Kluwer Academic Publishers, Lancaster, UK (1997) 245-264 17. Schlichter, J., Koch, M. and Bürger, M.: Workspace Awareness for Distributed Teams. In: Conen, W. and Neumann, G. (eds.): Proceeding Workshop Coordination Technology for Collaborative Applications, Organizations, Processes, and Agents. Lecture Notes on Computer Science 1364. Springer Verlag, Berlin (1997) 199-218 18. Sidler, G., Scott, A. and Wolf, H.: Collaborative Browsing in the World Wide Web Applications. In: Proceedings of the 8th Joint European Networking Conference. Edinburgh, Scotland (1997) 122-2 to 122-8 19. Simone, C. and Bandini, S.: Agents in the Design of Cooperative Applications. In: Schmidt, K. (eds.): Proceedings of the the 5th European Conference on CSCW’97: Workshop Social Agents in Web-based Collaboration, Dordrecht: Kluwer Academic Publishers, Lancaster, UK (1997)

Evaluating Collaborative Learning Processes César A. Collazos1, 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. Understanding and analyzing collaborative learning processes require a fine-grained sequential analysis of the group interaction in the context of learning goals. Several researchers in the area of cooperative work take as a success criterion the quality of the group outcome. Nevertheless, recent findings are giving importance to the quality of the cooperation process itself. This paper presents a set of indicators which main objective is to evaluate the collaborative learning process. We have defined an experiment with a tool instrumented to gather data from groups working in a simple task. This data is then useful to build the cooperation indicators, which in turn allow us to estimate the quality of the work process.

1 Introduction Dillenbourg et al. claim that during many years, theories of collaborative learning have been focused on how individuals work in group, and recently, they have focused on the group by itself, trying to establish when and under what circumstances collaborative learning is more effective than individual learning [7]. In this context, some independent variables have been identified and widely studied: the size and composition of the group, the nature and the objectives of the task, the media and communication channels, the interaction between peers, the reward system and sex differences, among others [1,7,27]. Recent research, however, is giving emphasis to the study of collaboration processes and their support [3,4]. The work reported in this paper concerns the collaboration processes. Collaborative learning is a complex phenomenon, and studies are being conducted from many different analytical levels and from a range of various theoretical and methodological perspectives. Understanding group dynamics, and the collaborative processes of decision making and learning in groups, is important for both learners and instructors in collaborative learning programs. Understanding and analyzing the collaborative learning process requires a fine-grained sequential analysis of the group interaction in the context of learning goals. We may notice that supporting individual learning requires an understanding of individual thought process, whereas supporting group learning requires an understanding of the process of collaborative learning [23].

1

On leave from FIET, Universidad del Cauca, Colombia.

J.M. Haake and J.A. Pino (Eds.): CRIWG 2002, LNCS 2440, pp. 203–221, 2002. © Springer-Verlag Berlin Heidelberg 2002

204

C.A. Collazos et al.

Several researchers in the area of cooperative work take as a success criterion the quality of the group outcome. Nevertheless, recent findings are giving more importance to the quality of the “cooperation process” itself. Success in collaborative learning subject matter means both learning the subject matter (collaborating to learn), and learning how to effectively manage the interaction (learning to collaborate). The knowledge acquisition process for systems supporting collaborative learning warrants a closer look in light of this additional complexity [24]. Traditional instruction tends to emphasize the product of the design and development process, but not the process itself [19]. The typical evaluation of collaborative learning has been made by means of examinations or tests to the students to determine how much they have learned. That is to say, a quantitative evaluation of the quality of the outcome is done. Some techniques of cooperative learning use this strategy (e.g. “Student Team Learning” [24], “Group Investigation” [25], “Structural Approach” [17] and “Learning Together” [13]). Nevertheless, little investigation has been done to evaluate the quality of the collaboration process. Taking into account the characterization of cooperative learning presented by Johnson & Johnson [16], we further develop the Index of Collaboration proposed by Guerrero et al. [10], by defining a set of indicators. These indicators are intended to help in the evaluation of the collaborative learning process. We have defined an experiment with a tool instrumented to gather data useful to build these cooperation indicators, which in turn allow us to estimate the quality of the work process. This paper is organized as follows. In section 2, we present some related work. Section 3 presents the Johnson & Johnson characterization of collaborative learning processes. In section 4, we propose an evaluation instrument. Section 5 describes the metrics we used. Section 6 introduces the cooperation indicators as well as a method that allows us to evaluate some key points identified in the phases of collaborative learning. Section 7 describes the experimental design. An analysis of the results is done in Section 8, and finally, section 9 presents some conclusions and proposals for future work.

2 Related Work Since the advent of computer supported collaborative work, the investigation of computer supported collaborative learning 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 [21]. Collaboration is the mutual engagement of participants in a coordinated effort to solve a problem together [22]. Various approaches for analyzing group learning interaction have been proposed. Some of them are presented below to have an overview of how this interaction is considered from different perspectives. Barros and Verdejo [3] have proposed an asynchronous newsgroup-style environment enabling students to have structured, computer-mediated discussions online. Evaluating the interaction involves analyzing the conversation to compute values for the following four attributes: initiative, creativity, elaboration, and conformity. Katz et al. [18] developed two rule learning systems, String Rule Learner and

Evaluating Collaborative Learning Processes

205

Grammar Learner. These systems learn patterns of conversation acts from dialog segments that target particular pedagogical goals. Inaba & Okamoto [11] describe a model that draws upon the ideas of finite state machines and utility functions. They used a finite state machine to control the flow of conversation and to identify proposals, while applying utility functions to measure participants’ beliefs with regard to the group conversation. Muhlenbrock and Hoppe [21] have developed a framework system for computersupported cooperative learning and working. The system has been used in determining conflicts in focus setting as well as initiative shifts in aggregation and revision phases during some collaborative sessions on problem solving. Constantino-González et al. [5] developed a system that evaluates a new approach to supporting collaboration that identifies learning opportunities based on studying differences among problem solutions and on tracking levels of participation. Soller & Lesgold [23] have developed an approach to analyze collaborative learning using Hidden Markov Models. Additional work is needed to understand how students communicate and collaborate, and to apply this knowledge to develop computational methods for determining how to best support and assist the collaboration learning process. This is our rationale to propose a set of indicators in order to understand the collaborative learning process. Next there is an explanation on how we defined our set of indicators, based on the stages of cooperative learning processes presented by Johnson & Johnson in [1].

3 Stages of Cooperative Learning Processes A cooperative learning process is typically composed of several tasks that must be developed by the cognitive mediator or facilitator, and by the group of apprentices, defining naturally two categories of tasks. In order to evaluate the cooperative learning process, we divide it into three phases according to its temporal execution: preprocess, in-process and post-process. Thus, pre-process tasks are mainly coordination and strategy definition activities and post-process tasks are mainly work evaluation activities. Both phases, pre-process and post-process, will be accompli-shed entirely by the facilitator. The tasks concerning the in-process phase will be performed, to a large extent, by the group members. It is here where the interactions of cooperative work processes take place. Thus, our interest concentrates in the evaluation of this stage. In order to specify this division, we present the structure of a cooperative learning activity identified by Johnson & Johnson in [1], and next we classify each activity according to the stage we are proposing2: 1. Design the content and main tasks objectives to be accomplished by cooperative groups (pre-process). 2. Specify the size of the groups. It has been suggested to be up to 6 people depending on the nature of the task and the time available (pre-process). 3. Build the groups. Assign the students to conform each group or allow them to form the groups by their own (pre-process). 2 Johnson & Johnson do not make this phase differentiation.

206

C.A. Collazos et al.

4. Arrange the room for the cooperative learning activity. The facilitator must be “attainable” by every group and their members can seat together without interrupting other groups (pre-process). 5. Distribute the instructional material. This can be achieved in several ways (preprocess). 6. Design roles, such as: speaker, facilitator, recorder, executor, and observer (preprocess). 7. Specify the directives of the task: the facilitator must define the game rules (preprocess). 8. Apply strategies like positive interdependence of the goal, motivation of the peers and support to learning. Create a product related to a goal system where rewards are based on individual and group results (it is defined in the pre-process, but evaluated in the in-process phase). 9. Organize the intra-group cooperation, that is to say, define the collaboration strategies that are going to be used by the members of the group (pre-process, the definition of cooperation strategies occurs in the in-process phase). 10. Test the success criteria explaining the guidelines, limits and roles (pre-process, in-process and post-process phases). The success criteria must be defined at the beginning of the activity, and must be reviewed during the activity to check if the common goal is being reached, and after the activity, to check if the common goal was reached. 11. Determine the desired behavior (pre-process, definition of desired behavior occurs in the in-process phase). 12. Monitor the students, for example, verify that the previous point is fulfilled (phase of in-process). 13. Provide assistance when someone asks for it (in-process phase): it is provided to the whole group by the facilitator or peers. 14. The facilitator must intervene when groups have problems to collaborate (inprocess phase). 15. Terminate an activity (post-process phase). 16. Evaluate the quality of learning accomplished by the students at the end of the activity (post-process phase). 17. Encourage students to perform an evaluation on how well the group works altogether (at the end of the in-process phase). 18. Provide and foster feedback. Discuss how the activities could be improved (at the end of the in-process phase). Table 1 summarizes the activities and specifies the corresponding phases. These activities define the structure of any cooperative learning activity that takes place in small groups, and in synchronous learning scenarios (face to face, same time, same place). We are interested in the evaluation of the activities that correspond to the inprocess phase. Based on these, we will define some collaboration indicators. The next section introduces a software tool used to get raw data which will be elaborated by the collaboration indicators.

Evaluating Collaborative Learning Processes

207

Table 1. Activities of a cooperative learning process Pre-process Design the contents Specify the group sizes

In-process

Post-process

Application of strategies (positive interdependence of the goal, motivation between pairs, aid to learn)

Inspect success criteria

Intra-group cooperation

Evaluate the quality of learning

Present the activity closure

Arrange the groups Arrange the room Probe the success criteria Distribute the material Monitoring Design the roles Specify the game rules

Provide help (from facilitator and from peers)

Define the success criteria

Intervention in case of problems

Determine the desired behavior

Self-evaluation of the group Feedback

4 Chase the Cheese Since our goal is to study the collaborative learning process, we developed a tool to capture data from groups engaged in such type of learning. We chose a small case in which a group of persons have to do some learning in order to do a joint task. The task is a game of the labyrinth type. The game –called Chase the cheese– is played by four persons, each with a computer. The computers are physically distant and the only communication allowed is computer-mediated. All activities made by participants are recorded for analysis and players are made aware of that. Players are given very few details about the game. The rest of the game rules must be discovered by the participants while playing. They also have to develop joint strategies to succeed. Therefore, people can only play the game once. 4.1 System Functionality Figure 1 shows the game interface. To the left, there are four quadrants. The goal of the game is to move the mouse (1) to its cheese (2). Each quadrant has a coordinator – one of the players– permitted to move the mouse with the arrows (4); the other participants –collaborators– can only help the coordinator sending their messages which are seen at the right-hand side of the screen (10). Each player has two predefined roles: coordinator (only one per quadrant and randomly assigned) or collaborator (the three remaining).

208

C.A. Collazos et al.

The game challenges the coordinator of a quadrant in which the mouse is located because there are obstacles to the mouse movements. Most of the obstacles are invisible to the quadrant coordinator, but visible to one of the other players. In each quadrant there are two types of obstacles through where the mouse cannot pass: general obstacles or grids (6) and colored obstacles (7). This is one of the features of the game which must be discovered by the players. The players must then develop a shared strategy to communicate obstacles location to the coordinator of the current quadrant. No message broadcasting is allowed, so players have to choose one receiver for each message they send (9). Since each participant has a partial view of the labyrinth, she must interact with her peers to solve the problem. In order to communicate with them, each player has a dialogue box (8) from which she can send messages to each of them explicitly (one at a time) through a set of buttons associated to the color of the destination (9). For example, in Figure 1, she can send messages to the players with blue, red and green colors.

Fig. 1. Chase the Cheese game interface.

Since each player has a color associated to her, her quadrant shows the corresponding color (5). When starting to move the mouse, the coordinator has an individual score (11) of 100 points. Whenever the mouse hits an obstacle, this score is decreased 10 points. The coordinator has to lead the mouse to the cheese (in the case of the last quadrant) or to a traffic light (3), where the mouse passes to another quadrant and her role is switched to collaborator and the coordinator role then, is assigned to the next player (clockwise). When this event occurs, the individual score is added to the total score of the group (12). Both scores, partial and total are hidden; if a player wants to see them, she must pass the mouse over the corresponding icon displaying the score for two seconds. 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).

Evaluating Collaborative Learning Processes

209

4.2 Gathered Information The application has a structured chat-style user interface, through which the group conversation is held. The application records every message sent by any member of the group. Along with each message, it records the time of occurrence, sender, addressee and current quadrant (the mouse location –X and Y position– when the message was sent). The Figure 2 shows an example of the information gathered by the application. In addition, it records the partial scores and total score by quadrant. The tool also registers the start and finish time of the game, the time spent in each quadrant, and the number of times each player looked at the partial and total scores by quadrant. X 1

Y 1

Quadrant 1

1

2

1

1 2 2 2 3

3 3 4 5 5

1 1 1 1 1

From

To

Message

Time

Andres Andres Andres Miguel Gaston Andres Sergio

Gaston Miguel Sergio Andres Andres Gaston Andres

I need your coordinates I need your coordinates I need your coordinates A2 and F4 A5 and G5 D3 and g3 ok

12:00:41 12:00:52 12:01:13 12:01:25 12:02:08 12:03:13 12:03:21

Miguel

Andres

Letters are arrows

12:04:32

Fig. 2. Log file content.

5 Metrics In order to analyze each one of the indicators, we define some metrics, that are indicators of system, user, and group performance that can be observed, singly or collectively, while executing group activities. Metrics –such as time, length of turn, and other countable events– are directly measurable and can often be automatically collected [8]. The following table of metrics includes the observable data elements that were identified as useful indicators of system and group performance. For each metric, we present definitions and some examples of ways to capture the metric in Table 2.

6 The Indicators Guerrero et al. [10] have defined an Index of Collaboration based on the structure of a cooperative learning activity explained above in section 2 (in-process phase). That

210

C.A. Collazos et al. Table 2. Metrics

Metric Number of Errors Solution to the problem Movements Score checks Use strategy Maintain strategy Communicate strategy Strategy messages

Work strategy messages

Coordination strategy messages Work messages Coordination messages Success criteria review messages Lateral messages

Total messages

Meaning Total hits over an obstacle. The group is able to solve the game.

Example

Number of mouse movements Total number of checks to the scores Outline a strategy for the problem solution in an explicit way. Use the defined strategy during all the game Negotiate, reaching consensus and disseminate information about strategy. Messages that propose guidelines to reach the group goal.

“Let's label the columns with letters and the rows with numbers” Messages that help the coordinator to make the “Stop, there is an most suitable decisions. These are sentences in obstacle in B3". present tense and their goal is to inform the group about the current state of the group task. Messages that correspond to activities which "I will move six main purpose is to regulate the dynamics of the squares to the process, and are characterized by prescribed right". future actions. Messages received by the coordinator. Messages sent by the coordinator.

Messages that review the boundaries, guidelines and roles of the group activity. The kind of particular messages (i.e. social "Come on, hurry up, messages, comments) and conversations that I'm hungry!!!!!!! ". are not focused on the solution of the problem. Total number of messages received and sent by the group during the activity.

Index was the simple average of five identified indicators based on some activities proposed by Johnson & Johnson in [1]. In this work, we present a refinement of that Index of Collaboration, defining a set of indicators which main objective is to evaluate the collaborative learning process. Four of the indicators are based on the following activities proposed by Johnson & Johnson in [1]: use of strategies, intra-group cooperation, checking the success criteria, and monitoring. The fifth indicator is based on the performance of the group. Each one of these indicators is explained below. 6.1 Applying Strategies The first indicator tries to capture the ability of the group members to generate, communicate and consistently apply a strategy to jointly solve the problem. According

Evaluating Collaborative Learning Processes

211

to Johnson & Johnson in [1], to apply a strategy is “to produce a single product or put in place an assessment system where rewards are based on individual scores and on the average for the group as a whole”. Group members are forced to closely interact with peers since each player has a partial view of the game obstacles. Therefore, the game presents a strict positive interdependence of goals. If the group is able to solve the game, we can say their members have built a shared understanding of the problem (see Dillenbourg definition of collaboration [7]). They must have understood the underlying problem: the coordinator does not have all the information needed to move the mouse in her quadrant without hitting any obstacle, so she needs the timely assistance from her collaborators. According to Fussell [9], the discussion of the strategy to solve the problem helps the group members to construct a shared view or mental model of their goals and tasks required to be executed. This mental model can improve the coordination, because each member knows how her task fits into the global team goals. The learning potential of a team is maximized when all the students actively participate in the group discussions. Building involvement in group discussions increases the amount of information available to the group, enhancing group decision making and improving the students’ quality of thought during the learning process [12]. In general, the specific measure to be considered for this indicator are subjectrelated. In our case study (Chase the Cheese), we estimated both the strategy the group applied and its success should be part of the indicator. Furthermore, we thought the strategy should have a weight four times larger than the one assigned to the success factor (whether or not the group solved the labyrinth). Thus, the first indicator (CI1) should be built with 80% weight for the applied strategy and 20% weight for the success factor. The strategy factor mentioned above was built from simple measures which could be obtained from the raw data. The 80% weight was explained as 20% for whether or not the group was able to keep the chosen strategy during the game development, 30% for quality of the strategy communication, and 5% for other quality measures. The other quality measures included number of errors made by the group (related to the score) and number of mouse movements (related to efficiency). 6.2 Intra-group Cooperation This indicator corresponds to the application of collaborative strategies previously defined during the process of group work. If each group member is able to understand how her task is related to the global team goals, then every one can anticipate her actions, requiring less coordination efforts. This indicator also includes measures related to the requirements of every player from her peers to reach her partial goal when acting as a coordinator. A group achieves promotive interdependence when the members of the group perceive that their goals are positively correlated such that an individual can only attain her goal if her team members also attain their goals [6]. In collaborative learning, these goals correspond to each member’s need to understand her team members’ ideas, questions, explanations, and problem solutions.

212

C.A. Collazos et al.

We have defined the CI2 indicator as: 80 % application of collaborative strategies and 20% providing help. Measuring the application of collaborative strategies implies the evaluation of coordination procedures and assessing the degree of joint understanding of the strategy. A good application of collaborative strategies should be observed as an efficient and fluid communication among members of the group. Good communication, in turn, means few, precise and timely messages (1 – (Work strategy messages)/(Work messages)). Providing help may be measured by the supporting messages from peers when the coordinator requests them. 6.3 Success Criteria Review This indicator measures the degree of involvement of the group members in reviewing boundaries, guidelines and roles during the group activity. It may include summarizing the outcome of the last task, assigning action items to members of the group, and noting times for expected completion of assignments. The beginning and ending of any group collaboration involve transition tasks such as assigning role, requesting changes to an agenda, and locating missing meeting participants. In the game, the success or failure of the group is related to the partial and global goals. It is shown in the obtained scores (partial and global scores). This indicator also should take into account the number of messages concerned with the reviewing mentioned above. It reflects interest in individual and collective performance. In our experiment, the more concerned the player is with the goals of the team, the more checks to the scores she will do, and the more messages of this kind she will send. CI3 is then computed with a 0-1 range, where 1 means the highest score in this indicator. 6.4 Monitoring This indicator is understood as a regulatory activity. The objective of this indicator is to oversee if the group maintains the chosen strategies to solve the problem, keeping focussed on the goals and the success criteria. If a player does not sustain the expected behavior, the group will not reach the common goal. In this sense, our fourth cooperation indicator (CI4) will be related to the number of coordination messages, where a small number of messages means good coordination (1 – (Coordination strategy messages)/(Coordination messages)). 6.5 Performance Baeza-Yates and Pino [2] made a proposal for the formal evaluation of collaborative work. They take into account three aspects: Quality (how good is the result of collaborative work), Time (total elapsed time while working) and Work (total amount of work done). So, in our experiment, Quality can be measured by three factors: few errors made by the group (related to the best score), achievement of the main goal (the group can solve the labyrinth) and few movements of the mouse (related to efficiency). The tool records the play-time since the first event (movement of the mouse or message sent by any player), until the group reaches the goal (cheese) or lose the game (a partial score goes down to zero). In this view, the “best” group does

Evaluating Collaborative Learning Processes

213

the work faster. Work is measured by the number of messages sent by group members. The performance indicator (CI5), will be the average of the three aspects mentioned above (Quality, Work, Time).

7 Experimental Design The experiment has four phases. The group receives a brief description of the software tool. During the second phase, group members are assigned to network workstations, in separate rooms (synchronous distributed interaction). From then on, all communication is mediated by computer. During the third phase, the group will try to solve the labyrinth. Finally, the fourth phase corresponds to the gathering and analysis of data recorded by the tool. We made also a final interview to the participants to foster a self-evaluation of the experience. This gave us a general overview of the problem perceived by each member of the team. So far, we have applied the experiment to eleven groups, as follows:

- A group of graduated students, from the course “Collaborative Systems” at Pontificia Universidad Católica de Chile, with some experience on collaborative work techniques (group 0). - A group of people, randomly selected, who have not met before and, of course, they have never worked together (group 3). - A group of friends who have worked as a group many times before the experience and have a good personal relationship (group 4). - Four groups of high school students from Cumbres de Santiago School, with an average age of 15 years old. Two of these were randomly selected (group 1 and 2) and the remaining ones were friends (group 5 and 6). - Four groups of graduate students from Universidad de Chile (Groups 7,8,9,10).

8 Results Analysis 8.1 Applying Strategies The objective is not only to show which group got the best or worst score, but to analyze each one of the elements that are part of this indicator and so, determine why some groups are better than others. Table 3 shows the results. From the collaborative work viewpoint, effective groups have goals which are 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. The results show us that groups are ineffective because communication was poor even though they have high “maintain strategy” scores. We can infer that members accept competitively structured imposed goals, so each member attempts to achieve her personal goal first.

214

C.A. Collazos et al. Table 3. Applying strategies results Group Solution 0 1 2 3 4 5 6 7 8 9 10

1 0 1 0 1 1 1 1 0 0 1

Use

Quality

1 0 1 1 1 1 1 0 0 0 0

0.62 0.5 0.95 0.52 0.87 0.74 0.56 0.5 0.4 0.4 0.5

Maintain Communicate 0.62 0.68 0.65 0.59 0.64 0.74 0.71 0.60 0.61 0.65 0.62

0.36 0.41 0.26 0.36 0.37 0.43 0.35 0.32 0.35 0.35 0.34

CI1 0.69 0.31 0.68 0.48 0.71 0.75 0.71 0.47 0.27 0.28 0.48

We could not find that conflicts of interest were solved through integrative negotiation and agreement, that is to say there is not a mediated process. It was common to observe that the first coordinator tried to impose her viewpoint and the rest of the group members simply followed her instructions. The initial imperative messages typically were: “Let’s label the columns with letters and the rows with numbers”, or “I will move first and then you are going to send me your coordinates”. It was not frequent to find messages that could induce to negotiate a position, like: “I propose that our strategy be... do you agree?” or “What do you think?” So, we can observe that the communication is not two-way and open with the possibility of expressing feelings as well as ideas. On the contrary, it usually was one-way, where only ideas were expressed and feelings were ignored. The group that got the best score was group 5 (CI1= 0.75), so, we could think that it is a good group in this aspect (applying strategies), but if we analyze in detail this indicator, we can infer this is a good work group, but not a good collaborative group. Group 5 is ineffective as collaborative group because the group could not build an effective communication method among members in spite of the best score in the maintenance aspect. In a collaborative activity, it is not only important to understand the problem, but to share that understanding among teammates, and this was Group 5 weakness. Compare this group with Group 8, which got the worst score (CI1=0.27), but it uses a better strategy (according to our quality metric) and it maintains it. Group 8 is one of the groups trying to promote some kind of discussion around the strategy definition; unfortunately, the final decision is imposed without a participatory negotiation. It was common to find groups that even after defining a strategy for the first quadrant, with some members of the group understanding that strategy, did not obtain a high score. The explanation lies in the lack of strategy understanding by some members of the group. We could observe, e.g., a group in which two of the members understood the strategy, and in fact during the first two quadrants the partial results were very good. The problem appeared in the third quadrant, because the corresponding coordinator –who had not fully understood the strategy– began to make some movements according to her viewpoint, and obviously the group could not solve the labyrinth. In this case, the members who understood the strategy did not care to make sure the rest of the group did also. So, it is not only important to understand the

Evaluating Collaborative Learning Processes

215

problem, but to be aware that the rest of the people can understand the problem situation during a collaborative learning activity. The team learning potential is maximized when all group members participate in the group discussions. Building involvement in group discussion increases the amount of information available to the group, enhancing group decision making and improving the participants’ quality of thought during the learning process [12]. For this reason, 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 behaved in this direction and therefore, one wonders if this aspect of learning is not spontaneous, at least in a first session of collaborative learning. 8.2 Intra-group Cooperation This indicator provides information about the application of collaborative strategies defined in Section 6.2. Table 4 shows the results. Table 4. Intra-group cooperation results Group

CI2

Group 0 Group 1 Group 2 Group 3 Group 4 Group 5 Group 6 Group 7 Group 8 Group 9 Group 10

0.69 0.71 0.62 0.61 0.74 0.84 0.72 0.80 0.75 0.75 0.80

Concerning this indicator, we can observe that almost all groups got a good score. These results show us there was an interest to solve the problematic situation among all members of the groups. It was common to observe that when someone asked information about something, the other members of the group were able to solve her doubts. Therefore, all questions –when asked– were solved by all group members. Analyzing and observing the members’ actions, we could find a dialogue pattern. When a participant requested help, at least she received one answer from the rest of the participants. It is important to note that these answers were timely. One of these patterns is shown below. Coordinator: Can I move to the right? Player 2: I don’t have obstacles. Player 3: I don’t have obstacles. Player 4: There is an obstacle in that position.

216

C.A. Collazos et al.

All the answers were given in a small time interval. Thus, the coordinator could infer what movement she could do and all participants are helping to solve the problematic situation. Members of the group who are not influenced by promotive interdependence engage in promotive interaction; they verbally promote each other’s understanding through support, help and encouragement [15]. In the experiments, it was common to observe that if a member of the group did not understand the answer to a question or solution to a problem, her teammates made special reinforcements, sending messages like: “Remember, you need to send me the location of your obstacles” or “You can not move”, to address her misunderstanding before the group moves on. Ensuring that each member of the group receives the help she needs from her peers is key to promoting effective collaboration interaction. Thus, for our groups we can conclude all of them were good according to this indicator. 8.3 Success Criteria Review This indicator gives information about the interest of members to check their roles, performance, results in order to achieve the main goal. Table 5 shows the results. Table 5. Success criteria review results Group

CI3

Group 0 Group 1 Group 2 Group 3 Group 4 Group 5 Group 6 Group 7 Group 8 Group 9 Group 10

0.2 0.2 0.2 0.5 0.8 1 1 0.2 0.2 0.2 0.2

This indicator provides an understanding of the performance analysis the group did during the group activity. Group processing and performance analysis exists when groups discuss their progress, and decide which behaviors to continue or change [15]. So, it is necessary that people evaluate the previous results obtained in order to continue, evaluating individual and group activities, and provide feedback. It is necessary also members of the group take turns questioning, clarifying and rewarding their peers’ comments to ensure their own understanding of the team interpretation of the problem and the proposed solutions. “In periods of successful collaborative activity, students’ conversational turns build upon each other and the content contribute to the joint problem solving activity” [28]. Unfortunately, this did not happen with the analyzed groups.

Evaluating Collaborative Learning Processes

217

If we look at the results, we could infer there were some groups who had a perfect performance in this indicator (groups 5, 6). However, if we observe in detail the objective of this indicator, and observe the group logs, we can conclude that this aspect was not fulfilled as we would like. The results we got are relative scores, that is to say, according to the analyzed groups, the best group were 5 and 6, but that does not mean they are good groups. According to this indicator, it only reflects we need to do additional experiments in order to determine the “ideal group”, and according to that group make relative comparisons. The groups with the best score were groups that reviewed the partial and total score during the process of collaborative activity, but rarely or never, were interested to evaluate the results obtained in order to re-define the next movements, or to provide some feedback to the members of the group. It was unusual to find messages like: “We are losing, our score is decreasing, so we need to define our next movement”. Only two groups (5, 6) had some messages like: “Our score has increased”, “We are losing”, but unfortunately, these groups did not stop to analyze their performance, to clarify issues and to define a new model of solving the problem situation. 8.4 Monitoring This indicator gives an understanding of how the group maintains the chosen strategies to solve the problem. Table 6 presents the results. They show that members of the groups are interested on being consistent about the strategy, so there is a direct relation between this indicator and the aspect of maintenance within Applying strategies indicator (e.g., the group that got the best CI4, got the best score in the maintenance part of CI1). Also, it should be noted that the groups which best scored in this aspect were the ones having a history of working together for some time, so they had good internal relationships. The numerical values for this indicator should be taken with caution, because they are not absolute values; they just serve to compare groups, they are comparative. In cooperative learning groups, members are required to acquire group skills, like how to provide effective leadership, decision-making, trust-building, communication and conflict-management [15]. The combination of knowing how to manage intellectual disagreements and how to negotiate/mediate conflicts among participants’ wants, needs, and goals ensures that the power of cooperative efforts will be maximized. The productivity of groups increases dramatically when members are skilled in how to manage conflicts constructively. Some groups participating in the experiment had worked together before, but still had the characteristics of “work groups” and were not collaborative groups. It was common to find, according to the analysis of the messages, that leadership was delegated and based upon authority, participation was unequal with high powered members dominating. These characteristics are typical of ineffective collaborative groups [20]. The same analysis gave us an understanding of the role of the coordinator in every quadrant. Its function should have been to contribute to maintain the harmony within group, avoiding negative discussions or conflicts, and promoting creative conflicts. Cooperation and conflict go hand-in-hand [16]. The more group members care about achieving the group goals, and the more they care about each other, the more likely they are to have conflicts with each other. The way conflict is managed largely determines how successful

218

C.A. Collazos et al.

cooperative efforts tend to be. For this reason, we can conclude that our groups still functioned as work groups. They had not acquired the collaborative status yet. Table 6. Monitoring results Group

CI4

Group 0 Group 1 Group 2 Group 3 Group 4 Group 5 Group 6 Group 7 Group 8 Group 9 Group 10

0.75 0.80 0.80 0.74 0.78 0.86 0.85 0.80 0.82 0.81 0.83

8.5 Performance Our last indicator provides an understanding of the fulfillment of the group. It provides an evaluation estimate of the groups’ outcome, according to its definition in Section 6.5. Notice that the groups which got the worst score were the groups that almost got the best score for the other indicators (see Table 7). That observation provides a hint that the task performance of a group is not related with its learning.

9 Conclusions and Further Work Understanding group dynamics and the collaborative process of decision making and learning in groups are both interesting research fields and the basis for new tools to support the findings. In the case of collaborative activities, performing well a task implies not only having the skills to execute the task, but also collaborating well with teammates to do it. In this paper we have presented a software tool allowing us to make experiments on the subject of collaborative work. We could gather information on them in order to evaluate the cooperation processes occurring in the group work. For their evaluation we proposed five cooperation indicators. We do not claim these are the only or best indicators that could be developed to this end. These indicators are not independent either; e.g., there is a relationship between the monitoring indicator and the maintenance of the strategy, and another one between intra-group cooperation and communication of the strategy. The important conclusion is that these five indicators did provide some insight on the collaborative work done by the groups. They can be used to detect group weaknesses in their collaborative learning process. The analysis of the results suggests the shared construction of a strategy to fulfill a group work –understood and adopted by every member of the group– is related to a

Evaluating Collaborative Learning Processes

219

Table 7. Performance results Group

Quality

Time

Work

CI5

0 1 2 3 4 5 6 7 8 9 10

0.87 0.5 0.95 0.52 0.62 0.74 0.56 0.5 0.4 0.4 0.5

0.86 0.82 0.99 0.67 0.42 0.83 0.81 0.87 0.81 0.82 0.78

0.22 0.4 0.13 0.72 0.95 0.27 0.19 0.23 0.4 0.4 0.3

0.65 0.57 0.69 0.63 0.66 0.61 0.52 0.53 0.54 0.54 0.53

successful process, to the individual construction of cognitive context, and to the experiences shared by the group members. Also, it enhances the elaboration process of strategies and facilitates its application. This fact is reflected in the performed language utterances: those are homogeneous, direct and unambiguous when referred to the common problem features. The studied groups were ineffective collaborative groups because they were weak in collaborative attitudes. Students have two responsibilities in cooperative learning situations, according to Johnson & Johnson: 1) learn the assigned material, and 2) ensure that all members of the group learn the assigned material [14]. The second aspect is something that never occurred during the collaborative learning processes of our groups. Of course, nobody told the group members they should have a collaborative attitude. Many hypothesis can be developed to explain why these attitudes did not appear spontaneously: perhaps the students initially thought the game was very easy, or maybe they felt pressured to play instead of stopping to think carefully what to do, etc. One could guess that a reduced number of work messages would imply a better coordination within the group and thus, one would find few coordination messages. This would occur because many messages would have an effect of cognitive overload, disturbances, etc. Our results support this relationship of number of work messages with number of coordination messages. However, again, well coordinated groups are not necessarily collaborative groups. It is also important to note that the cooperative work processes are influenced by the personal style and individual behavior of every member of the group. In our groups, it can be observed stability in the performance of the tasks accomplished by each of the group members, in both role types: coordinator and participant. This stability is also observed in the personal styles and communication styles. Further work is needed to study the influence of many variables we did not isolate in this experimentation. Such variables may be: genre (whether or not this factor has an effect on the results), age, culture, homogeneous vs. heterogeneous groups concerning the previous variables, etc. Other experiments could also be made changing the game. One of these changes may be allowing broadcast messages, or

220

C.A. Collazos et al.

allowing the group to slightly modify the rules of the game (e.g., forcing the coordinator to receive all messages from members before enabling moves).

Acknowledgments. This work was supported by grant No. 1000870 from Fondecyt (Chile), by the Scholarship for Doctoral Thesis Completion from Fondecyt (Chile) and by grant No. I-015-99/2 from Dirección de Investigación y Desarrollo (DID), Universidad de Chile.

References 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.

Adams, D. and Hamm, M.: Cooperative Learning, Critical Thinking and Collaboration Across The Curriculum. Second Edition, Charles Thomas Publisher, 1996. Baeza-Yates, R. and Pino, J. A.: A First Step to Formally Evaluate Collaborative Work. Int. Conf. GROUP’97, Phoenix, AZ, USA, pp. 55-60, Nov. 1997. Barros, B. and Verdejo, M. F.: An Approach to Analyze Collaboration when Shared Structured Workspaces are Use for Carrying Out Group Learning Processes. Proc. of the Int. Conf. AI-ED’99, Lajoie, S. P. and Vivet, M. (editors), pp. 449-456, 1999. Brna P. and Burton M.: Roles, Goals and Effective Collaboration. Proc. of the IV Collaborative Learning Workshop in the Int. Conf. AI-ED’97, Kobe, Japan, 1997. Constantino-González M., Suthers, D., Coaching Web-based Collaborative Learning based on Problem Solution Differences and Participation. Proc. of the Int. Conf. AI-ED 2001, J. D. Moore, C.L. Redfield & W. Lewis Johnson, Eds., IOS Press, pp.176-187, 2001. Deutsch, M.: Cooperation and trust: Some theoretical notes. In M. Jones (Ed.) Nebraska Symposium on Motivation (pp.275-320). Lincoln: University of Nebraska Press, 1962. Dillenbourg, P., Baker, M., Blake, A. and O’Malley, C.: The Evolution of Research on Collaborative Learning. Spada & Reimann (eds), Learning in Humans and Machines, 1995. Drury, J., Hirschman, L., Kurtz, J., Fanderclai, T., Damianos, L., Linton, F.: Methodology for Evaluation of Collaboration Systems, 1999, http://zing.ncsl.nist.gov/nist-icv/documents/methodv4.htm Fussell, S., Kraut, R., Lerch, F., Scherlis, W., McNally, M. and Cadiz, J.: Coordination, Overload and Team Performance: Effects of Team Communication Strategies. Proceedings of CSCW'98, Seattle, Washington, USA, 1998. Guerrero, L., Alarcón, R., Collazos, C., Pino, J & Fuller, D.: Evaluating Cooperation in Group Work. Proc. of the CRIWG’2000. Madeira, Portugal, 28-35, IEEE Computer Science Society Press, Los Alamitos, CA, 2000. Inaba, A. and Okamoto, T.: The Intelligent Discussion Coordinating System for Effective Collaborative Learning. Proc. of the IV Collaborative Learning Workshop in the Int. Conf. AI-ED’97, Kobe, Japan, 1997. 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. Johnson, D., Johnson, R.: Learning Together and Alone, Cooperation, Competition and Individualization. Prentice Hall Inc. Englewood Cliffs, New Jersey, 1975. Johnson, D., Johnson, R.: Cooperative, competitive, and individualistic learning. Journal of Research and Development in Education, Vol. 12,p.p. 8 –15, 1978. Johnson, D., Johnson, R., Holubec, E.: Circles of learning: Cooperation in the classroom rd (3 ed.), Edina, MN: Interaction Book Company, 1990.

Evaluating Collaborative Learning Processes rd

221

16. Johnson, D., Johnson, R.: My mediation notebook (3 ed.), Edina, MN: Interaction Book Company, 1995. 17. Kagan, S.: The Structural Approach to Cooperative Learning. Educational Leadership, Vol.47, No.4, pp.12-15, 1990. 18. Katz, S. The Cognitive Skill of Coaching Collaboration. Proceedings CSCL’99, Hoadley & J. Roschelle (Eds.) Dec. 12-15, Stanford University, Palo Alto, California. Mahwah, NJ: Lawrence Erlbaum Associates, 1999. 19. Linn, M.C., Clancy, M.J.: The Case for Case Studies of Programming Problems. Communications of the ACM, Vol. 35,No. 3, pp. 121-132, 1992. 20. Morrison, T.: Actionable Learning: A handbook for capacity building through case based learning. Asian Development Bank Institute, 2001. 21. 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. 22. Roschelle, J., Teasley, S.: The construction of shared knowledge in collaborative problem solving. In C. O’Malley (eds.), CSCL’91, pp. 67-97, Berlin, Germany: Springer, 1991. 23. Soller, A., and Lesgold, A.: Modeling the process of collaborative learning. Proc. of the Int. Workshop on New Technologies in Collaborative Learning, Awaji-Yumetabi, Japan, 2000. 24. Soller, A., and Lesgold, A.: Knowledge Acquisition for Adaptive Collaborative Learning Environments. AAAI Fall Symposium: Learning How to Do Things, Cape Cod, MA, 2000. 25. Sharan, Y. and Sharan, S.: Group Investigation Expands Cooperative Learning. Educational Leadership, Vol.47, No.4, pp.17-21, 1990. 26. Slavin, R., Madden, N. and Stevens, R.: Cooperative Learning Models for the 3 R's. Educational Leadership. Vol. 47, No.4, pp.22-28, 1990. 27. Slavin, R.: Synthesis of Research on Cooperative Learning. Educational Leadership, Vol.48, No.5, pp.71-82, 1991. 28. 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, pp. 102-119. NY: Cambridge University Press, 1992.

The CSCW Lab for Groupware Evaluation 1*

2**

3

Renata Mendes de Araujo , Flavia M. Santoro , and Marcos R.S. Borges 1

Departamento de Ciências da Computação/UFRJ and UNIRIO Caixa Postal 2324, Rio de Janeiro, 20001-970, RJ, Brasil [email protected] 2 Departamento de Ciências da Computação/UFRJ [email protected] 3

Departamento de Ciências da Computação and NCE/UFRJ [email protected]

Abstract. The aim of this paper is to report the initiative of a research project called the CSCW Lab. The CSCW Lab is an approach for applying evaluation methodologies in the context of a groupware research group. We identify the major dimensions of groupware evaluation and describe how the CSCW Lab addresses them. The first experiments using CSCW Lab are also described.

1 Introduction Groupware evaluation is becoming a relevant research issue. The research area came to a point where there have been a lot of proposals and solutions. Now, the great challenge is to be aware of how effective are these solutions in real situations. The claim for groupware evaluation can be observed by the number of papers and research reports addressing this issue and by the recent workshops totally devoted to this theme [3][4]. We are very far from consensus about how groupware evaluation should be conducted although we see some initial results for building its “body of knowledge” [1][2][3][4][5][6][7]. Within the context of our research group – CHORD – many tools and prototypes have been specified and developed as the result of undergraduate, master and doctoral work [13]. The main difficulty faced by our research group is how to accomplish the evaluation of these tools and prototypes in order to verify if they answer the hypotheses outlined at the beginning of the research work. What is the scope of the evaluation, how do we define variables to measure the results, which instruments should we apply, how do we choose participants and settle down the groups that will take part in the experiment, how far should we go to validate our hypotheses? In this work we present the CSCW Lab – an environment for the first-step evaluation of groupware prototypes. Besides an environment for evaluating our research _____________________________________________ * sponsored by FAPERJ (process #E-26/152.176/2000). ** sponsored by FAPERJ (process #E-26/152.116/2001).

J.M. Haake and J.A. Pino (Eds.): CRIWG 2002, LNCS 2440, pp. 222–231, 2002. © Springer-Verlag Berlin Heidelberg 2002

The CSCW Lab for Groupware Evaluation

223

products, the CSCW Lab is also a research project, since we intend to study existing methodologies applied to groupware evaluation as well as the definition of new methods, instruments and/or tools. CSCW Lab defines a method for groupware evaluation based on the dimensions for evaluation and the steps to investigate each dimension. This paper is structured as follows: in section 2 we present a summary of the major issues and approaches comprising groupware evaluation. In section 3 we identify and discuss the possible dimensions of groupware evaluation and how they influence each other. In section 4 we present the ideas concerning the CSCW Lab and how each dimension of evaluation could be addressed. In section 5 we illustrate the paper with some examples of evaluations conducted within the CSCW Lab. Finally, section 6 concludes the paper.

2 Groupware Evaluation: What Has Been Done? Many authors have been reporting problems with the development and use of groupware applications. Evaluation failures of CSCW systems may be partially responsible for slow adoption of such systems. The system performance may depend on the varied behavior and personalities of the group members, the effect of social, motivational, economic and political dynamics, and the relevance of time as a factor in understanding interaction changes. All these issues interfere in the way people use a groupware, making it difficult, or almost impossible, to identify and to obtain control over all variables related to it. Thus, groupware evaluation is expensive and produces few general results. Nevertheless, without the appropriate evaluation mechanisms, the developer’s community does not accumulate enough experience to learn and build better systems [8]. It is claimed that four important, but still opened, topics should be considered in this case: What do we want to evaluate? What methodological approach should be taken? What criteria should be used to achieve the results? What instruments should be used? There is no consensus on the methodology to be adopted in order to perform evaluations in groupware. Pinelle and Gutwin [2] present a survey on the most used evaluation methodologies, based on the works presented at the main conferences of the CSCW area. They classified the evaluations both in relation to the environment where they are accomplished (natural occurrence or simulation of the phenomenon), and the degree of the variables manipulation (rigorous or minimum control of variables) (Table 1). Their conclusion is that each work used different approaches, methodologies or techniques for conducting evaluations. Table 1. Evaluation Classifications [2]

Naturalistic

–

Controlled

–

Setting

Manipulation Rigorous Minimal/None Field Experiment – Field Study – Case Study Laboratory Experiment – Exploratory

224

R. Mendes de Araujo, F.M. Santoro, and M.R.S. Borges

Randall et al. [9] had also identified four orthogonal dimensions to classify the kinds of evaluation in groupware: Summative X Formative; Quantitative X Qualitative; Controlled Experiments X Ethnographic Observations; Formal and rigorous X Informal and opportunistic. The authors state that the most used types of evaluations are the summativecontrolled and experimental (considered a formal technique); and the formativequalitative-opportunistic approaches (considered an informal technique). Concerning the criteria for evaluating groupware, Baker et al. [8] proposed to analyze groupware through appropriate heuristics, which Nielsen, from the HCI (Human-Computer Interaction) area, defines as “general rules used to describe common properties of usable interfaces”. The heuristics are related to communication (verbal, gesture, body, shared artifacts), protection, activities and collaboration management and contact establishment. Some other works are more concerned with quantitative matters, such as BaezaYates and Pino’s [10], who concentrate on the relationships among issues like the quality of a work outcome, the time spent on it and the total amount of work done. Monk et al.[11] state that measures based on task performance – for instance, how well or quickly the work is completed - are only sensitive to gross changes in the facilities available for communication. They assume that looking directly at the effect of a manipulation on communication, rather than indirectly via the effect that communication has on the work, the effects observed will be clearer and easier to detect and the results will be easier to interpret, leading to a better understanding and hence more generalizable findings. Steves and Allen [12] point out some other important issues related to groupware evaluation: a better evaluation will be supported by improved data collection, data formats, data categorization and data visualization tools; researchers cannot control all independent variables, and do not usually relate how they were handled in a case study documentation, that is, the analysis of data collection is typically labor intensive. Knutilla, Steves and Allen [3] asserts that researchers need tools to measure the incremental progress towards developing useful collaborative systems, as well as methods to evaluate the impact of specific technologies on collaboration. Additionally, the ultimate goal of any evaluation is to validate some theory. The obstacles found in a groupware evaluation process makes it very hard to achieve, if we consider the straight meaning of validation. Therefore, Randall et al. [9] suggest that validation cannot be done in practice, but a provisional status should be accepted. For these authors, evaluations should focus on potential changes in human practice as well as machine functionality, and on the relationship between them. Considering this variety of ideas, suggestions and approaches for groupware evaluation, the main objective of the CSCW Lab is to define a method for groupware evaluation comprising the steps for conducting the evaluation and guidelines for using any technique and instruments.

3 Dimensions of Groupware Evaluation The first issue addressed in the CSCW Lab in order to define a method for groupware evaluation is to identify the concepts or dimensions that must be considered while evaluating groupware. We identify four dimensions for groupware evaluation (Fig. 1).

The CSCW Lab for Groupware Evaluation

225

These dimensions are a first step towards building a conceptual framework for our studies in the CSCW Lab. The conceptual framework considers that while evaluating groupware we may be addressing how to: evaluate and describe the context where the application under evaluation will be used; evaluate the application usability strengths and weakness; evaluate the level of collaboration achieved while using the application; and evaluate the technological and cultural impact achieved with its use along the time. Group Context

Usability

Influences

Collaboration

Change

Cultural Impact Fig. 1. Dimensions for groupware evaluation

Group context. It is a consensus in groupware evaluation research that groups are quite unique. Even if we try hard, it is almost impossible to find two groups with the same values to conform to our independent variables. Often we cannot find de “ideal” group to conduct our evaluations. To find or to build groups for evaluation is difficult and costly. In groupware evaluation we must care about group diversity. While conducting evaluations, we should target on: comparing results from different groups, collecting empirical or statistical evidence on the effectiveness of a new technology or just observing a unique case on the field. In any case, we must look into the many different outcomes when supporting collaboration for different groups. To study the effects on diversity, a sharp characterization of the observed group is essential for the interpretation and discussion of any evaluation result. Also, our framework considers that the singularities of the group context can influence all other evaluation dimensions. For instance, if a group is initially highly committed to perform a task, it is possible that they overcome any usability problems with the application in use. It is also possible that the level of collaboration will be high, since they are willing to work together and, finally, it is also possible that the tool will have a positive impact in the work or interaction environment. System usability. The next dimension is evaluating usability. It is widely known that the level of usability of an application determines its proper use and also its acceptance by users. Evaluating groupware usability is a complex task since it

226

R. Mendes de Araujo, F.M. Santoro, and M.R.S. Borges

involves not only the evaluation of how a user can use the tool but also if the group can interact as expected using the tool [15][16]. Level of collaboration. Collaboration may occur at many levels and depends a lot on the nature and objectives of the group task. To evaluate collaboration it is first necessary to determine what are the measures or variables that determine how people collaborate. For instance, in a discussion forum, one possibility to measure collaboration is to count the number of contributions generated by the group. However, collaboration in a forum is only effective if contributions are not only inserted but also read by other participants [17]. Measuring collaboration also involves subjective metrics. Usually, people can feel if the members of the group they take part in collaborate with each other. By introducing instruments such as questionnaires or direct observation, evaluators can be aware of participants’ satisfaction and have an indication about the collaboration that occurs among group members. Cultural Impact. The technology may have completely different use in different contexts. The final dimension of group evaluation is how a groupware tool transforms: the way the members of a group work, the way the group work as an unit, what are the expected and unexpected ways the tool is used by the group and also how the organization or group incorporate or recognize the new tool introduced into their working culture. Based on our previous evaluations, we observed that these four dimensions have a close relationship with each other in terms of their evaluation. For instance, depending on the group characteristics (its context), the reaction of using a specific tool can be quite different. Groups that are highly committed to an activity may try to overcome any usability problems that exist in the supporting tool. If the majority of people working in a group consist of optimistic persons, there is a tendency for the tool being used to have a positive cultural impact. If a tool has too many usability problems, collaboration may be completely compromised. If a high level of collaboration is achieved through the use of a groupware tool, the cultural impacts can be of greater dimension. Additionally, evaluations should consider that the cultural impact (positive or negative) of the use of a groupware tool might change the group context (aims, expectative, attitudes), the way it is used and how people collaborate with each other.

4 The CSCW Lab The CSCW Lab is an attempt to define a laboratory for groupware evaluation. By a laboratory we mean an environment where a methodology, including guidelines and instruments, are available for conducting groupware evaluation. Groupware evaluation involves a great amount of efforts. The planning, design, accomplishment and replication of an evaluation are costly activities. The design of an evaluation is an activity that should be carefully performed in order to guarantee that the results and measures are relevant for interpretation. It is important that some evaluations should be conducted previously from real evaluations with the groups or organization where the tool will be used [1]. This first

The CSCW Lab for Groupware Evaluation

227

evaluation stage – that we call “pilot-evaluation” – is important to tune the evaluation design and to outline the first general impressions, problems and benefits of the artifact been evaluated. The results are also relevant for identifying major usability problems in the developed tools before putting it to work in real settings. The main objective of the CSCW Lab is to support the design and the conduction of pilot-evaluations. Each dimension described in the previous section can be considered as the subsequent steps of a method for conducting groupware pilotevaluations: Group context. The characterization of the groups to be observed is the first issue to be discussed. What are the essential group characteristics that must be collected before conducting the evaluation and that will be relevant to further understand the evaluation results? What are the guidelines for describing a group? How can we evaluate that a specific group is appropriate for our study? What are the group expectations with the use of the groupware tool? How these characteristics change from one domain to another? Group context characterization is a dimension that relies heavily on psychology, sociology and ethnographic studies. It is an objective of CSCW Lab to work collaboratively with researchers from these domains in order to define techniques and instruments for characterizing group contexts. Usability. Usability is the next dimension to be evaluated. Groupware usability is being widely discussed and some approaches and techniques for its evaluation have been proposed [15][16]. Usability evaluation techniques for single-user applications have been adapted to the evaluation of collaborative applications. In CSCW Lab, we aim at collecting, using and evaluating these suggested techniques as instruments for assessing the usability of the applications. Usability has a strong relation to interface design and research. Some initial collaboration with other research groups [14] in this area has been settled to combine investigations on this theme. Level of Collaboration. When we design and construct a groupware tool, our aim is to support and to promote collaboration. If we cannot determine if this collaboration really occurred, the tool looses its relevance and cannot be validated. Although we may not disregard the other dimensions of groupware evaluation, since they influence each other, collaboration evaluation is the main focus of groupware research. To address this issue in the CSCW Lab, we define what we call Collaboration Maturity Models. Similarly to what has been defined in software engineering domain [18], we believe that it is possible to describe a set of collaboration levels a group can achieve and what are the characteristics of each level. Two models for evaluating the level of collaboration have already been developed in the context of the research group [19][20] providing resources for establishing other models for other domains. Cultural Impact. After characterizing the group, evaluating the tool usability and the level of collaboration achieved by group members, we are able to evaluate its cultural impact. In CSCW Lab, we assume that cultural impact evaluation must consider the following levels: the individual level, the group level and the organizational level. In all these levels, it is possible to measure impressions, perceptions, satisfaction, commitment, learning and change of attitudes among other impact indicators.

228

R. Mendes de Araujo, F.M. Santoro, and M.R.S. Borges

Another objective of the CSCW Lab is to collect, organize and store data about the design and results of the evaluations conducted in the Lab. This data can be used as a source for analyzing the evaluation results as also to reuse the evaluation design specifications.

5 Experiences in the CSCW Lab In this section we described the first set for experiments conducted in the CSCW Lab. These experiments where conducted as an attempt to validate the products of two doctoral research works of CHORD group in the domains of software development and collaborative learning. Our objective in this section is to show how the dimensions of CSCW Lab can be followed as evaluation steps according to each specific evaluation objective. PIEnvironment evaluations. One group of evaluations was accomplished in the context of the use of workflow systems and awareness mechanisms for software process learning and improvement. An environment, named PIEnvironment, was built as an extension of a commercial workflow system in order to provide information about the collaboration that occurred within a defined process being executed through the workflow system. A description of the environment and its complete experiment design and results can be found in [21]. The environment was conceived in order to help software process participants to: follow and perform their tasks, be aware of the process they execute; learn about the process, and participate suggesting process improvement opportunities. The basic hypothesis of PIEnvironment was that process visualization and learning could change the culture of software development, enforcing the collaboration that exists within it. The attempt of the pilot-evaluations, in this case, was to observe the potential of PIEnvironment in providing awareness, knowledge and consciousness to process participants about their work, and whether they felt satisfied and in favor of the idea of using a defined process. In order to accomplish this objective of PIEnvironment evaluations, each of the dimensions of the CSCW Lab were defined: – Group context: to evaluate the levels of awareness, consciousness and knowledge about the process they execute, it should be important to consider, for instance: the previous experiences of the participants with software development, their knowledge and practice about using defined processes, their practice and satisfaction with process definition and improvement initiatives and so on. Subjective measures about group context should also consider, for instance, the group commitment to the task and to the evaluation process. – Usability: usability was not the main focus of PIEnvironment evaluations at this time. We addressed this dimension by allowing participants to report any problems and causes of insatisfaction they encountered during process enactment, reflecting interface and/or usability troubles. – Level of collaboration: PIEnvironment was conceived to make collaboration more visible and, consequently, to enforce it. To evaluate if the environment was

The CSCW Lab for Groupware Evaluation

–

229

able to turn participants aware of the collaboration they took part was our first attempt at this time. Measuring how collaboration was enforced within the group was subjective, using the questionnaires to let participants report their feelings about how collaboration occurred and if they felt satisfied with it. Cultural impact: this could be considered the main objective of PIEnvironment evaluations – to evaluate how the awareness of the process and the collaboration provided by the environment helped participants to be more receptive to idea of following defined processes. To measure this level of individual cultural impact, we defined subjective questions in the questionnaire where participants could report if they felt satisfied with the overall process enactment and about how they suppose to use defined processes in the future.

COPLE evaluations. Another group of evaluations aimed at validating a conceptual model for collaborative project-based learning [20]. For this purpose, COPLE (Cooperative Project-Based Learning Environment) was implemented. This educational groupware presents an approach where teachers and students should define their work process, it means, the stages, the tasks and relationship among them, identifying the best ways to interact and to integrate individual solutions in order to accomplish a collaborative project. Our hypothesis is that collaboration enhances learning, thus it is necessary to enhance collaboration. Therefore, the goal was to observe if the process design helped to stimulate collaboration within the group. A methodological set, including a series of criteria was defined to evaluate collaboration. In the sense of the four dimensions stated in the CSCW Lab Project, we can discuss the following subjects: – Group context: It was very important to understand the personal characteristics of the public who used the environment, since we were in real case situation, and the cultural issues could interfere in the results obtained. We had two groups, working for a pos-graduate course, thus the background of each participant was also relevant in terms of the contributions to the final product made by the group. We observed that the personal commitment and availability of each member are the most determinant factors to the success of the project. – Usability: Although we recognize this dimension to be a fundamental basis for any groupware evaluation, we did not attained very much on it this time. In the questionnaires we used to inquire students about their work, we just tried to raise the HCI problems that could possibly had influence on the way students developed their projects. – Level of Collaboration: Evaluating the level of collaboration was the focus of this research. Therefore, we defined a set of criteria concerned to the following issues: Communication, Contributions for collective knowledge building, Coordination and Awareness. These criteria combined quantitative and qualitative measure units due to the nature of the collaborative process. – Cultural Impact: In this case, to measure cultural impacts means to verify if the kind of work proposed brings a new perspective on the way apprentices and teachers view learning-teaching process. It would be necessary to go on using it in real situations with diverse teachers and students’ groups, while reflecting the observations made by each study in new functionalities for the COPLE environment. That is what we intend to do within CSCW Lab project due to our goal to establish a methodological approach for groupware evaluations.

230

R. Mendes de Araujo, F.M. Santoro, and M.R.S. Borges

6 Conclusions This paper presented our ideas concerning the CSCW Lab. The CSCW Lab is an initiative to organize and address the main issue of evaluating the groupware products developed within a research group. The paper identifies from the literature what are the main dimensions of groupware evaluation and how they are addressed in the Lab as steps for an evaluation method. Additionally, some experiments already conducted following CSCW Lab method are described. From the evaluations conducted within CSCW Lab, we can conclude that the first step for designing groupware evaluations is to properly identify which of the dimensions are to be evaluated during the experiments depending on the research hypothesis. Next, each dimension must be defined in terms of the necessary variables to be set and how to measure them using specific techniques. To accomplish this definition, the CSCW Lab aim at providing guidelines, variables, models and instruments specific for groupware evaluation As we can observe from the examples of evaluations conducted in CSCW Lab, they had very different targets and consequently, different aims and dimensions definitions. Another goal of the CSCW Lab is to define guidelines for helping researchers to map evaluation objectives to evaluation variables and techniques. Other set of evaluations are now being planned in the context of our research group following the CSCW Lab method. Each of them will help us to continuously detail the method steps and techniques. Finally, there are special issues that we would like to deeply address in CSCW Lab. Among them is the dimension of the collaboration level achieved using groupware by the definition of the collaboration maturity models. Additionally, we intuitively observed that there are strong relations between group commitment, tool usability and the level of collaboration achieved. Thus, we aim to continue to study this special relation in our experiments within CSCW Lab.

References [1] [2] [3]

[4]

Pinelle, D. 2000 A Survey of Groupware Evaluations in CSCW Proceedings. Research Report 00-1, Computer Science Department, University of Saskatchewan. Pinelle, D., and Gutwin, C., 2000, “A Review of Groupware Evaluations”, Proceedings of Ninth IEEE WETICE 2000 Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, Gaithersburg, Maryland, June. Knutilla, A.J., Steves, M.P., Allen, R.H., 2000, Workshop on Evaluating Collaborative th Enterprises 2000 – Workshop Report, as part of the 9 Int. Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, June, National Institute of Standards and Technology, USA. (report available at: www.mel.nist.gov/msidlibrary/doc/steves00a.pdf) Steves, M.P., Allen, R.H., 2001, Evaluating Collaborative Enterprises – A Workshop th Report, as part of the 10 Int. Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, June, MIT, Cambridge, MA, USA. (available at: www.mel.nist.gov/msidlibrary/doc/steves01b.pdf)

The CSCW Lab for Groupware Evaluation [5]

[6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]

[21]

231

McGrath, J.E., “Methodology Matters: Doing Research in the Behavioral and Social nd Sciences”. In: Readings in Human-Computer Interaction: Toward the Year 2000, 2 Ed. Baeker, R.M., Grudin, J., Buxton, W.A.S., Greenberg, S. (eds.), Morgan Kaufman Publishers, San Francisco, 1995, 152-169. Ramage, M., Twidale, M., Sommerville, I., Evaluation of Cooperative Systems Project, (http://www.comp.lancs.ac.uk/computing/research/cseg/projects/evaluation/) Dennis, A., Valacich, J.S., 2001, “Conducting Research in Information Systems”, Communications of the Association for Information Systems, Vol. 7, Article 5, July. Baker, K., Greenberg, S., Gutwin, S., 2001, “Heuristic Evaluation of Groupware Based on the Mechanics of Collaboration”. In: Proceedings of the 8th IFIP Working Conference on Engineering for Human-Computer Interaction (EHCI´01), Toronto, Canadá. Randall, D., Twidale, M., Bentley, R., 1996, “Dealing with Uncertainty- Perspectives on the Evaluation Process”. In: Thomas, P.J. (ed.), CSCW Requirements and Evaluation, Springer. Baeza-Yates, R., Pino, J.A., 1997, “A First Step to Formally Evaluate Collaborative Work”. In Proceedings of Group 97, Phoenix, USA. Monk, A., McCarthy, J., Watts, L., Daly-Jones, O., 1996, “Measures of Process”. In: Thomas, P.J. (ed.), CSCW Requirements and Evaluation, Berlin, Springer. Steves, M.P., Allen, R.H. (2001) Evaluating Collaborative Enterprises – A Workshop Report. WETICE’2001. CHORD Group – www.chord.nce.ufrj.br Semiotic Engineering Research Group (SERG) – www.serg.inf.puc-rio.br Baker, K., Greenberg, S., Gutwin, C., 2001, “Heuristic Evaluation of Groupware Based on the Mechanics of Collaboration”, Proc. of the 8th IFIP Working Conference on Engineering for Human-Computer Interaction, ECHI'01, May 11-13, Toronto, Canada. Prates, R.O, Souza, C.S., Assis, P.S., “Categorizing communicability evaluation breakdowns in groupware applications”, CHI-SA 2001, Pretoria, South Africa. Borges, M.R.S., Pino, J.A., 1999, “Awareness Mechanisms for Coordination in Asynchronous CSCW”. In: Proceedings of the 9th Workshop on Information Technology and Systems (WITS’99), Charlotte, North Carolina, EUA, Dec. Paulk, M.C. et al, 1993, Capability Maturity Model for Software, version 1.1. CMU/SEI93-TR-24, Carnegie Mellon University, Software Engineering Institute, Pittsburgh, Pennsylvania, Feb. Santoro, F.M. , 2001, A Cooperation Model for Project-Based Learning. Doctoral Thesis. COPPE Sistemas, UFRJ, Rio de Janeiro, Brazil. (in Portuguese). Borges, M.R.S., Pino, J.A., 2000. “Information Technology in Latin America: Two Decades of Collaboration”, Information Technology for Development, V 9 N 3-4, p. 189204 Araujo, R.M., Borges, M.R.S., 2001. Extending the Software Process Culture – An Approach Based on Groupware and Workflow. In: Proceedings of the Third International Conference on Product Focused Software Process Improvement PROFES’2001, Kaiserlautern, Germany, September, p. 297-310.

Tailoring Group Work 1

2

3

Alejandro Fernández , Jörg M. Haake , and Adele Goldberg 1

Fraunhofer Integrated Publication and Information Systems Institute (IPSI). Dolivstr. 15, D-64293 Darmstadt,Germany [email protected] 2 FernUniversität-Gesamthochschule Hagen, Computer Science VI – Distributed Systems, Informatikzentrum, Universitaetsstr. 1, D-58084 Hagen, Germany [email protected] 3 Neometron Inc. USA [email protected]

Abstract. The success of groupware lies partially with its design. Welldesigned groupware will still fail to meet its users’ expectations if those users do not feel empowered by its use. Providing groups of users with the means of tailoring groupware in the wider context of group work may be the answer. This paper introduces our vision for tailoring group work, clarifies the principles underlying tailoring group work, and lays out the research approach we are currently taking, in expectation of stimulating interest in this challenging area.

1 Introduction Our interest in groupware stems from our interest in understanding group dynamics. Our motivation is simple: we manage groups of researchers and software engineers who need to work purposively—to create a desired outcome, and effectively—to create that outcome within some understood criteria for success. Groupware is software; it is also the intentional processes that a group uses and that therefore frame the use of the software. As software, groupware can be as simple as a calendar for coordinating the physical availability of group members, or as complex as an online community that explicitly directs a member’s access to information, the context for carrying out work related actions, and the ability to share issues and results. The success of groupware lies partially with its design—function as well as form, but only partially. Well-designed groupware will still fail to meet its users’ expectations if those users do not feel empowered by its use. If using groupware becomes the end goal rather than the means to the end goal, i.e., creating the desired outcome, then users will either ignore or begrudge its use. Take the following story as an example of the problem. The context is a research and development group whose 17 members represent multiple disciplines—psychology, computer science, and education. At some point, the manager of the group solved a frustration with the inability to schedule meetings and resources by instituting a group calendar. The only information represented in the calendar was dates when each person would be physically absent from the shared offices. Either the person will be on vacation, J.M. Haake and J.A. Pino (Eds.): CRIWG 2002, LNCS 2440, pp. 232–242, 2002. © Springer-Verlag Berlin Heidelberg 2002

Tailoring Group Work

233

at a conference, on a business trip, or working at home. Why they were absent was not made explicit. The calendar was implemented as a shared html file containing a table with entries for each day that at least one member would be out of the office. Each member was expected to maintain his or her personal information. The calendar fell into disuse. As the group’s membership changed since the calendar was made available, not everyone remembers why it was created. Not everyone shared a belief that knowing the physical whereabouts of the others was a problem requiring solution. Except the group manager, who raised the need to maintain the calendar at one of the weekly group meetings. Rather than impose the requirement, though, the group was asked to vote. The results were predictable—the task seemed easy enough, no one questioned why they stopped doing it, and so the decision was made to restart. In reality, only a few months after the calendar was first adopted, group members realized that the information was not always consistently correct. Some people assumed the calendar was no longer in use (although no decision to abandon it was ever announced), while others kept supplying information despite uncertainty of its value. After time, some people simply forgot where to find it. The calendar was neither used nor trusted. Coordination was handled by other means. At the time of the group vote to try again, this history was not questioned. The calendar as an effective tool for this group appears doomed. The group itself does not see the calendar as a solution to a problem that all group members recognize. There was no group member participation in understanding the problem from each member’s point of view, and no effort to propose alternative solutions (to propose, for example, either a different form for the calendar or a more accessible location for the shared tool). Moreover, as in the first decision to use a calendar, there was no decision to monitor or perhaps host its use, to elicit better trust that the information is consistently accurate and timely. Recently, our interest in this situation apparently motivated the group to discuss the problem solved by a calendar. Awareness of the problem led to a group evaluation and decision to adapt the tool for easier access. The group is now tracking the calendar use out of an interest in whether such information impacts the members’ ability to coordinate activities. Ultimately, this simple story is the story of a group tailoring its own groupware through explicit discussion about how the group can work together to improve its own work context. The success of groupware is intimately linked to its flexible use—both how the software is incorporated within the social dynamics of a group, and how the software can be customized to better fit that social dynamics. The latter has been the primary focus of most research work regarding groupware, and takes the form of the design of adaptable software (software that can be changed either through parameterization and therefore user choice of form or function, customization so that users can add visual interfaces or function, or protocol specification to support integration with other software). Our interest, and the topic of this paper, is the former as understood to be support for how a group recognizes and can enhance its own social dynamics through selection and modification of groupware. Our specific work is motivated by a belief that tailoring groupware really means tailoring the context in which the group works, and fitting groupware appropriately

234

A. Fernández, J.M. Haake, and A. Goldberg

into that context. Tailoring groupware requires that the group collaborate on understanding its contextual needs; consequently, tailoring groupware is tailoring group work. And tailoring group work is a collaborative process involving reflection and collaboration (negotiation). Our research efforts have just begun. Our purpose in this paper is to introduce our vision for tailoring group work, to clarify principles underlying tailoring group work, and to lay out the research approach we are currently taking, in expectation of stimulating interest in this challenging area. We are not organizational psychologist, although we are aware of the large body of work in that field that certainly informs our studies. Closer to our own efforts are those of the members of the CSCW community who are building theories around how new technologies are introduced and used in work contexts not populated by computer scientists. The thesis of Marike Hettinga is typical of research to formulate and test such theories, and provides a rich explanation and bibliography around techniques for case studies [2]. Especially of interest is her presentation of work breakdowns as opportunities for reflection.1

2 Terminology: Group Work and Tailoring The choice of the term “tailor” is fairly standard terminology: to adapt a certain aspect, to make to specific requirements or measurements; to make, alter, or adapt for a particular end or purpose. Our use of “group work” needs some explanation. Robert Johansen defines groupware as: “specialized computer aids that are designed for the use of collaborative work groups.” [3] This definition lumps computer aids such as documentation templates and typesetting word processors, useful for collaboration in shared writing tasks, with more sophisticated aids such as a version management system (e.g., CVS [1]). Both kinds of aids work successfully only in the context of some organizational agreements. The templates and choice of typesetter represent information exchange format agreements, while versioning relies on established rules for passing change rights. Such agreements or rules can be built into the computer aid, or managed externally. Our work on tailoring group work relates to this wider context of external influence on the use of computer aids. By “group work” we mean the group itself, its rules for assigning and taking responsibility (typically manifested as roles), its goals and processes by which it seeks its goals, its measures for monitoring progress, additional rules by which information flows through the group, work plans, and resources, including software to support the execution of its work plan. Peter Johnson-Lenz and Trudy Johnson-Lenz [4] coined the term “groupware” with this larger contextual notion in mind by defining groupware as “intentional group processes plus software to support them”. The idea is that group collaboration and support for the collaboration is not defined by the software, but by the processes that the software is expected to support. Later, these same authors noted that the emphasis solely on processes was too limiting. In [5], they suggest a set of principles for the development, tailoring, and use of groupware systems so as to emphasize that 1

We would like to express our appreciation to the reviewers for pointing us to this timely and useful reference.

Tailoring Group Work

235

groupware is a part of a creative process, and that this process serves to evolve both the software and the context of use of that software, i.e., the group work. The users’ ability to create provides a powerful indicator of the success of groupware, in so far as the groupware fulfills the requirement to be altered by the users to support their specific needs and purpose. In considering these ideas, it is easy to conclude that the authors tie group success to the ability of the group to express its own identity through the way it sets up and uses tools. In fact, this conclusion is precisely the idea. Consider simple communications tools like chat. The form for a chat may not have evolved much, but the form of the chatting has, with the introduction of clever letter sequences to express emotions, laughter or tears, annoyance or pleasure. MUDs evolved to MOOs, to support users in their ability to tailor their personal representations in online interactions. The question is who does the tailoring? What about group work can or should be open to alteration? And does the ability to tailor dominate or enhance the work effort?

3 The Nature of Tailoring These questions cannot be answered without first exploring the broader question of what is the nature of tailoring. Our purpose is to provide a sufficiently clear definition that we can both understand how others have approached research about tailoring so as to learn from their work, and to light a pathway for our own endeavor. Briefly, we want to know if the ability to tailor group work—the groupware and/or the context in which that groupware is used—impacts the efficacy of the group. A number of recent workshops have explored how to position the question of tailoring. The paper ”Tailorable Groupware – Issues, Methods and Architectures” [10] reports on the results of a workshop on the subject, held at the GROUP’97 conference. In this workshop, which emphasized the software aspects of groupware, tailoring is seen as extending an application during its use in order to cover requirements that were not present in the original design. The WACC’99 workshop on ”Implementing Tailorability in Groupware” reconvened the discussion, but this time with the added participation of researchers outside the boundaries of computer science. This discussion concluded that the ability to tailor groupware is fundamental to achieving groupware’s acceptance. The workshop report [13] gives some accounts on work being done regarding the relation of tailoring to the social construction of knowledge. In the article “User-Tailorable Systems: Pressing the Issues with Buttons”[8], MacLean et al present tailoring as a community effort. Here we see a shift of attention from “why tailor” to “who tailors”. Tailoring is motivated by establishing a tailoring culture. The community of users is populated by ”workers” who just want to get work done, ”tinkerers” that enjoy exploring the system but may not understand it totally, ”programmers” that are gurus who understand the system in detail, and ”handymen” that act as bridges between workers and programmers. A tailoring culture helps workers be in control of changing the system by communicating their needs to tinkerers, programmers, or handymen, in cases where the complexity of the task surpasses the workers’ skill level. The approach aims to build a social network in

236

A. Fernández, J.M. Haake, and A. Goldberg

which communications among users of different skills improves group interest in learning about and carrying out system refinement. Mackay [6, 7] reports on studies about sharing files containing customization data. The first target of customization in these studies is a system called the Information Lens[9], an e-mail filtering system that lets users define their own mail filtering rules. The second target of customization was a user who could customize the working environment of a shared Unix System to their preferences (e.g., aliases, windows size, icon behavior, background, menus, key bindings). Mail filtering rules and personal environment configuration are primarily about personalizing for individuals. However, Mackay’s research renders tailoring as a learning activity that, in the context of group work, has benefits potentially for everyone. Her contribution to tailoring of group work is ”tailoring as peer learning”. The work reported by Farshcian and Divitini in their position paper to the GROUP’97 workshop on tailorable groupware[10], describes a highly tailorable system for building collaboration spaces on the world-wide web. The system includes notification facilities to support the coordination of individual tailoring efforts. Email notifications are used to provide awareness about changes due to modifications of the shared collaboration spaces to fit particular situations. Although not the main focus of their work, Farshcian and Divitini reminds us of the importance of keeping users aware of the status of shared spaces. Anders Mørch studied tailoring as indirect, long-term collaboration between users and developers. In his paper, ”Tailoring as Collaboration: The Mediating Role of Multiple Representations and Application Units” [11], he highlights the importance that documenting design rationale has on communication. Mørch draws our attention to the time span of the changes done in the context of tailoring. In his work, he relates tailoring in the context of use to later development. Hence, he highlights the requirement for documenting change, both to enable future development and to enable iteratively customizing the changes. Wang and Haake [14] approached tailoring of groupware by allowing groups to adapt the processes that model their work. Moreover, such tailoring is done in collaboration. The XCHIPS system introduced by these researchers allows group members to negotiate their work processes and update them accordingly. This work is unique in that it provided the technical means to collaboratively model and evolve work processes. However, the system provides no specific support for negotiation or tracking of evolution, and targets a particular kind of workflow model for processes. Johnson-Lenz and Johnson-Lenz [5] offer us a very comprehensive view of the tailoring of effective groupware. Facilitators provide the initial structure that groups need to get started. Then, as the group evolves in response to feedback from these initial structures, they self organize and become part of a cycle for tailoring the structures in response to each new situation. The work cited here is couched in social terms, strictly about social dynamics and evolving personal interactions within group settings, rather than specific computer aids and how the aids evolve. Their contribution is to emphasize that group work tends to mature when sufficient space is given for reflection and discussion about how work takes place, not just about the work artifacts.

Tailoring Group Work

237

GW0 = process0 + tools/resources0 tailoring(goals, criteria) GW1 = process1 + tools/resources1 evaluate(goals, criteria) Success/Failure

Fig. 1. Tailoring Group Work

We conceptualize tailoring as the process of changing group work, assuming that a need for tailoring is given. Fig. 1 represents our understanding of group work as a combination of social/work processes and tools/resources. In order to tailor an instance of group work GW0 into another instance of group work GW1, a mapping from the existing process and tool/resource system into the new one must be defined. This tailoring function is dependent on the goals and success criteria defined by the original need for tailoring. In order to check the success of the tailoring, an evaluation function is needed, which tests whether the new form of group work GW1is meeting the success criteria derived from the impetus for tailoring. In the introductory example, GWo represents group work without the calendar. Coordination is manually done. GW1 is group work with the calendar and, ideally, with the right processes in place to ensure that the calendar is correctly maintained and used. GW3, one step further, is group work where the location and implementation of the calendar has been changed in order to simplify access. Sadly, the evaluation function was missing 3.1 Tailoring as a Form of Reflection Tailoring requires that the users move away from the task being performed in order to ask questions about how the context could better support (or at least hinder less) the ability to do the work. Both the act of tailoring, but more importantly, the decision to tailor, has to be handled at a different level. Take, as an example, the requirement to evaluate one’s work. It is possible to focus solely on the outcome of the work, applying measures of quality consistent with the organization’s objectives. But it is also possible to consider the characteristics of the work environment, especially the quality of the tools, the ability to communicate with other workers, and the ability to learn from these and others with complimentary or more mature skills. We can develop better software systems that allow users to more easily change the various functions, but the decision to make those changes has to be considered as well. And we may want to understand why a system, for example, was tailored to take its current form. Tailoring is in many cases an exploratory experience. The ultimate destination is not always known by the tailor who may change a computer aid while trying to understand how to best use it, or in order to understand its potential use. Drawing from his experience, the tailor tries what he thinks could work better for his needs. He works under the new circumstances, preferably paying attention to the effect of the

238

A. Fernández, J.M. Haake, and A. Goldberg

changes. What results from the new setting causes the users to try further possibilities, take back the change, or finally accept it. The emphasis in the last decade on software prototyping certainly illustrates this point, as do the large-scale efforts to identify fundamental frameworks for enterprise systems that can be modified through specialization in the sense of object technology’s support for behavior refinement. What is said in the preceding paragraphs borrows from Schön’s theory of Reflection in Action [12]. Reflection in action is a practitioner’s conversation with a problem that aims at defining it, constructing hypotheses to test, either through observation or experimentation. At each step the practitioner may draw on several sources of knowledge and experience. Like tailoring, reflection is a continuous spiral of appreciation, action and re-appreciation, leading to the goal. In each cycle of the spiral, the practitioner takes decisions and makes commitments that must be honored in future cycles. The model depicted by Fig. 2 complements our initial conceptualization of tailoring of group work, by placing the functions for tailoring and evaluation in the context of a continuous cycle of reflective tailoring. Awareness of success criteria triggers reflection when such criteria are not met. Reflection on the actual state of group work results in a perception of what needs to be change. A solution follows, in the form of a function that maps from the current situation to the desired one. Moreover, evaluation criteria accompany the solution and are applied while the solution is in place. Such evaluation criteria would lead to further cycles of tailoring.

Identify Solve tailloring(goals, criteria)

Realize

Observe/Learn evaluate(goals, criteria)

Fig. 2. Continuous Reflection and Tailoring

In this model, successful tailoring requires the ability: œ To explicitly express processes and resources (work context) in a form that provides the basis for discussion and in a form that can be modified; œ To define a mapping between existing and proposed new process and tool/resource systems, which will address the initial need for the tailoring, again in a form that can be discussed, debated, and resolved; œ To maintain consistency between any multiply selected process and tool/resource system, so that information created in any tailored version can be shared as change is adopted; œ To ensure acceptance of the resulting change through the ability to monitor the anticipated benefits (i.e., so that users adapt and stick to the changes); and

Tailoring Group Work

239

œ To maintain awareness of success criteria and a shared ability to evaluate the success of the change. The consequences of this conceptualization are twofold: (1) Tailoring – since it is an action stimulated by a recognized need – requires (group) reflection, and is itself a reflective process requiring monitoring and change. (2) Tailoring group work – since it is both affecting a group and being performed in a group, is a collaborative process and is therefore subject to software system assistance (groupware for tailoring support). 3.2 Tailoring as a Form of Collaboration When a group is tailoring its own way of performing group work, first of all it requires a shared vocabulary, the terminology for talking about change. Next, it needs a consistent collaborative tailoring process, which helps define the desired mappings and meet the success criteria noted earlier. The Language of Reflection The notion of reflection is that you think about or theorize about what you are doing. It assumes that you have a language with which to discuss your work. If you are a solitary worker, then the only person who has to understand your terminology and the way you use terms to express your ideas is…well, you. But if you are in a collaborative situation, as you most certainly are when working in a team of people with whom you share a common goal to produce some outcome, then how you talk about your work affects whether you can agree on change. When computer scientists create a groupware system and identify various parameters that can be set or various interfaces where additional functionality can be integrated, then these scientists have defined a form of vocabulary for talking about tailoring the system. Of course, the vocabulary is restricted. When a groupware system truly expects to support its users collaborative needs, then it would seem to follow that changing the system should itself be done in a collaborative manner. Hence we propose that tailoring group work, restated minimally as tailoring the computer aids to working together, should be done collaboratively. And then it follows that there has to be some way in which the participants can talk about how the groupware does or does not support their work, and they must be able to debate or at least negotiate to reach agreement on what should be changed. In this case, we are obviously focused on changes that are shared. Some form of formal language is also a requirement if the groupware system is to support the group in tracking the results of tailoring and raising the flags that indicate that a reaction is needed. Such language, based on a set of concepts whose evolution can be trace by the system, allows users to express their interests. Negotiation in Tailoring Tailoring can be dictated, just as the use of the calendar in our opening story was dictated. But the benefit of the tailoring comes not just from having a tailored result. It also comes from the effort spent by group members in reflecting on how they work

240

A. Fernández, J.M. Haake, and A. Goldberg

together and in negotiating what, because of natural group diversity of style and opinion, by necessity becomes a compromise. To work together effectively in such a situation requires that the group be fully aware of how and why the compromise was reached. Our challenge then is to design our groupware in such a way that it can support the group in reaching such compromises and documenting the rationale in a manner that is useful when, inevitably, another round of tailoring is desired. Negotiation and collaboration are present in each stage of the model in Fig.2. Group members need to negotiate in order to come to an agreed perception of the situation requiring action. They must also negotiate a solution approach that balances their needs. Furthermore, they must work together to implement the change itself and the mechanisms that would lead to evaluation of success. 3.3 System Design Issues Our ultimate goal is to shape groupware systems so that they support groups during the evolving process of use and development. Achieving such a goal requires that the following issues be resolved: Mapping processes and tools/resources: Based on terminology/notation, it must be possible to describe existing and new process systems (actors, roles, tasks, and abstract resources), tools and specific resources, to make sure that information created in a prior version is properly accessible in the current version, where appropriate. Maintaining consistency: Make sure that abstract resources in the process system are mapped consistently on tools/resources in the tool/resource system. If new tools/data objects are used, explain how they are created (e.g., from existing tools/data objects) so that the history of evolution can be traced and potentially unwound. Managing change: Ensure acceptance through creation and communication of participatory design processes, documentation on how goals and milestones are to be met by the proposed (re)design, and identification of measures for success and progress that can be monitored by the group and the system. Facilitating evolution by recognizing that change invites further change, and providing: techniques for capturing and reviewing the history in a form accessible by all current and future group members; documentation for change rationale and a process for continual reconsideration; a context for encouraging reflection.

4 Summary In this paper, we present a new view of tailoring groupware as an extension of the larger opportunity—tailoring group work, which is the context that gives groupware its value. We approach tailoring of group work by highlighting its reflective and collaborative nature. The contribution of this work lies in the analysis of issues that surround a model of tailoring as repeated cycles of realization, definition, solution, and observation and learning. Moreover, an initial exploration of system design issues is made that sets the departure points for further research. Understanding and supporting groups in tailoring group work presents many challenges. The field is still unexplored. We are conducting studies with groups that,

Tailoring Group Work

241

for a variety of circumstances in the context in which they are immersed, are required to change. Our goal is to provide them with an environment that helps them undertake change as a group. Such an environment must comprise support for group members to build on a language of reflection; a means to negotiate a clear statement of the shared group work problem (including a needs statement), a means to express the goals and success criteria tied to any change; and a mechanism to stay aware of whether a particular decision for how to change creates the desired result. Our current activity targets a group of software developers in re-defining their developments processes. The needs of their work context as well as the composition of the group have changed in a way that calls for redefinition of the principles, goals, and mechanisms of the group. During this experience, the group evolves its group work from a few starting structures that define its initial work processes, resources, and tools. At the same time, a new groupware system is being designed that can support tailoring the group work. This new system is to embrace the collaborative tailoring definition of reflection and negotiation. To do so involves providing the capability for the group to reflect on their work at two distinct levels. On one level, group members reflect on their work practices. On the other, jointly with us as facilitators, they reflect on how an evolution of their work practices can be supported and taken forward. To tackle the complexity of this task, we have identified a small number of members that feel comfortable moving between these two levels. They are aware of the fact that we are constructing (through tailoring) the process that guides how software development is changed for the whole group. We cannot claim that the model for tailoring presented in this paper ensures success. We point to the key forces that, when manipulated in a wise manner, can lead to success. Our observations are founded on what has been learned already that can be related to collaborative tailoring. Of course, any attempt to construct a new setting for successful collaborative tailoring requires its own associated set of evaluation measures. Only then, the tailor of tailors can formally certify any positive outcomes. We, the tailors of the context that allows our software developers to tailor their group work, have chosen a set of measures focused on acceptance and adoption of change, adequacy of the constructed change (i.e., whether change generated in our environment produces positive impact in group work), and the capacity to generate and maintain variations of group work Iteratively, tailoring from initial simple structures, we will obtain groupware to tailor group work.

References 1. 2. 3. 4.

Berliner, B. CVS II: Parallelizing Software Development. in Proceedings of USENIX Winter 1990 Technical Conference. 1990: USENIX Association. Hettinga, M., Understanding Evolutionary use of Groupware. Telematica Instituut Fundamental Research Series. 2002, Enschede, The Netherlands: Universal Press, Veenedaal, The Netherlands. 180. Johansen, R., GroupWare: Computer Support for Business Teams. 1988, New York: The Free Press, Macmillan Inc. Johnson-Lenz, P. and T. Johnson-Lenz, Consider the Groupware: Design and Group Process Impacts on Communication in the Electronic Medium, in Computer-Mediated Communication Systems. 1981, Academic Press: Newark, New Jersey.

242 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.

A. Fernández, J.M. Haake, and A. Goldberg Johnson-Lenz, P. and T. Johnson-Lenz, Rhythms, Boundaries, and Containers: Creative Dynamics of Asynchronous Group Life. The International Journal of Man Machine Studies, 1991(34): p. 395-417. Mackay, W.E. Patterns of Sharing Customizable Software. in Proceedings of Computersupported cooperative work (CSCW’90). 1990: ACM Press. Mackay, W.E., Users and Customizable Software: A Co-Adaptive Phenomenon. 1990, Massachusetts Instititute of Technology. MacLean, A., et al., User-tailorable systems: pressing the issues with buttons. Special issue of the SIGCHI Bulletin: Conference proceedings on Empowering people - Human factors in computing system, 1990: p. 175-182. Malone, T.W., et al., The information lens: An intelligent system for information sharing and coordination, in Technological Support for Work Group Collaboration, M.H. Olson, Editor. 1989, Lawrence Erlbaum Associates. p. 65--88. Mørch, A., O. Stiemerling, and V. Wulf, Tailorable groupware: issues, methods, and architectures (workshop report). The SIGCHI Bulletin, 1998. 30(2). Mørch, A.I. and N.D. Mehandjiev, Tailoring as Collaboration: The Mediating Role of Multiple Representations and Application Units. Computer Supported Cooperative Work. The Journal of Collaborative Computing, 2000. 9(1): p. 75-100. Schön, D.A., The Reflective Practitioner. How Professionals Think in Action. 1983, New York: Basic Books Inc. Teege, G., Implementing Tailorability in Groupware. WACC’99 Workshop report. SIGGROUP Bulletin, 1999. 20(2): p. 57-59. Wang, W. and J.M. Haake, Tailoring Groupware: The Cooperative Hypermedia Approach. Computer Supported Cooperative Work: the Journal of CollaborativeComputing, 2000. 9(1): p. 123-146.

Building Groupwares over Duplicated Object Systems Hechmi Khlifi1 , Jocelyn Desbiens1 , and Mohamed Cheriet2 1

INRS–T´el´ecommunications, Universit´e du Qu´ebec, Place Bonaventure, 900, de la Gaucheti`ere, Ouest, Niveau C, C.P. 644, Montr´eal (Qu´ebec) Canada, H5A 1C6, {khlifi,desbiens}@inrs-telecom.uquebec.ca 2 ´ Ecole de Technologie Sup´erieure, Universit´e du Qu´ebec, 1100 rue Notre-Dame, Ouest, Montr´eal (Qu´ebec) Canada, H3C 1K3, [email protected]

Abstract. Groupware toolkits let developers build applications for synchronous and distributed computer-based conferencing. Duplicated object systems1 (or DoS ), on the other hand, manage distributed objects over the Internet and, since they include high-level features such as communication facilities, load balancing, fault tolerance, and hierarchical messaging, may be leveraged as building blocks for rapidly developing groupware toolkits. This paper describes how we built such a groupware starting from a particular DoS. The system contains a run-time architecture that automatically manages the creation, interconnection, and communications of the distributed processes involved in the working sessions, a set of groupware facilities allowing users to collaborate, to take action on state changes, and to share relevant data, and a session management and user control mechanisms accommodating the group’s working style.

1

Introduction

Building groupware for synchronous, distributed conferencing can be a frustrating experience. If only conventional single-user GUI toolkits are available, implementing even the simplest systems can be lengthy and error-prone. A programmer must spend much time on tedious but highly technical house-keeping tasks, and must recreate interface components to work in a multi-user setting. Aside from the normal load of developing a robust application, the programmer of groupware must also attend to the setup and management of distributed processes, inter-process communication, state management and process synchronization, design of groupware widgets, creation of session managers, concurrency control, security, and so on. Consequently, a variety of researchers have been exploring groupware toolkits [9]. Their purpose is to provide tools and infrastructures powerful enough 1

Object duplication is a distributed object paradigm created and put forward by Quazal Inc., a Montr´eal based company where one of the author worked for one and a half year.

J.M. Haake and J.A. Pino (Eds.): CRIWG 2002, LNCS 2440, pp. 245–254, 2002. c Springer-Verlag Berlin Heidelberg 2002


246

H. Khlifi, J. Desbiens, and M. Cheriet

to let a programmer develop robust, high quality groupware with reasonable effort. Some inroads have been made, but we are far from a complete solution. Realistically, most of today’s groupware toolkits are best seen as breakthrough research systems used to either explore particular architectural features of groupware toolkits, or as platforms to build experimental groupware prototypes. While they have not reached the maturity of single-user GUI toolkits, these pioneering efforts have laid a foundation for the next generation of toolkit design. The solution we propose to this problem is to build the groupware upon a DoS. The DoS handles all the low-level technical network details. This allow us to construct real-time distributed multi-point groupware applications, where two or more people in different locations would be able to visually share and manipulate their online work. Typical applications produced by this system would be electronic whiteboards, games, multi-user text and graphics editors, distributed presentation software, textual chat systems, and so on. In the second section of this paper we define and describe the principals features of Duplicated Object Systems. In the third section, we describe how Synchromedia 2 , a distance-learning system, has been built using a DoS.

2

Duplicated Object System

2.1

DoS: Overview

A Duplicated Object System 3 is a distributed object architecture where information is “pushed” across the network rather than using the less scalable “pull” approach. The basic philosophy is that a collaborative application consists of a collection of objects which need to be distributed and duplicated across the stations participating in the session. Furthermore, the object content needs to be coherent and upon modification propagated to other stations. In a collaborative application, shared objects need to be duplicated across the network so that the participants may see each other. Object duplication is the mechanism used by a DoS to achieve this. The use of duplicated objects gives a DoS significant advantages over other technologies when it comes to the features offered and the ease of programming as they allow high level features such as fault tolerance, load balancing, and object migration to be presented to the user in an easy to use manner. A duplicated object has the status of either duplication master or duplica. The duplication master of an object is the controlling instance of the object, while its duplicas are copies of the master object. If a participant joins a session that is already in progress, duplicas of the existing duplicated objects that the new participant requires will be automatically created on that participant’s station. The object duplication model used by a DoS allows the programmer to define where objects are required to be duplicated via several different implementations, as detailed below. 2 3

´ Synchromedia: Tele-education and tele-research global university. Ecole de Technologie de l’Information. Universit´e du Qu´ebec. Or DoS for short.

Building Groupwares over Duplicated Object Systems

2.2

247

Object Duplication

To enable participants to see each other, duplicated objects need to be duplicated to those stations that require the object. However, to enable a session to be scaled and to operate efficiently, each station connected to a session should only have copies of the objects that it really needs. This ensures that the use of resources such as CPU and bandwidth are minimized, which allows for a greater number of simultaneously connected users. In a DoS, there are possibly four mechanisms used to duplicate objects to the stations where they are required: a duplication master may create a duplica on a particular station, a station may fetch a duplica of a specific duplication master, an object may be automatically duplicated to all participating stations, or duplication spaces may be used to dictate where objects should be duplicated to. The flexibility of the duplication model allows the programmer to use any combination of these four mechanisms to control the duplication of objects across the stations connected to the session. This gives the programmer the ability to decide how many duplicas of each object are published and to which stations so that objects are only duplicated to the stations where they are needed. The level of control that the developer has also facilitates the optimization of resource usage, such as the available memory and bandwidth. If an object is required to be known globally, the easiest way to be certain that it is duplicated to all stations participating in the session is to ensure that the user-defined class inherits from the appropriate DoS class. This will guarantee that the object will be duplicated to each station connected to the session. If an object is not required to be known globally then the programmer must dictate the conditions under which an object is duplicated. This can be done by simply directly calling the appropriate method to create a duplica on another station or to fetch a duplica from another station. In certain situations, this may be the simplest manner in which to duplicate objects. However, if objects are simultaneously created, migrated, or deleted, due to operations such as fault tolerance and load balancing, object duplication can become very complex and the implementation of duplication spaces will usually present an easier solution to the management of object duplication.

3

Building a Groupware over a DoS: Synchromedia

Synchromedia is a distance-learning project involving four universities and about ten researchers. It is made up of a collection of collaborative tools (whiteboard, chat, audio/video, shared directories, and virtual laboratory) allowing students to work together and to interact as if they were in a real classroom. Synchromedia is a typical example of a groupware made from a DoS. The Dos we used is NetZ [7]. Figure 1 is a snapshot of the user’s interface. 3.1

Communications in Synchromedia

Communication across a large network presents a number of difficulties that need to be overcome in order to produce an efficient and operable system. The types

248

H. Khlifi, J. Desbiens, and M. Cheriet

Fig. 1. User’s interface

of problems encountered are the numerous combinations of connection types and processing power that each station may have which leads to non-uniform station capacities and available bandwidth. In addition, the variety of transport types means that stations with no common transport cannot communicate directly with each other. In the case of Synchromedia, the DoS communication model deals with these problems thus relieving the programmer of these complex issues. To solve the problem of different transport types, a DoS performs automatic message routing as required. Therefore, if a station cannot directly communicate with a station to which it wishes to send a message, the DoS will automatically route the message via another station. This is useful to circumvent firewalls and to enable two stations that do not have a common transport type to communicate. 3.2

Maintaining Consistency in Synchromedia

Synchromedia is made of duplicated objects. Collaborative work consists on the sharing of a collection of duplicated objects. Each duplicated object has a master and duplicas. The master is responsible of updating the itself and its duplicas. When a user perform an action on the master, the master take charge of distributing the effect of this action on all its duplicas. If the action is performed on a duplica, this duplica notify its master about it and the master distribute its effect of the action to all other duplicas. This approach permit to avoid the emergence of inconsistency rather then allow it and reestablish consistency as some other systems do [3,4]. For each duplicated object, a DoS uses ordering to avoid inconsistency. Ordering consists

Building Groupwares over Duplicated Object Systems

249

on accepting actions that may cause inconsistency and postponing their execution to a moment that will not cause the emergence of inconsistency. This approach is also known as serialization [3]. Various approaches exist that can ensure consistency requirements based on logical time [6] (FIFO, CAUSAL and TOTAL). FIFO order implies that messages from the same source to the same destination are delivered in their order of generation. CAUSAL [6] order implies that messages that are linked by a causal relation are delivered in FIFO order. TOTAL order implies that all destinations receive all messages in the same order regardless of their emission order. A DoS uses a TOTAL ordering scheme for each duplicate object. This scheme guarantee that all copies of any duplicated object remain consistent during the collaborative work. In that way the whole collaborative work remain consistent. Although the TOTAL ordering scheme usually increase response times and notification times, its use within a DoS improves this weakness. In fact, each duplicated object is treated separately so that the queuing time is reduced. In addition, masters of duplicated objects are distributed all over the network so that the the processing charges is shared between many stations. 3.3

Management of Presence in Synchromedia

DoS don’t provide appropriate mechanisms for the control of presence. Although they provide a joiner-based mechanism for the management of sessions, they don’t allow the control of groups and users. Groupware developers have to implement their own mechanisms for controlling users and groups. As part of the project Synchromedia, we designed and implemented a mechanism for the management of presence in groupware. This mechanism manage sessions according to the joiner-based approach, though we added the option of launching sessions in the absence of users. This option give more independence to the system towards its users. As far as the management of users and groups are concerned, we adopted an organization of work meeting the needs of collaborative work at the university level. Users are organized in groups, and are administrated and controlled according to their roles. Organization of Work. The work in Synchromedia is organized according to the four next guidelines: 1. a single work space includes all participants in the collaborative works. This space correspond to the university in the real context; 2. in this work space, there may be as many work groups as one wishes. Each work group includes all users working on the same theme and having the same objectives (students and teacher). Work groups are not necessarily mutually exclusive. This means that a user may belong to more than one work group; 3. the users of a work group collaborate during a work meeting (i.e., a course). A users can work simultaneously in many work meetings if he is member of the corresponding work groups;

250

H. Khlifi, J. Desbiens, and M. Cheriet

4. the users have different rights. These in turn depend on the user’s role. For instance, a teacher may perform some actions that are not permitted to student. During a work meeting, each work group is administrated by an administrator (i.e., the teacher). Figure 2 illustrates the organization of work mentioned above.

work space

work group in a work meeting user administrator privileged user

Fig. 2. Organization of work

Administration of Users and Groups in Synchromedia. The administration of users and groups in Synchrom´edia is made according to a new model that we called DRBAC (Dynamic Role Based Access Control). This model is derived from the Role Based Access Control model (RBAC) [8,1,2,5]. RBAC is used to describe security mechanisms that mediate users’ access to computational resources based on role constructs. A role defines a set of allowable activities for users authorized its use. It can be thought of as a job title or position within an organization, which represents the authority needed to conduct the associated duties. The introduction of roles in the security mechanisms considerably reduces the cost and complexity of administration ([1] presents an exhaustive study of this issue). As shown in figure 3, RBAC associates users with roles and roles with permissions. A permission is the right to perform a given action on a given object. A user who is authorized to a role, is consequently authorized to all permissions underlying of this role. DRBAC is derived from RBAC. It takes advantage of RBAC to reduce the administration cost. In addition, it provides new features that meet the groupwares requirements. DRBAC distinguishes between two states of the system:

Building Groupwares over Duplicated Object Systems

251

user

role

action

object permission

Fig. 3. RBAC approach

static state and execution state. The static state is the state of the system before initiating the collaborative work. The execution state is the state of the system during the collaborative work. The figure 4 presents these two states. In the static state, we introduce a new association action/user that doesn’t exist in the RBAC. We call this association administration as it refers to actions that one user may perform on another user. For instance preventing a user from writing on the whiteboard is an administration that a teacher can perform on a student. In this way, DRBAC associates, in one hand, users to roles and, in the other hand, roles to permissions and administrations. Those associations are immutable during the static state, however they may change during the execution state. A new association appears also in the execution state. This association links users directly to permissions and administrations. This association is very important as far as it results of the administrations performed by privileged users on others users. For instance if the teacher allows a student to write on the whiteboard, a new association between this student and the permission write on the whiteboard appears even though this permission is not allowed to the role student. The associations between users in one side and permissions or administrations in the other side are temporary and don’t last after the end of the collaborative work. The introduction of the execution state with the DRBAC model permit a better control of users while working. It permits a real time administration of users. For instance a teacher is given a mean to modify student’s rights and privileges, i.e., he may allow or prevent a student from writing on the whiteboard. DRBAC predicts that users are organized in groups. The creation and destruction of groups are also permissions that can be linked to some roles. In

252

H. Khlifi, J. Desbiens, and M. Cheriet

user

user

role

role

action

object

static state

action

object

execution state

Fig. 4. DRBAC approach

addition, groups may be definite statically and users are given or not the right to gain access to them. Integration of DRBAC. In order to integrate the DRBAC to Synchromedia, we have developed the following three components: – Static DRBAC database: this database is used to specify the users, their roles and their memberships. To each role is assigned a set of permissions and administrations. If a user is active in a role, he is allowed to perform all actions linked to this role. – Activation manager: this manager is responsible for controlling users within the execution state of the system. It is directly integrated in Synchromedia. To each duplicated object User , are associated two structures : a permission table and an administration table. The permissions table contains the permissions of the corresponding user and the administrations table contains the administrations of the corresponding user. After login, user’s permissions and administrations are downloaded from the static control database to the structures and distributed to all users of his/her group. When the user attempts to perform an action, the system verifies his permissions table before allowing the action to be done. Permissions could be changed at runtime by an authorized user. The administration table of authorized users contains the administrations that allow them to modify others’ permissions. Permissions are actually implemented in the form of a matrix. Rows of a permission matrix correspond to objects and columns to actions performed on those objects. The content of a cell (i, j) is a variable that may take one of the three following values: 0, 1, or -1, 0 meaning that the corresponding

Building Groupwares over Duplicated Object Systems

253

user is not allowed to perform the action i onto the object j, 1 meaning that he is allowed to perform that action, and -1 meaning that the action is not defined for the object. Table 5 gives an example of the permissions matrix of a student in Synchromedia. Write Erase Change entries Stop Whiteboard 1 1 -1 -1 Virtual lab -1 -1 0 0 Fig. 5. Student’s permission table

As well as permissions, administrations are also implemented in the form of matrix. Rows of an administration matrix correspond to roles and columns to actions performed on the users of those roles. The content of a cell (i, j) is a variable that may take the values: 0 or 1, 0 meaning that the owner of this administration table is not allowed to perform the action i onto the users of the role j, and 1 meaning that he is allowed to do so. Table 6 gives an example of the administration matrix of a teacher in Synchromedia.

Assistant Student

Allow writing Prevent writing Eject 1 1 0 1 1 1

Fig. 6. Teacher’s administration table

– Administration tool: the administration tool is an interface designed for the administration of the static control database. It’s purpose is to let the administrator define and modify users, groups, roles, and permissions for the current session.

4

Conclusion

By abstracting the network layer, a DoS allows groupware developers to concentrate their development efforts on content and tools rather than network issues. Via high-level features such as communication facilities, load balancing, fault tolerance, and hierarchical messaging, an DoS-enabled groupware effectively deals with the Internet’s inherent unreliability, high latencies, bandwidth limitations, and resource constraints. In Synchromedia, we have designed and implemented our own mechanism for the management of presence. The main idea behind this mechanism is to allow privileged users to administrate their groups during the collaborative work. Our future work will be focused on the following two directions:

254

H. Khlifi, J. Desbiens, and M. Cheriet

– Comparison between the three run-time architectures used to build groupwares (centralized, replicated, and DoS architecture). The criteria of comparison are: response time and notification time. This comparison can be made using a mathematical model, a simulation or by making some experiences and taking measurements. – Further development of the DRBAC model, especially to formally define the different components of this model and to introduce the static and dynamic constraints that may apply. The existence of a well-defined model will make easier the implementation of groupwares and give more flexibility to their use. Acknowledgments. Netz product was provided by Quazal Inc. from Montr´eal, special thanks to all the team up there. This research work was supported by grants from FODAR (University of Qu´ebec Academic Fund and Development Fund) and the MEQ (Department of Education of Qu´ebec).

References [1] D.F. Ferraiolo, J.F. Barkley, and D.R. Kuhn. A role based access control model and reference implementation within a corporate intranet. ACM Transactions on Information Systems Security, 1, February 1999. [2] D.F. Ferraiolo, J. Cugini, and D.R. Kuhn. Role based access control: Features and motivations. 1995. [3] S. Greenberg and D. Marwood. Real time groupware as a distributed system: Concurrency control and its effect on the interface. In Proceedings of the ACM CSCW 94 Conference on Computer Supported Cooperative Work, pages 207–217, October 1994. [4] A. Karsenty and M. Beaudoin-Lafon. Slice: a logical model for shared editors. In Real Time Group Drawing and Writing Tools, pages 156–173, McGraw-Hill, New York, 1995. [5] D.R. Kuhn. Mutual exclusion of roles as a means of implementing separation of duty in role-based access control systems. In Second ACM Workshop on Role-Based Access Control, 1997. [6] L. Lamport. Time, clocks and the ordering of events in a distributed system. Communications of the ACM, pages 558–565, july 1978. [7] Quazal. Net-z 2.0 - technical overview. [8] R.S. Sandhu, E.J. Coyne, H.L. Feinstein, and C.E. Youman. Role-based access control models. IEEE Computer, 29(2):38–47, 1996. [9] T. Urnes and R. Nejabi. Tools for implementing groupware: Survey and evaluation. Technical Report No. CS-94-03, York University, 1994.

Adaptive and Transparent Data Distribution Support for Synchronous Groupware Stephan Lukosch University of Hagen Computer Science II - Cooperative Systems 58084 Hagen, Germany [email protected]

Abstract. The data of a groupware application must be shared to support interactions between collaborating users. There have been a lot of discussions about the best distribution scheme for the data of a groupware application. Many existing groupware platforms only support one distribution scheme, e.g. a replicated or a central scheme. The selected scheme applies to the entire application. In our opinion, none of these architectures fits well for every groupware application. In this paper we describe a development platform that allows a developer to determine the distribution scheme for each shared data object. With the help of an object-oriented programming principle it also achieves a maximum of transparency for the application developer.

1

Introduction

Synchronous groupware brings together users, which are geographically distributed and connected via a network. It encompasses a wide range of applications like collaborative whiteboards, text editors or Web browsers. All these applications have to share data to support interactions between their users. There have been a lot of discussions about the best distribution scheme for the data objects of a groupware application. Many existing groupware platforms support a replicated distribution scheme or a central one. The supported scheme applies to the entire application. In our opinion, none of these architectures fits well for every groupware application. Different applications or even single applications may have different requirements concerning data distribution in general for particular data objects. Therefore a developer should be able to individually control the distribution scheme of a shared data object. In this paper we present a platform, which substantially simplifies the development of shared data objects. The main benefits of this platform are: – Various distribution schemes: For data objects with a significant amount of data and minor data exchange, e.g., a video, a developer may choose an asymmetric distribution scheme. In contrast to the central distribution scheme, the asymmetric does not demand a well-known server. In case the application demands high responsiveness, the developer might select a replicated distribution scheme. J.M. Haake and J.A. Pino (Eds.): CRIWG 2002, LNCS 2440, pp. 255–274, 2002. c Springer-Verlag Berlin Heidelberg 2002


256

S. Lukosch

Furthermore we offer a novel adaptive distribution scheme, which dynamically changes the distribution characteristics of a shared object according to a user’s working style. If the data of an application bases on a logical structure, e.g. a text document, single logical pieces of the text document are replicated to those sites, which intensively access them. – Composite data objects: Complex collaborative applications, e.g. virtual environments or computer-aided design applications, demand composite data objects. Our platform supports composite data objects with heterogenous distribution schemes. A developer does not have to use platform-provided classes to build composite data objects and can easily reuse existing data classes. – Runtime configuration: A developer can specify the distribution scheme of a shared object and its consistency configuration at runtime. Furthermore, a developer can change the coupling between the user interface of a collaborative application and its shared objects at runtime. By applying the object-oriented substitution principle, our platform achieves all these benefits with a maximum of transparency for the developer. After an initial configuration concerning the distribution scheme, the consistency, and the coupling to the user interface, the developer can use a shared object like a local data object. The runtime system hides all necessary mechanism to manage the shared data object. Before presenting the concepts and protocols used in our platform, we discuss related work.

2

Related Work

Most of the existing groupware platforms differ with regard to the distribution schemes of the shared data, the application architecture, or both. There are various classification schemes for the distribution architecture of a collaborative application. Patterson’s taxonomy [17] is one of the first architectural models for synchronous groupware. Dewan’s generic architecture [4] can be viewed as a generalisation of Patterson’s taxonomy. Roth et al. [20] analyse a variety of groupware platforms and develop a more comprehensive, extensible classification model. Summing up, we can identify the following data distribution schemes: 1. Central : A well-known server manages the data of an application. The main advantage of this distribution scheme is that it is very simple to handle data consistency and persistency. However, one has to maintain the server, the server is a bottleneck, and slow network connections can increase the response time of an application. 2. Asymmetric: Compared to the central scheme, the asymmetric scheme does not need an additional server, as an arbitrary participating site fulfils its tasks. Using this scheme every participant can easily introduce local data. 3. Semi-replicated : This scheme uses multiple servers, i.e. the data of an application is distributed to more than one site. Compared to the central and asymmetric scheme, this may decrease the response time of an application,

Adaptive and Transparent Data Distribution Support

257

but the runtime system has to use more complex algorithms, e.g. for concurrency control. 4. Replicated : The data of an application is replicated to every participating site. As an application can locally access the shared data, its response time is reduced. Again the runtime system has to use more complex algorithms. Rendezvous [9] and Suite [5] are sample groupware platforms, which use a central distribution scheme for the data of a collaborative application. Suite extends a framework for developing single-user applications by mechanisms supporting groupware aspects. A Suite application consists of a module, which runs on a central server, and replicated dialogue managers. Rendezvous provides a distribution mechanism based on X-windows events. A lot of groupware platforms, e.g., GroupKit [18], COAST [21], or DECAF [23] use the replicated distribution scheme. GroupKit offers a program library, which contains basic services for standard problems, covering session management, communication, and distributed user interfaces. COAST and DECAF extend the well-known architectural style MVC [10] to support groupware applications. They offer abstract classes to develop shared data objects and in this way support, in contrast to GroupKit, composite data objects. ` DAgora [22] is a sample platform for the semi-replicated distribution scheme. It bases on a peer object-group design pattern. Each site holds a replica for every object the associated user is currently working on. The set of replicas for an object is called a peer object-group. To access a replicated object a developer has to join its object-group explicitly. When he is no longer interested, he has to leave the object-group explicitly. In contrast to the previous platforms, TCD [1], Clock [24], and GEN [16] support a variety of distribution schemes. TCD, an implementation of the architectural style Dragonfly, and Clock build groupware applications from components. In both platforms the components can be customised via a visual programming environment. A developer may, e.g., choose between a central and a replicated distribution strategy. While TCD supports concurrency control for both distribution schemes, Clock supports concurrency control only for the central one. GEN especially focuses on flexible distribution strategies. It provides shared objects as a high-level abstraction and allows a developer to specify, how a shared object is distributed and how its consistency is maintained. For this, the developer has to be completely aware of the underlying concepts and protocols, as he has to change the implementation. As default, GEN offers implementations for a replicated or central distribution scheme. In summary, there exist platforms for every distribution scheme. Every distribution scheme has its advantages and drawbacks. However, in our opinion, none of these architectures fits well for every groupware application, as different applications may have different requirements. TCD, Clock, and GEN at least support a variety of distribution schemes. When the developer is completely aware of the underlying concepts, the latter even allows a developer to define own distribution schemes. Our approach achieves a maximum of transparency for the developer. He has not to use abstract classes to develop data objects and he can configure the

258

S. Lukosch

distribution scheme of a shared object and its consistency without being aware of the underlying protocols. We start with the description of the platform which is the funding for our work, and a sample application, which we use in this paper to illustrate our concepts. Then we present our concepts and protocols.

3

DreamTeam

DreamTeam [19] is a platform for synchronous collaboration. It offers a variety of services for application developers as well as for end-users and simplifies the development of synchronous groupware. Based on a completely decentralised architecture, it does not use a central server. The decentralised architecture leads to more complex algorithms, nevertheless it avoids performance bottlenecks and makes the system much more reliable. The platform consists of three parts: 1. Development environment: This environment mainly consists of a Java class library, which, e.g., contains distributed mouse pointers and a collaborative component concept. 2. Runtime environment: This environment provides an infrastructure with special groupware facilities, e.g. a rendezvous manager,which determines the actual network addresses of all team members. A front-end on top of the runtime environment allows users to control and configure the system. 3. Simulation environment: A developer can test collaborative applications in the simulation environment. It allows the developer to simulate different network characteristics on a single computer. Testing applications inside the simulation environment ensures stability for real usage and avoids performance problems, which otherwise would be detected very late in the development cycle. With the help of DreamTeam, we developed several groupware applications, e.g. a distance teaching environment [13]. We noticed that the main obstacles during the development are concerned with data distribution and consistency. Taking DreamTeam as a funding, we developed the platform DreamObjects, which offers a set of powerful services for shared data management. Both platforms together reduce the development costs for a collaborative application and even allow a developer to reuse existing single-user applications [12]. Fig. 1 shows a screenshot of a collaborative virtual environment (CVE). This CVE allows users to walk through virtual rooms and to furnish them collaboratively. The upper right window shows the session window, which contains a list of active sessions. The left window shows the top-view of the actual environment. The lower right window contains the 3D-view of the environment. Actually you can see the avatar of another user and that the local user picks the displayed table. A context menu allows the local user to move the table, put something on the table, change the appearance of the table, or resize it. Each modifiable element in this CVE is represented by one shared object. The shared objects were developed with DreamObjects.

Adaptive and Transparent Data Distribution Support

259

Fig. 1. Collaborative virtual environment

In the following sections we will describe, how we achieve a maximum of transparency concerning data distribution and consistency and how we used our platform during the development of the CVE.

4

Data Distribution

As already mentioned, we believe that none of the discussed distribution schemes suits well for every groupware application or even for single data objects of one application. The asymmetric distribution scheme fits well, when a user wants to introduce local data into a collaborative session. The replicated distribution scheme offers high responsiveness. A developer might choose the semi-replicated distribution scheme, if the data of an application can be divided into single logical pieces, e.g. a text document. As a user’s working style may change during a collaborative session, the semi-replicated distribution scheme should adapt these changes. We call such a distribution scheme adaptive semi-replicated. Compared to the replicated distribution scheme, an adaptive semi-replicated distribution scheme significantly reduces network traffic concerning data distribution and consistency. Therefore it also decreases the response time of a collaborative application. Our platform supports the asymmetric, the adaptive semi-replicated, and the replicated distribution scheme. We believe that these schemes cover all possible requirements of a collaborative application and offer the most advantages. In the following part we exactly describe, how we handle these three distribution schemes.

260

S. Lukosch

Similarly to the architectural styles for groupware applications like ALV [8], PAC [2] or multi-user MVC, which stems from [10], we divide a collaborative application into two object sets: 1. Shared data objects: These objects contain the data of an application. Let D denote the set of shared data objects. Md denotes the set of methods and Cd denotes the set of constructors offered by the class of a data object d ∈ D. A method call is denoted as d.m with m ∈ Md and a constructor call as d.c with c ∈ Cd . Finally the set MMd ⊆ Md denotes the subset of methods, which modify d ∈ D. 2. User interface objects: These objects control the user interface behaviour of an application. To achieve distribution transparency, we use substitutes [14]. This name stems from the substitution principle in object-oriented programming languages. A substitute replaces a developer-defined data object at runtime. The class of a substitute is a subclass of a developer-defined data object class and thus offers the same interface as the substituted data object. The substitute for a data object d ∈ D overwrites all methods in Md to add additional functionality, e.g. protocols for method call distribution or consistency. Inside an application, a developer can use a substitute like a local object. To reuse an existing or to define a new data object class the developer does not have to provide any additional classes. There are no limitations to the complexity of a shared object. It can be composed of other shared objects, which may even have different distribution schemes. The CVE (see. fig. 1), e.g., uses an asymmetrically distributed data object, which accesses a local file at the session initiating site to create the rooms. So local data is introduced into the session without distributing it. Usually, a user works in one room and thus does not need the data of all rooms. Therefore the rooms use a semi-replicated distribution scheme. Fig. 2 shows the class hierarchy for a sample shared object. To use the SampleObject class within our platform, the developer only has to – implement the SharedObject interface and – to define a MODIFYING METHODS field. The interface just serves as an identification within the runtime system and does not require to implement any method. The field specifies the set of modifying methods MMd . The substitute class SampleSubstitute can either be generated from the command-line or automatically by our runtime system. If the runtime system generates the substitute class, its bytecode is stored in an instance of the class Bytecode. This allows every participating site to create the substitute without generating its class again. The substitute class itself implements the Substitute interface, which contains special substitute methods for the runtime system. Each substitute class contains an instance of the SORepresentation class. This class contains the runtime representation of a shared object, i.e. its consistency configuration, its reference, the used constructor arguments, its bytecode, and

Adaptive and Transparent Data Distribution Support Toolkit-provided class Developer-defined class

SampleObject $ MODIFYING_METHODS : String[]

261

<> SharedObject

Toolkit-generated class

ConsistencyScheme

ConstructorArgs

SampleSubstitute

<> Substitute

SORepresentation

SharedObjectReference

Evaluator

Bytecode

ApplicationReference

Fig. 2. Class hierarchy of a sample shared object

the evaluator. The reference identifies a shared object among the different participating sites and among the applications of a collaborative session. The evaluator controls the distribution scheme of the shared object. To create a new shared data object, the developer has to call a special registration method and provide a runtime configuration for the data object. The runtime system informs all other sites about the registration, creates the corresponding substitute, uses the configuration to intialise it, and returns it, i.e. the shared data object, to the developer. If the substitute class is not available, the runtime system generates it. The configuration possibilities include: – Registration name: The registration name is a part of the reference. A developer may either specify a registration name on his own or leave it to the runtime environment to generate a registration name. When the developer defines an own registration name, he can use it to request the object from the runtime environment. This, e.g., allows an application at a latecomer’s site to request its initial data objects. – Constructor arguments: Let Ad.c denote the tuple of constructor arguments used for a constructor call d.c. By specifying Ad.c , the developer can choose, how the shared object will be initialised. – Consistency scheme: The consistency scheme defines the consistency configuration of a shared object (see section 5). – Evaluator : The evaluator controls the distribution of a shared object. We offer a set of pre-defined evaluators, which we distinguish between adaptive semi-replicated and static ones. The developer may choose between two static evaluators for an asymmetric and a replicated distribution scheme. Furthermore he may select between two adaptive evaluators for a basic semireplicated and a network-oriented semi-replicated distribution scheme. He may also define an own adaptive semi-replicated evaluator. Normally, changing from one distribution scheme to another affords significant reprogramming. Since the distribution scheme of an object is defined at its registration, a developer may use different instances of the same data class with different distribution schemes without any programming effort.

262

S. Lukosch

Based on the configuration, the runtime environment creates a representation for the new shared object. It contains the reference, the constructor arguments Ad.c , the consistency configuration, the bytecode of the substitute class, if it was generated at runtime, and the chosen evaluator of the shared object. To inform all other sites about the registration of a new object d ∈ D, the runtime system distributes a constructor call message that contains the representation of the shared object. With the help of the representation, each site can create the new shared data object. Let S denote the set of sites participating in a collaborative session and let sd denote the site which initiates the creation of a shared object d ∈ D. Whenever a site sd creates a new shared object, it distributes a constructor call message to all sites in S\{sd }. Depending on the selected distribution scheme each receiving site determines, if it becomes a data holder of the new object. The set DHd ⊆ S contains all data holders of an object. Each site s ∈ DHd holds the data of an object and thus can perform method calls locally. For all distribution schemes we have sd ∈ DHd . Depending on the distribution scheme we know: – Asymmetric: DHd = {sd } – Replicated: DHd = S – Semi-replicated: DHd ⊆ S In case of the semi-replicated distribution scheme, the evaluator of the object determines, if a site becomes a data holder of the new object or not. For faulttolerance the evaluator ensures |DHd | ≥ 2. In case of the basic semi-replicated distribution scheme the evaluator initially selects the two sites with the maximum bandwidth. In case of the network-oriented semi-replicated distribution scheme the evaluator checks, if S is partitioned in strongly connected subnets and in this case initially selects one site from every partition as data holder. To adapt a user’s working style in the distribution of a semi-replicated object, the set of data holders has to change at runtime. Whenever a site executes a method call on a semi-replicated object, the runtime system at this site passes some statistical values to the evaluator of the shared object. These values include the size of the method call arguments, the size of the result, and the size of the shared object in bytes. If the developer uses one of the predefined evaluators, he can, e.g., set maximum and minimum limits for the read load, write load, or overall load. When a load exceeds a maximum limit, the evaluator decides to request the data of the object. When a load falls below the minimum limits, the evaluator decides, that the local site does not need to be a data holder anymore. In the first case the runtime system selects a site in DHd , requests the state of the object, and adds the local site to DHd . In the second case the runtime system just removes the local site from the set DHd . It is a quite application- and network-dependent task to choose appropriate limits. Within a text editor, e.g., a part of the document should not be requested, if the user just takes a short look. For best results a developer can test an application within the simulation environment and empirically determine appropriate limits. If not, he can use default values.

Adaptive and Transparent Data Distribution Support

263

When a site receives a constructor call message, the evaluator determines, if the site becomes a data holder or not. If s ∈ DHd , the site executes the developerspecified constructor. Otherwise it executes the default constructor, which does not initialise the shared object. After executing the selected constructor, all sites in S\{sd } send an execution confirmation to sd . When sd received a confirmation from every site, it locally registers the new shared object and sends a registration permission to all other sites. When receiving the permission, these sites also register the new shared object. We use this two-phased protocol to avoid runtime failures. Similarly to constructor call messages, we distribute method call messages to propagate state changes of a shared object. If a site registered a new shared object directly after executing the constructor, it could execute a modifying method on the new object. Under certain circumstances other sites could receive the corresponding method call message before receiving the constructor call message. In this case such a site could not handle the method call, since it is directed to an unknown shared object. Fig. 3 shows a sample constructor call distribution. At each site a box indicates the time from constructor execution start till object registration. In this example the data object uses a semi-replicated distribution scheme. Depending on the corresponding local evaluator, s1 executes the default constructor and the two other sites execute the developer-selected constructor. Thus we have DHd = {s2 , s3 }.

d

s

s

s

2

1

3

d.c1 d.c0

CC

EC

EC RP

RP

t

d.c1

CC

t

t

CC: Constructor call, EC: Execution confirmation, RP: Registration permission

Fig. 3. Sample constructor call distribution

Before we describe the protocols that are used to distribute method call messages we show, how a developer can configure the consistency of a shared object and how he can trace changes of a shared object, e.g. to update the user interface. Both effect the protocols used for method call distribution.

264

5

S. Lukosch

Data Consistency

We offer two basic consistency schemes, an object-based and a method-based scheme. The object-based consistency scheme can be used to implement floor control mechanisms, which are often used in collaborative multimedia or conferencing applications [6]. In this section we describe the method-based consistency scheme, as this effects the way how method calls are distributed. Several sites may modify the same data object at the same time. This may lead to inconsistencies. If all conflicting method calls are executed under distributed mutual exclusion, consistency is guaranteed. Our method-based consistency scheme bases on this idea. Usually, not all method calls are conflicting. To allow concurrent method execution, if possible, we use multiple, distributed locks. We distinguish between intra-object consistency, which takes care of a single shared object, and inter-object consistency, which considers dependencies between different data objects. To configure the intra-object consistency of a shared object d ∈ D, a developer can group the methods Md into sets of mutually exclusive methods. Let EMj ⊆ Md denote an exclusive method set. All developer-defined exclusive method sets form the object exclusive method set OEMd = {EM1 , . . . , EMn }. The set Ld = {l1 , . . . , ln } with l1 ≤ l2 ≤ . . . ≤ ln contains all necessary locks for a shared object. With the help of the lock mapping function lm : OEMd → Ld , lm(EMj ) = lj , each lock lj is assigned to a set of exclusive methods EMj ∈ OEMd . Let sd.m ∈ S denote a site, which initiates a method call d.m. Whenever a site sd.m calls a method m ∈ Md , it requests all locks in the lock set of the method MLm = {lj |lj = lm(EMj ) ∧ m ∈ EMj }. To avoid deadlocks we use an approach that stems from resource allocation in operating systems [7]. The site sd.m requests the locks according to the order given by Ld . Inter-object consistency is necessary, if there are dependencies between different data objects, which make it necessary to block a method call to a shared object while a method call to another shared object is executed. Method call arguments may contain shared objects. The contained shared objects might be kept unchanged during the method call. Otherwise the method call might not have the same effect on every participating site. As these dependencies mostly emerge at runtime, the developer must be able to configure the inter-object consistency at runtime too. Let Ad.m denote the tuple of method call arguments used for a method call d.m. Before a substitute executes a method call d.m, it calls a developer-defined method with the shared objects contained in Ad.m . As result the developer-defined method has to return the inter-object consistency configuration for the method call d.m. The inter-object consistency configuration for a method call d.m is denoted as an inter-object exclusive method set IOEMd.m . A developer can select this set such that IOEMd.m ⊆ {EMdi |EMdi ⊆ Mdi ∧ di ∈ D ∧ di = d}.

Adaptive and Transparent Data Distribution Support

265

The sets EMdi contain the methods, which must not be executed by a site s = sd.m , while the latter executes the method call d.m. To use the inter-object consistency configuration for a method call d.m, the substitute for d first determines the lock set MLm . Then it evaluates the sets EMdi ∈ IOEMd.m . Based on the intra-object consistency configuration of di , the substitute determines the lock set for each method in EMdi and adds the contained locks to MLm . Finally, the method call initiating site sd.m requests all locks in MLm per object di according to the order defined by Ldi . So we avoid deadlocks again. To illustrate how these sets are used at runtime, we consider the CVE in fig. 1 and the shared objects for the table and the lamp. Let the shared object for the table offer a set of four methods, which either move the table to another position, put something on the table, change the appearance of the table, or resize the table. For the intra-object consistency of the table the developer specifies following sets: – – – –

OEMtable = {EMpos , EMapp , EMsize } EMpos = {move, put}, EMapp = {change}, EMsize = {resize} Ltable = {lpos , lapp , lsize } MLmove = {lpos }, MLput = {lpos }, MLchange = {lapp }, MLresize = {lsize }

The methods change and resize can be executed concurrently, since they modify independent properties. However, they are executed self-exclusively to allow only one user to change the corresponding property at a time. Since it should not be possible to put something on a table, while latter is moved and vice versa, the methods move and put are executed exclusively. Let a shared object for a lamp offer a set of three methods, which either move the lamp, darken the lamp, or lighten the lamp. For the intra-object consistency of the lamp the developer specifies following sets: – – – –

OEMlamp = {EMlum , EMpos } EMlum = {darken, lighten}, EMpos = {move} Llamp = {lpos , llum } MLdarken = {llum }, MLlighten = {llum }, MLmove = {lpos }

As the methods darken and lighten modify the same property, they are executed exclusively. The method move is executed self-exclusively. The developer also wants to achieve that the lamp stays in its position relative to the table, when latter is moved, i.e. its move method is executed. Using our intra-object consistency scheme, the method call initiating site would request the lock for the move method of the lamp, when the method is called and release the lock, after it finished. Thus another user could move the lamp during the movement of the table. To prevent this, the developer specifies a method, which in our example returns the following inter-object configuration: – IOEMtable.move = {EMlamp } – EMlamp = {move} with move ∈ Mlamp

266

S. Lukosch

Thus the substitute for the table adds the necessary locks for move ∈ Mlamp to the lock set M Lmove of move ∈ Mtable . After this, stable.move requests the contained locks. As stable.move now holds the necessary locks for both move methods, another site cannot move the lamp, before stable.move finishes the movement of the table. Thus the specified inter-object configuration achieves the desired effect.

6

Coupling

Different users manipulate the data objects of a collaborative application. We distribute method call messages to propagate these state changes among the participating sites. However, data objects may change unnoticed from a local application. Therefore an application must be able to react on remote changes and to apply them, e.g., to the user interface. Often these changes are propagated by simply posting an event to a listener object. A drawback of this approach is, that the listener object receives events in which it is not interested. Furthermore the listener object has to implement a special method to receive these events. Usually, this method is just a conditional code block, which cannot be easily maintained [15]. To overcome this situation, we offer a flexible object coupling service, which restricts the passed information to the needs of a developer-defined listener object and method. With the help of the object coupling service the conditional code block is divided into separate methods and thus maintenance is simplified. To use the object coupling service, the developer has to define which listener method has to be called by the runtime system, whenever a modifying method of a shared object was executed. For this reason the developer has to register a listener configuration within the runtime environment. If the developer is not longer interested in tracing the changes of an object, e.g. the content of the object is not longer displayed, he can unregister the configuration. Let cl denote the call listener object, ml the listener method, and m a modifying method of a shared object d ∈ D. A call listener configuration consists of cl, ml , m and a mapping, which allows the runtime system to select the arguments for the listener method ml . For each method m ∈ MMd the runtime system maintains a set of call listener configurations CLm . Whenever the developer registers a configuration for a modifying method, the runtime system adds this to CLm . It is removed from the set, whenever the developer unregisters the configuration. At runtime the mapping, which is contained in the call listener configuration, selects the arguments for the listener method from the method call arguments Ad.m , the method call result, and the method calling site sd.m . Let us, e.g., consider the method move ∈ Mtable . Atable.move is a 4-tuple, which contains the movement of the table in x-direction, y-direction, z-direction, and its rotation around the y-axis. To keep the 3D-view and the top-view consistent (see fig. 1), the developer has to apply the changes of the move method to the corresponding user interface objects. For this reason the developer registers two call listener configurations, one for each user interface object. The mapping

Adaptive and Transparent Data Distribution Support

267

for the 3D-view selects Atable.move as arguments for the listener method. The mapping for the top-view only selects the movement of the table in x-direction, z-direction, and its rotation around the y-axis, as the top-view does not display movements in y-direction.

7

Method Calls

As already mentioned, we distribute method call messages to propagate state changes to every participating site in a collaborative session. We distinguish between flat and nested method calls. Flat method calls do not call methods of the same or another shared object. Nested method calls are directed to a shared object, but also call methods of the same or another shared object. Since the protocols for both kinds are completely hidden in the substitute for a data object and the developer uses the substitute like a local object, we achieve a maximum of transparency for the developer. In the following sections we describe the protocols that we use to manage flat as well as nested method calls. 7.1

Flat Method Calls

One of the first protocols for replicated method calls can be found in [3]. Compared to this, our protocol can be used for a variety of distribution schemes. It is divided in the following phases: initialisation, pre-consistency, call-distribution, call-execution, result-distribution, post-consistency, and post-execution. Our protocol distinguishes between a method call that modifies an object and one that does not. In the following part, we exactly describe the single phases for a modifying method call. At the site sd.m the initialisation phase for a modifying method call is started by a user event. In this phase the substitute for the data object creates a method call message. This message contains a unique number for the method m ∈ Md , the method call arguments Ad.m , the reference of the shared object, and a timestamp ts d.m according to [11]. At every other site this phase is started by a method call message receipt. When the substitute creates the method call message, it checks, if Ad.m contains any shared objects and replaces them with their reference. When a site receives a method call message, it exchanges the references with the corresponding local shared object. This ensures that each site applies possible changes to the respective local instance of the shared objects in Ad.m . In the pre-consistency phase the method call initiating site sd.m requests all locks in MLm . When all locks were granted, the next phase is executed. In the call-distribution phase, the substitute at sd.m determines the recipients of the method call message and distributes the message. In section 6 we described that a developer may register arbitrary objects as call listeners for methods in MMd . Let CLsmi denote the set of call listeners at a site si . As CLsmi may vary from site to site, the runtime system also maintains a set SCLm ⊆ S that contains the sites si for which CLsmi contains at least one call listener.

268

S. Lukosch

Instead of simply multicasting the method call message to all participating sites, sd.m distributes the message to all sites in DHd ∪ SCLm . This is done to reduce network traffic. The sites in DHd receive the method call to keep the object consistent and the sites in SCLm to inform local call listeners. In the execution-phase each site in DHd executes the method call. All other sites, which have received the method call message, enter into a wait state, until they receive the result. In the result-distribution phase each site in DHd checks if it has to distribute the method call result. Since any site in DHd is able to distribute the result, but only one site has to distribute the result, the runtime system associates a write master wmd ∈ DHd with every shared object. At object registration, the runtime system sets wmd = sd . The write master distributes a method call result message to all sites in (SCLm ∪ {sd.m }) \ DHd . Thus all waiting sites receive the result and can leave their wait state. If the result contains any shared objects, these are handled in the same way as shared objects that are contained in the arguments of a method call. For fault-tolerance, wmd also sends a confirmation to all other data holders to inform them about the result distribution. If wmd leaves the running session before distributing the result, the runtime system deterministically selects a new write master, which distributes the method call result. The next phase is the post-consistency phase. When sd.m had to request any locks, all sites in DHd \ {sd.m , wmd } send an execution confirmation to sd.m . The write master does not send this confirmation, as it already confirmed the execution by distributing the method call result. At sd.m , a thread parallel to the execution thread collects these confirmations. If sd.m ∈ DHd , it notifies this thread locally. When this thread received all necessary confirmations, it releases all requested locks. Thus distributed mutual exclusion is guaranteed, as the locks are not released, before every data holding site executed the method call. In the post-execution phase each site si informs the call listeners in CLsmi . If the data object uses an adaptive semi-replicated distribution scheme, the method call initiating site calls the evaluator of the data object with some statistical values about the method call. This is done to reflect a user’s working style in the distribution of the data object (see section 4). Though we could use the described protocol to also handle a method call that does not modify an object, we use a different protocol to reduce network traffic. There are, e.g., differences in the call-distribution and call-execution phase. If the method call initiating site holds the data of the object, it does not distribute a method call message. It simply executes the method call locally. In the other case it distributes a method call message to only one data holding site. It is the task of the evaluator to determine this data holding site. If the object, e.g., uses our network-oriented semi-replicated distribution scheme, the evaluator chooses the data holder that is in the same partition as the method call initiating site.

Adaptive and Transparent Data Distribution Support

269

Fig. 4 shows, how the runtime system handles a sample modifying flat method call. At each site a box indicates the execution time of the method call. d.m

s

s

s

d.m

d.m

2

1

3

d.m LR LG MC

RSC

MCR

t

EC

t

t

MC: Method call, MCR: Method call result, EC: Execution confirmation, RSC: Result sent confirmation, LR: Lock request, LG: Lock grant

Fig. 4. Sample flat method call protocol, for m ∈ MMd , SCLm = {s1 , s2 , s3 }, DHd = {s2 , s3 }, and wmd = s2

7.2

Nested Method Calls

This section describes, how we handle nested method calls. Nested method calls are often used within data objects. Thus nested method call support is essential for a distributed object platform, which aims to simplify distributed object development. Our flat method call protocol cannot be used to support nested method calls. To illustrate this, we again consider the CVE and the move method of the table. Since this method modifies the content of the table, it is distributed to and executed by every data holder of the table. Therefore every data holding site of the table also executes the move method of the lamp and distributes a method call message to at least all data holders of the lamp. Thus each data holder of the lamp would receive and execute the move method as often as there are data holders for the table. Obviously this leads to a lot of unnecessary method call messages and of course to an undesired position of the lamp. Just imagine, what would happen, if the move method of the lamp would call another modifying method. A first naive idea to overcome this situation would be to identify and ignore a method call message, which was already executed. This would lead to the desired effect, but it still unnecessarily increases network traffic. So we developed a protocol, which only distributes a method call message if it must be distributed. Let di .mi ❀ dj .mj ❀ · · · ❀ dp .mp ❀ df .mf · · · denote a sequence of nested method calls, i.e. di .mi calls dj .mj and so on. If di .mi was not called by another method, it is called initiating. A method call dp .mp prior to df .mf is called

270

S. Lukosch

previous method call of df .mf , while df .mf is called follow-up method call of dp .mp . Principally an initiating method call di .mi is handled in the same way as a flat method call. There are only small extensions in the initialisation and post-execution phase. In the initialisation phase the substitute of di creates a method stack M Sdi .mi , pushes di .mi on the stack, and registers it within the runtime environment using the timestamp tsdi .mi . The stack allows a substitute to determine the previous method call of a method call and therefore if a method call is a follow-up method call or not. In the post-execution phase the substitute of an initiating method call unregisters the stack. The protocol for a follow-up method call is executed in the execution phase of its previous method call. It is also divided in the phases: initialisation, pre-consistency, call-distribution, call-execution, result-distribution, postconsistency, and post-execution. Again our protocol distinguishes between a follow-up method call that does modify an object and one that does not. In the following part we exactly describe the single phases for a modifying followup method call. In the initialisation phase of a modifying follow-up method call df .mf a site either executes the previous method call dp .mp or received a method call message for df .mf . The substitute for df pushes df .mf on the method stack M Sdi .mi and increments a follow-up counter f cdi .mi . If a site is executing dp .mp , it creates a method call message for df .mf . Since a follow-up method call can easily be identified with the follow-up counter f cdi .mi and the timestamp of the initiating method call tsdi .mi , the substitute of df includes the both in the follow-up method call message. The nested method call protocol further requires that each site knows the initiating method call di .mi and the previous method call dp .mp of a follow-up method call. Thus, a description for both method calls is included in the method call message for df .mf . Compared to a normal method call message, the description only contains the timestamp of a method call, the reference of the shared object, and the number of the method. It does not contain the arguments and therefore its size is significantly reduced. In the pre-consistency phase the method call initiating site sdi .mi requests all necessary locks for df .mf . Due to the inter-object consistency configuration of previous method calls sdi .mi might already hold some locks. Therefore it only requests the locks in M Lmf that it does not hold yet. After the locks were granted, it distributes a method call start permit message to all sites in DHdf \ {sdi .mi }. This message is omitted, when it was not necessary to request any locks. When sdi .mi has to request some locks, all sites in DHdf \ {sdi .mi } enter into a wait state until they receive the necessary start permit for df .mf . This ensures that a site in DHdf does not execute the follow-up method call, before the necessary locks were granted. So possible inconsistencies are avoided. It is the task of sdi .mi to request necessary locks, since it may already hold some of the necessary locks. If another site than sdi .mi requested the locks for df .mf , this could lead to a deadlock.

Adaptive and Transparent Data Distribution Support

271

In the call-distribution phase the write master wmdp distributes the method call message for df .mf to the following sites (SCLmf ∪ DHdf ∪ {sdi .mi }) \ DHdp . The method call is sent to sdi .mi , since this site may have to request necessary locks. It is sent to all sites in DHdf to keep df consistent and to all sites in SCLmf , to inform the call listener at these sites. Finally, it is not sent to any site in DHdp , since these already execute df .mf . If the previous object dp , e.g., uses a replicated distribution scheme, the follow-up call message is not distributed at all. Besides preserving the intention of the method call, our protocol, compared to the naive approach, reduces the number of exchanged method call messages by |DHdp |. When the write master wmdp had to distribute the method call message, it also distributes a confirmation to all other sites in DHdp to inform them about the distribution. This is done for fault-tolerance. If wmd leaves the running session before distributing the method call message, the runtime system deterministically selects a new write master that subsequently distributes the method call message. However, when a site in DHdp receives the confirmation, it knows that the method call message was distributed and thus can dismiss the task to distribute method call. Now each site in DHdf executes the follow-up method call. All sites outside of DHdf which either received the method call message for df .mf or are executing dp .mp enter into a wait state, until they receive the result. In the result-distribution phase the write master wmdf distributes the result of the follow-up method call to all sites in (SCLmf ∪ DHdp ∪ {sdi .mi }) \ DHdf . The result is sent to all sites in SCLmf to inform the call listener at these sites. It is sent to all sites in DHdp and to sdi .mi , since they may wait for the result. Of course, the result is not sent to any site in DHdf , since these sites were able to execute the follow-up method call locally. When the write master wmdf had to distribute the result, it also sends a confirmation to all sites in DHdf to inform them about the distribution. This is done for the same reason as during a modifying flat method call. In the post-consistency phase all sites in DHdf \ {sdi .mi , wmdf } send an execution confirmation to sdi .mi . Again the write master does not send this confirmation, as it already confirmed the execution by distributing the result message. The other sites omit this message, when sdi .mi did not have to request any locks for the follow-up method call df .mf . Finally, in the post-execution phase every site that was involved in the protocol for the follow-up method call either executed the follow-up method call or received the method call result. At each site the runtime system informs the call listeners in CLmf and the substitute for df removes the follow-up method call from the method stack MSdi .mi . At the method call initiating site sdi .mi the substitute for df calls the corresponding evaluator, if df uses an adaptive

272

S. Lukosch

semi-replicated distribution scheme. Again this is done to reflect a user’s working style in the distribution of the data object (see section 4). We could use the described protocol to also handle a follow-up method call that does not modify an object. However, we use a different protocol to reduce network traffic. There are, e.g., differences in the call-distribution and callexecution phase. If every site that is executing the previous method call dp .mp is a data holder of df , it is not necessary to distribute a method call message for df .mf . Every site can execute the method call locally. Fig. 5 shows a simplified diagram of a sample, nested method call protocol for two modifying method calls. It does not contain the messages that are exchanged to request or grant necessary locks. Assume that s1 would request the locks before distributing the method call d1 .m1 and before sending the start permit for d2 .m2 . d1 .m1

s

s

1

d1.m 1

MC(m 1)

s

2

3

d1.m 1

d1.m 1 d2.m 2

Queue d2.m 2

d2.m 2 MCSC(m 2)

MC(m 2) MCSP(m 2)

Dequeue d2.m 2

MCR(m 2)

MCR(m 1)

RSC(m 1) EC(m 1)

t

t

t

MC: Method call, MCR: Method call result, MCSP: Method call start permit, MCSC: Method call sent confirmation, EC: Execution confirmation, RSC: Result sent confirmation

Fig. 5. Sample nested method call protocol, for d1 .m1 ❀ d2 .m2 , DHd1 = {s2 , s3 }, DHd2 = {s3 }, wmd1 = s2 , wmd2 = s3

8

Conclusion

In this paper we described a development platform for shared data objects. It offers a variety of distribution schemes and allows a developer to individually control the distribution scheme of a shared data object. In dependence of the properties of a data object and the corresponding collaborative application a developer may choose the appropriate distribution scheme for a particular data object. Since the substitute concept hides necessary mechanisms to manage the shared data, our platform achieves a maximum of transparency for the developer. After an initial configuration, a developer can use a shared data object like a

Adaptive and Transparent Data Distribution Support

273

local object and does not have to worry about, how the platform distributes the data object and how it achieves consistency. We focused on the protocols and concepts that we use to distribute the shared data objects and keep them consistent. However, we offer further services for shared data management, e.g., a decentral latecomer support, which either handles the transfer of a session state or replays it, or a persistency service, which asynchronously distributes a session state among group members. Both services are necessary to completely support the developer of a groupware application and a collaborating group during synchronous and asynchronous work. Nevertheless, there are still open issues. We want to extend our concept to support the developer if he has to merge data objects. This might be necessary, when the network, which connects the collaborating users, crashes and the users keep on working. We also intend to analyse the effects of different settings in an adaptive semi-replicated evaluator. So we want to provide instructions for a developer, on how to choose the best evaluator for each data object of a collaborative application.

References [1] Gary E. Anderson, T.C. Nicholas Graham, and Timtohy N. Wright. Dragonfly: Linking Conceptual and Implementation Architectures of Multiuser Interactive Systems. In Proceedings of the 22nd International Conference on Software Engineering, ICSE 2000, pages 252–261, Limerick, Irland, June 2000. [2] Ga¨elle Calvary, Jo¨elle Coutaz, and Laurence Nigay. From Single-User Architectural Design to PAC∗ : a Generic Software Architecture Model for CSCW. In Human Factors in Computing Systems: CHI’97 Conference Proceedings, pages 242–249, 1997. [3] Eric C. Cooper. Replicated Distributed Programs. In Proceedings of the 10th ACM Symposium on Operating Systems Principles, pages 63–78, Orcas Island, Washington, USA, 1985. [4] Prasun Dewan. Multiuser Architectures. In Proceedings of IFIP WG2.7 Working Conference on Engineering for Human-Computer Communication, pages 247–270, August 1996. [5] Prasun Dewan and Rajiv Choudhary. A High-Level and Flexible Framework for Implementing Multiuser Interfaces. ACM Transactions on Information Systems, 10(4):345–380, October 1992. [6] Hans-Peter Dommel and J.J. Garcia-Luna-Aceves. Floor control for multimedia conferencing and collaboration. Multimedia Systems, 5(1):23–38, 1997. [7] J.W. Havender. Avoiding deadlock in multitasking systems. IBM Systems Journal, 7(2):74–84, 1968. [8] Ralph D. Hill. The Abstraction-Link-View Paradigm: Using Constraints to connect User Interfaces to Applications. In Human Factors in Computing Systems: CHI’92 Conference Proceedings, pages 335–342, Monterey, CA, USA, May 1992. [9] Ralph D. Hill, Tom Brinck, Steven L. Rohall, John F. Patterson, and Wayne Wilne. The Rendezvous architecture and language for constructing multiuser applications. ACM Transactions on Computer-Human Interaction, 1(2):81–125, June 1994.

274

S. Lukosch

[10] Glenn E. Krasner and Stephen T. Pope. A Cookbook for Using the Model-ViewController User Interface Paradigm in Smalltalk-80. Journal of Object-Oriented Programming, 1(3):26–49, August 1988. [11] Leslie Lamport. Time, Clocks, and the Ordering of Events in a Distributed System. Communications of the ACM, 21(7), July 1978. [12] 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. [13] 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. [14] 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. [15] Brad A. Myers. Separating Application Code from Toolkits: Eliminating the Spaghetti of Call-Backs. In Proceedings of the 4th annual ACM symposium on User interface software and technology, pages 211–220, Hilton Head, South Carolina, USA, November 1991. [16] Theodore O’Grady. Flexible Data Sharing in a Groupware Toolkit. Master’s thesis, University of Calgary, Department of Computer Science, Calgary, Alberta, Canada, November 1996. [17] John F. Patterson. A Taxonomy of Architectures for Synchronous Groupware Architectures. ACM SIGOIS Bulletin Special Issue: Papers of the CSCW’94 Workshops, 15(3):27–29, April 1995. [18] 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. [19] J¨ org Roth. ’DreamTeam’: A Platform for Synchronous Collaborative Applications. AI & Society, 14(1):98–119, March 2000. [20] J¨ org Roth and Claus Unger. An extensible classification model for distribution architectures of synchronous groupware. In Proceedings of the Fourth International Conference on the Design of Cooperative Systems (COOP2000), Sophia Antipolis, France, May 2000. IOS Press. [21] Christian Schuckmann, Lutz Kirchner, Jan Sch¨ ummer, and J¨ org M. Haake. Designing object-oriented synchronous groupware with COAST. In Proceedings of the ACM 1996 Conference on Computer Supported Cooperative Work, pages 30– 38, Cambridge, MA, USA, July 1996. [22] Jorge Sim˜ ao, Henrique J. Domingos, J. Legatheaux Martins, and Nuno Pregui¸ca. Supporting Synchronous Groupware with Peer Object-Groups. In Proceedings of the Third USENIX Conference on Object-Oriented Technologies (COOTS), Portland, Oregon, USA, June 1997. [23] Robert Strom, Guruduth Banavar, Kevan Miller, Atul Prakash, and Michael Ward. Concurrency Control and View Notification Algorithms for Collaborative Replicated Objects. IEEE Transactions on Computers, 47(4):458–471, April 1998. [24] Tore Urnes and T.C. Nicholas Graham. Flexibly Mapping Synchronous Groupware Architectures to Distributed Implementations. In Proceedings of Design, Specification and Implementation of Interactive Systems (DSV-IS’99), 1999.

COPSE-Web: An Infrastructure for Developing Web-Based Groupware Applications 1

2

José Maria N. David and Marcos R.S. Borges 1

COPPE-PESC / UFRJ & Faculdade Ruy Barbosa / BA [email protected] 2 NCE & IM Federal University of Rio de Janeiro [email protected]

Abstract. The main approach for the development of groupware applications presented in the literature, has been the use of toolkits. However, at least in the case of groupware applications the main advantages of toolkits have not been fully accomplished. They don’t offer the necessary flexibility to address the social aspects related to the interaction of geographically dispersed groups. Although the web is the main application environment for current applications, only recent toolkits have been able to support the groupware development for the web. In this paper, we discuss and describe the work carried out in converting COPSE to COPSE-Web, an infrastructure for the development of web-based groupware applications. We used this work to discuss the requirements, the architectural and implementation issues in the design of an integrated groupware toolkit. We illustrate the advantages of our approach by describing the development of the environment’s administration tool. Keywords: World Wide Web, CSCW framework, groupware toolkit, Webbased development.

1

Introduction

The main approach for the development of groupware applications, presented in the literature, has been the use of Toolkits. An appropriate toolkit saves time and programming efforts. Moreover, it allows an easy integration of different tools under the same environment. These issues have been the motivating factor for the development of general toolkits, such as Groupkit [12] and specific domain development environments, like Habanero [13], amongst others. In the case of groupware applications, however, the main advantages of toolkits have not been fully exploited. Besides not offering the necessary flexibility to support cooperative activities, some tools limit the scope of the application [5]. Also, most tools do not address the social aspects related to the interaction of the geographically dispersed groups. Under a different perspective, although the web is the main application environment for current applications, only recent toolkits have been able

J.M. Haake and J.A. Pino (Eds.): CRIWG 2002, LNCS 2440, pp. 275–284, 2002. © Springer-Verlag Berlin Heidelberg 2002

276

J.M.N. David and M.R.S. Borges

to support the groupware development for the web. To sum up, very few toolkits are available which can satisfy the requirements for a complex groupware, without extensive programming. We have been developing groupware applications using COPSE1 infrastructure [4, 18]. COPSE is a comprehensive infrastructure based on a client-server architecture. It has some nice features that not only provide facilities for the development of new applications, but also allow their full integration with applications already present in the environment [6]. However, the COPSE infrastructure is not prepared for a webbased application development and lacks many important features, which will be required when developing the complex asynchronous applications. In this paper, we discuss and describe the work carried out to convert COPSE to COPSE-Web, an infrastructure designed for the development of web-based groupware applications. Although the conversion is our main motivation, we used this work to discuss the requirements, the architectural and implementation issues in the design of an integrated groupware toolkit. We illustrate the advantages of our approach by describing the development of the environment’s administration tool. In section 2 we discuss the requirements for a web-based and comprehensive groupware development environment. Then, in Section 3, the architecture of a groupware infrastructure designed to support these requirements is proposed. In section 4, the implementation issues of the proposed architecture are presented. Section 5 we make a brief analysis of other toolkits. The use of the resulting infrastructure is illustrated by the development of an application, described in Section 6, and finally Section 7 concludes the paper.

2

Requirements for Web-Based Groupware Development

There are several toolkits, which support the development of non-web groupware applications, and they very seldom allow these applications to be implemented without an extensive programming effort. In most cases, a specific application solution, such as browsing [14], communication tools, meetings support tools, text edition tools, is implemented. Unfortunately, these applications are built frequently without focusing on the complexities of groupware activities and addressing the inherent needs of a groupware application, for example, integration with other tools. Most toolkits do not offer an open source code, which would permit customization and extension to support different group’s needs. The group’s participants usually do not have experience in collaborating. Moreover, new groups of expertise need to be invited to contribute in different locations. That is, the development of these systems demands different roles and competencies to be accomplished. In addition, a high level of flexibility is needed through the extendable components, protocols, services, which could improve the collaboration results among certain heterogeneous groups. Other points that should be addressed when designing web-based groupware applications are discussed in [15]. In [14] some issues related to the design of Collaborative Browsing systems is presented in a five-dimensions framework, which points out some aspects that should be considered when designing such systems. 1

COPSE – COllaborative Project Support Environment

COPSE-Web: An Infrastructure

277

The increasing demand for network services and also the number of available webbased applications have given evidence to the fact that the Internet is a convenient infrastructure to be accessed in order to look for different information, and deployed mainly in cooperative activities [1]. Thus, we can suggest that web-based technologies can be used not only to support the development of groupware applications, but also the integration of these tools and its interoperability during the group’s activities. The client-server model has already shown advantages when deployed in a groupware architecture design and implementation [10]. However, web applications currently do not make a clear separation between the presentation of the information, and the control and logic of the groupware applications. On the contrary, they use technology that restricts their scalability and portability. Considering the inherent complexities of CSCW systems, the technology deployed by them is not adequate enough to be used by groupware applications.

3

The COPSE-Web Architecture

COPSE environment can be considered as the first step in the direction of supplying a collaborative work environment and a tool framework for the cooperative development of software. Its infrastructure supports not only synchronous but also asynchronous activities, which are accomplished in the environment. Furthermore, a tool framework is supplied, allowing the development of groupware applications to be coupled to the environment [5, 6]. This current version is a Java-based application, which does not implement a object-oriented middleware like CORBA, for instance. All integration issues between applications rely on group memory [6]. Aiming at supporting the development of web-based groupware applications this environment was extended to fulfill the requirements to support web technologies. The proposed architecture for a groupware environment in the web should allow any client running a browser to have the ability to connect to any available application running in the environment. Such applications and other web services do not necessarily need to be running on the same web server. Users need only be authenticated in the environment through a single logon, so that they can execute the available groupware applications at that time. The architecture we have designed is illustrated in Figure 1. COPSE-Web server is the key component of the designed infrastructure. Each server has an associated user administration module. Besides supplying relative information about users running an application, this module also communicates with a trusted directory service server installed in the network. Thus, the additional functionality related to the applications and participant’s information could be managed, such as the set of cooperative tools started by each participant, or interested topics and subjects. Each application running in a COPSE-Web server has the support of a group memory, which stores specific information related to the application and the activity that is being supported. For example, discussion support tools and elicitation process support tools could provide specific components to measure the participation and contribution rate for each participant [2, 4]. These components are related to each

278

J.M.N. David and M.R.S. Borges

GM

JDBC

GM

GM

JDBC

Application Server

JDBC

Application Server

Application Server

... Web COPSE Server Server

JDBC

Adm.

GM

Web Server

COPSE Server

JDBC

Adm.

GM

Web COPSE Server Server

Adm.

JDBC

GM

Directory Services

... Fig. 1. A groupware architecture in the Web

activity carried out by the participants. COPSE servers have also group memories attached to them, which are responsible for the storage of common information to any applications and any user in the environment.

4

Implementation Issues

One of the main reasons for the selection of COPSE as the infrastructure to be extended for this project was the available open source code and existing documentation. Other characteristics also contributed to the extension of this infrastructure, for instance: (i) it is a tool that allows the integration of other CSCW applications and allows customizations in other functionalities of these applications; (ii) it offers an open code making some possible adaptations and extensions to the group needs, whilst keeping portability, scalability and interoperability of the applications; (iii) it was originally developed in Java programming language. In this context, we also needed an architecture model that could be applied so that the system’s functionalities could be adequately separated. Moreover, we should moreover build a cohesive and significant set of functionalities necessary to support the group activities. Through this model we should be able to provide the flexibility in software development activities. Analyzing the Model-View-Controller (MVC) model, it was possible to visualize some benefits that the implementation of this model would bring to this project. In the view layer, the pages for information exhibition in the client browser are found. These pages can be codified in HTML, XML, JSP, or another presentation language can be used on web. How the information is obtained and processed is not its function. In the control and model layers, mechanisms capable of controlling and modeling data flow are found respectively. The model layer is responsible for activities such as, data management and database queries. The control layer is responsible for the interaction between the front-end (View) and the back-end (Model). The decisions process related to different presentation modes are kept in this layer [8].

COPSE-Web: An Infrastructure

279

However, it would be necessary to choose a technology that could be used together with the previously designed COPSE architecture [5, 6]. Only WWW and pure Javabased applications do not offer the necessary support for the implementation of this architecture and the designed mechanisms. One example of this is the COPSE-Web servers’ initialization task. There was a need to use technology capable of supporting the remote start and stop of different COPSE-Web application servers. Through the analysis of the current web technologies, we decided to use Java Server Pages (JSP) technology to provide not only a user session management service, but also a dynamic functionality to the system providing personalized web page contents [8]. While this technology provides a more substantial support for asynchronous groupware applications, it is not suitable for synchronous applications when changes in any information (model) are made and have to be sent to client browser (view). Furthermore, it would require frequent pages reload by each group participant. Then, applets were designed in COPSE-Web to be used in synchronous groupware applications. For the development of COPSE-Web architecture, we used a servlets centered approach for the design of applications running in the environment. In the extended architecture a set of servlets can accomplish some activities drafted initially for the User Session Management module (Figure 2), in which each user can establish a connection with the project server through environment authentication. Thus, important user information, such as information about the tools started by them, is directed to the Web Server GUI Servlet, and soon after to the Web Server GUI JSP in order to constructs the web page. Tools launched by each user establish a connection to secondary servers (special servers or document server). Different tools share the same document set in the Document Server. The Process Server is responsible for the execution of collaboration process and for the association to a project [5, 6, 17]. COPSE-Web environment implements not only a Project Server – responsible also for the database maintenance of relative documents to the projects – but also other servers, namely Special Servers, which can be found in the data layer (Figure 2). Dias and Borges [6] present some servers coupled to the environment, and likewise in [17] Santoro and Borges present some adaptations both in the COPSE conception and implementation. In this architecture, we propose the development of another server: the Profiles and Awareness Server. This server is directly associated with the profile mechanisms shown in the Figure 2. It also offers generic awareness components for the environment, or specific awareness components for the development of groupware applications. The implementation of this server and the mechanisms associated to each User Session Management is part of an awareness service, which is under development and is to be coupled to the environment at a later date.

5

Related Work

Groupkit [12] was designed to support the development of synchronous CSCW applications. However, we observed that several works like this don't contemplate the

280

J.M.N. David and M.R.S. Borges

...

Web Browser User #1

Web Browser User #m

Presentation Tier (VIEW)

Web Server GUI (JSP)

Web Server GUI (Servlet)

...

User #1

User Session Manag.

User #m

User Session Manag.

... Tool #1

... Tool #n

Profile Mechanism #1

Special Servers Process Server

Other Servers

Profile Mechanism #m

Profiles & Awareness Server

Tool #k

Application Tier (CONTROLLER)

Tool #w

Document Server

COPSE - Project Server

Data Tier (MODEL)

Project Database

Fig. 2. Architecture of COPSE-Web (adapted from [6])

users’ fundamental needs of groupware application. They support neither the transitions between synchronous and asynchronous activities, nor the dynamic support to group awareness [3, 4, 5, 11]. MetaWeb [21] toolkit provides support for synchronous web-based groupware applications. The development of applications are based on three concepts: ‘users’ interact with the toolkit, ‘locations’ are places where the group interaction takes place and ‘sessions’ is a medium through which better group communication can take place. Furthermore, it provides support for access control but a single server approach does not allow interoperability between different needed applications to support cooperative work. Promondia [10] is a Java-based framework that provides real-time group communication for groupware applications in the web. This functionality was implemented as Java applets, which are loaded from any Promondia server. Several communications tools such as chat, shared white board, voting and surveys are provided. This framework does not support other group activities and the infrastructure is proposed only to support group communication for WWW. Using the metaphor of rooms, TeamWave Workplace [11] allows tools to be placed on a shared space and customized according to the group’s needs. However, all participants share the same information and events. COPSE-Web provides resources to configure shared workspaces with mandatory awareness components. Each group’s participant can accomplish an individual workspace configuration.

COPSE-Web: An Infrastructure

281

Although considering integration issues of web technologies, ESCOT [7] project supports group activities in order to compose lessons in a specific domain. As in this project, the approach proposed in COPSE-Web suggests that a multidisciplinary activity can be supported through components reuse and their interoperability. NESSIE [16], PoliAwaC [20] and AREA [9] also give us some directions about some aspects to be included in the software requirements specification of the awareness service in COPSE-Web. Our proposal is focused on ‘profile of interest’ to filter awareness components, and as a result, to determine coordination actions. WWG [15] is a distributed and decentralized infrastructure, which supports distributed group learning and team work activities. This infrastructure is based on event distribution mechanisms that provide an information exchange with many geographically dispersed groups. WWG does not describe how information is presented to users, but describes how different interfaces are provided in order to collect and to propagate events, and to notify the participants about their activities. This functionality has inspired us to design a more adequate event mechanism, which is to be used in the COPSE-Web awareness service.

6

Applications

Aiming at evaluating issues that have been discussed previously, an application was developed according to the concepts and to the architecture described above. This application provides administration services to the environment. It also communicates with the administration server that centralizes the users’ data. Through a directory service, this server allows a single logon in the environment, from the moment the user is registered by the use of administration module. Each user has access to the information and the user’s properties (user name, password, email address, user projects and profiles, for example), for reading purposes only, depending on the access control rights assigned by the administrator of the COPSE-Web environment. In the main COPSE-Web options menu some items were implemented, others are still under development. Among the implemented items we can find the ‘Servers’ menu item, which allows to start/stop different legacy application servers available in the environment. By selecting the ‘Tools’ menu item, each participant can start any COPSE-Web enabled groupware applications. The ‘Awareness’ item allows any user to load generic awareness components in the shared workspace, such as the active user list and active cooperative tools in each group participant workspace. Other specific awareness components related to the groupware application are only shown in each application menu toolbar. For example, in a pre-meeting application, each participant can start an awareness component showing the invited members and their position about the coordinator’s invitation. In addition, they can launch the participameter component [2]. These awareness components are still under development as part of another groupware application to support pre-meeting activities in the web. In the ‘Communication’ menu item, chat and message tool for example, can be started in the common workspace. In the ‘Documents’ menu item, which is at present still under development, is a document database administration tool, this can be started in order to manage all information produced by the group in the form of documents in the environment.

282

J.M.N. David and M.R.S. Borges

Legacy applications have already been integrated to the COPSE-Web environment and can be launched by the use of main option menu. In the earlier versions some of these applications were developed by the use of COPSE tool framework and were not extended to the COPSE environment. Others have already been developed using available tools in COPSE environment and they have already been integrated to the environment, such as Editex [18] – Cooperative Text Editor -, and the CEPE2 [19] Cooperative Editor of Process Elicitation. To be fully integrated to the environment and web browsers, they should be extended to the COPSE-Web environment according to the model.

7

Conclusions

When we planned to design this architecture, we tried mainly to minimize the client’s complex processing procedure, just leaving the activities related to the information presentation in the front-end. On the server’s side, we can find the application control functions and the data manipulation associated to the applications. We also noticed that by using a servlets centered approach, groupware applications could be developed in an evolutionary way, while preserving the inherent dynamic behavior of web-based applications. That is, new interface components and new web technologies could be developed, and become available to the user. At the same time, control and data management related mechanisms could evolve without changing applications. In these applications, sequences of actions can frequently be interrupted, demanding appropriate treatment by the technology used. This was one of the reasons why we chose JSP technology. As this technology provides a dynamic functionality to COPSE-Web server, applets technology provides interactive functionality to a special-purpose synchronous groupware application. Furthermore, by using this architecture, we could preserve legacy groupware applications, which were developed according to the concepts of previous COPSE versions, and it was not possible to change these applications at that time. In the future, we are planning to extend their functionalities to web browsers. Some issues related to the distributed groupware architecture were not specified and we are also investigating how to integrate different applications in order to establish adequate communication between them, without an intensive programming effort. Acknowledgments. This work has been partially supported by a grant from Faculdade Ruy Barbosa (Salvador / BA – Brazil).

2

In a second version of the system CEPE, new functionalities are being built, but according to the previous COPSE version.

COPSE-Web: An Infrastructure

283

References [1] [2] [3] [4] [5] [6] [7] [8] [9]

[10] [11]

[12] [13] [14] [15] [16] [17]

[18]

Bentley, R., Horstmann, T., Trevor, J., “The World Wide Web as enabling technology for CSCW: The case of BSCW”. In: Computer-Supported Cooperative Work: Special Issue on CSCW and the Web, vol. 6., 1997, pp. 111–134. Borges, M. R. S. and Pino, J. A. , “Awareness Mechanisms for Coordination in th Asynchronous CSCW”. In: Proc. 9 Workshop on Information Technologies and Systems (WITS 1999), Charlotte, North Carolina, Dec. 1999, pp. 69–74. David, J. M. N., Borges, M. R. S., “Improving the Selectivity of Awareness Information in Groupware Applications”. In: Proc. of the Sixth International Conference on CSCW in Design, London, Ontario, Canada, Jul. 2001, pp. 41–46. David, J. M. N., Borges, M. R. S., “Selectivity of Awareness Components in Asynchronous CSCW Environments”. In: Proc. of Seventh International Workshop on Groupware (CRIWG’01), Darmstadt, Germany, Sept. 2001, pp. 115–124. Dias, M. S., “COPSE – Um Ambiente de Suporte ao Projeto Cooperativo de Software”. Master Dissertation in Portuguese. COPPE/UFRJ, Rio de Janeiro, RJ, Brazil, Jul. 1998. Dias, M. S. and Borges, M. R. S., “Development of Groupware Systems with the COPSE th Infrastructure”. In: Proc. of 5 International Workshop on Groupware (CRIWG’99), Cancún, México, Sept. 1999, pp.278–285. ESCOT, 2002, URL http://www.escot.org (web page as of May 2002). Fields, D. K. and Kolb, M. A., “Web Development with JavaServer Pages”, Manning Publications Co., 2000. Fuchs, L., “AREA: A Cross-Application Notification Service for Groupware”. In: Proceedings of the Sixth European Conference on Computer-Supported Cooperative Work (ECSCW’99), Copenhagen, Denmark, Kluwer Academic Publishers, Sept. 1999, pp. 61–80. Gall, U. and Hauck, F., “Promondia: A Java-Based Framework for Real-time Group Communication in the Web”. In: Proc. of Sixth International World Wide Web Conference, Santa Clara, California, USA, Apr., 1997. Greenberg, S. and Roseman, M., “Using a Room Metaphor to Ease Transitions in Groupware”. Research report 98/611/02, Department of Computer Science, University of Calgary, Calgary, Alberta, Canada, Jan., 1998. Groupkit, 2000, URL http://www.cpsc.ucalgary.ca/redirect/grouplab/projects/groupkit/ (web page as of July 2000) Habanero, 2001, URL: http://habanero.ncsa.uiuc.edu/habanero/ (web page as of Jan. 2001). Rivera, G. J. H., Courtiat, J. and Villemur, “A Design Framework for Collaborative th Browsing”. In: IEEE 10 Int. Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE’01), 2001. Marquès, J. M. and Navarro, L., “WWG: a Wide-Area Infrastructure for Group Work”. th In: IEEE 10 Int. Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE’01), 2001. Prinz, W., “NESSIE: An Awareness Environment for Cooperative Settings”, In: Proc. of the Sixth European Conference on Computer Supported Cooperative Work (ECSCW’99), Copenhagen, Denmark, Kluwer Academic Publishers, Sept. 1999, pp. 391–410. Santoro, F. M., Borges, M. R. S. and dos Santos, N., “An Infrastructure to Support the Development of Collaborative Project-Based Learning Environments”. In: Proc. of Sixth International Workshop on Groupware (CRIWG’00), Madeira, Portugal, Oct. 2000, pp.78-85. Santoro, F. M., “Um Modelo de Cooperação para Aprendizagem Baseada em Projetos”. Phd Thesis, In Portuguese, COPPE/UFRJ, Rio de Janeiro, RJ, Brazil, Dec. 2001.

284

J.M.N. David and M.R.S. Borges

[19] Santoro, F., Borges, M. R. S., Pino, J. A., “CEPE: Cooperative Editor for Processes Elicitation”. In: Proc. of the Collaboration Systems and Technology Track of the ThirtyThird Hawaii Int. Conference on System Sciences (HICSS-33), Maui Island, Hawaii, USA, Jan. 2000 (in CD-ROM). [20] Sohlenkamp, M., Prinz, W., Fuchs, L., “POLIAwaC: Design and Evaluation of an Awareness Enhanced Groupware Client”. AI & Society, vol. 14, 2000, pp. 31–47. [21] Trevor, J., Koch, T. and Woetzel, G., “MetaWeb: Bringing synchronous groupware to the World Wide Web”. In: Proceedings of the Fifth European Conference on ComputerSupported Cooperative Work (ECSCW’97), Lancaster, UK, Kluwer Academic Publishers, Sept. 1997.

Author Index

Alarc´ on, Rosa 168 Alves, Gustavo R. C. Antunes, Pedro 47

25

Bacelo Blois, Ana P.T. 134 Baloian, Nelson 35 Becker, Karin 134 Berges, Alexander 35 Borges, Marcos R.S. 222, 275 Buschmann, Stephan 35 Cheriet, Mohamed 245 Collazos, C´esar A. 203 Costa, Carlos J. 47 Costa, Ricardo 25 Covarrubias, Eliana 189 David, Jos´e M.N. 275 Dawabi, Peter 93 Decouchant, Dominique Desbiens, Jocelyn 245

Haake, J¨ org M. 70, 232 Hardings, Jens 35 Herrera, Oriel 114 Hine, Nick 25 Hoppe, Heinz Ulrich 35 Khlifi, Hechmi

245

Leiva-Lobos, Edmundo P. 189 Leyva L´ opez, Juan Carlos 61 L´ opez Elizalde, Dina Esperanza Lukosch, Stephan 255 Luther, Wolfram 35 Mart´ınez-Enr´ıquez, Ana M. 147 Mendes de Araujo, Renata 222 Mor´ an, Alberto L. 147

147

Favela, Jesus 147 Fern´ andez, Alejandro 232 Ferreira, J.M. Martins 25 Fuller, David A. 114, 168 Gaßner, Katrin 35 Goldberg, Adele 232 Guerrero, Luis A. 114, 203

Neuwirth, Christine M. Ochoa, Sergio F. Pino, Jos´e A. Rubart, Jessica

114, 203

203 70, 93

Santoro, Flavia M. Stahl, Gerry 7 Wang, Weigang

3

70

222

61