Collaboration and Technology - CRIWG 2011

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

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

6969

Adriana S. Vivacqua Carl Gutwin Marcos R.S. Borges (Eds.)

Collaboration and Technology 17th International Conference, CRIWG 2011 Paraty, Brazil, October 2-7, 2011 Proceedings

13

Volume Editors Adriana S. Vivacqua Universidade Federal do Rio de Janeiro Instituto de Matemática, Departamento de Ciência da Computação Caixa Postal 68.530, CEP 21941-590 Rio de Janeiro, Brazil E-mail: [email protected] Carl Gutwin University of Saskatchewan, Department of Computer Science 110 Science Place, Saskatoon, SK, S7N 5C9, Canada E-mail: [email protected] Marcos R.S. Borges Universidade Federal do Rio de Janeiro Instituto de Matemática, Departamento de Ciência da Computação Caixa Postal 68.530, CEP 21941-590 Rio de Janeiro, Brazil E-mail: [email protected]

ISSN 0302-9743 e-ISSN 1611-3349 ISBN 978-3-642-23800-0 e-ISBN 978-3-642-23801-7 DOI 10.1007/978-3-642-23801-7 Springer Heidelberg Dordrecht London New York Library of Congress Control Number: 2011935855 CR Subject Classification (1998): D.2, H.3, H.4, H.5, C.2, J.1, H.2.8 LNCS Sublibrary: SL 3 – Information Systems and Application, incl. Internet/Web and HCI © Springer-Verlag Berlin Heidelberg 2011 This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable to prosecution under the German Copyright Law. The use of general descriptive names, registered names, trademarks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. Typesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, India Printed on acid-free paper Springer is part of Springer Science+Business Media (www.springer.com)

Preface

This volume constitutes the proceedings of the 17th Collaboration Researchers’ International Working Group (CRIWG 2011) Conference on Collaboration and Technology. The conference was held in Paraty, Brazil. The previous ten CRIWG conferences were organized in Darmstadt, Germany (2001), La Serena, Chile (2002), Autrans, France (2003), San Carlos, Costa Rica (2004), Porto de Galinhas, Brazil (2005), Medina del Campo, Spain (2006), Bariloche, Argentina (2007), Omaha NE, USA (2008), Peso da R´egua, Douro, Portugal (2009), and Maastricht, The Netherlands (2010). CRIWG conferences have always been motivated by advances in computersupported cooperative work (CSCW), and by the need for CSCW to meet the challenges of new application areas. They aim at providing a forum for academic re-searchers and professionals to exchange their experiences and their ideas about problems and solutions related to the design, development, and use of groupware applications. The conferences follow a simple recipe for success: good papers, a relatively small number of attendees, extensive time for lively and constructive discussions, and a high level of cooperation both within and between paper sessions. CRIWG 2011 continued this tradition. This 17th CRIWG highlighted the continuing interest in the groupware research area. Papers were reviewed by at least three members of an internationally renowned Program Committee, using a double-blind reviewing process. Based on the reviewers’ recommendations, 18 papers were finally accepted: 12 long papers presenting mature work, and 6 short papers describing work in progress. Accepted papers were grouped into themes that represent current areas of interest in groupware research: theoretical foundations, studies of group behavior, methods and techniques and tools for communication and cooperation. For the first time, CRIWG was collocated with the Brazilian Symposium on Collaborative Systems, with which part of the program was shared. The shared program included keynotes by Dave Randall, Gerhard Fischer, and Clarisse Sieckenius de Souza. CRIWG 2011 would not have been possible without the work and support of a great number of people. First of all we thank all members of the Program Committee for their valuable reviews of the papers. We are grateful for the advice and support provided by the CRIWG Steering Committee, and we thank the Doctoral Consortium Chair Fl´ avia Santoro, from Universidade Federal do Estado do Rio de Janeiro (UNIRIO), Brazil. We also thank SBC, CGi.br, CNPq and CAPES for their support. Last, but certainly not least, we thank you for your interest in CRIWG 2011, and hope you find the proceedings valuable. July 2011

Adriana S. Vivacqua Carl Gutwin Marcos R.S. Borges

Conference Organization

CRIWG 2011 was organized by the Graduate Program in Informatics and Department of Computer Science, Federal University of Rio de Janeiro.

Program Committee Chairs Adriana S. Vivacqua Carl Gutwin

Universidade Federal do Rio de Janeiro, Brazil University of Saskatchewan, Canada

Program Committee Adriana S. Vivacqua Alberto Mor´ an Alberto Raposo Ana Cristina Garcia Anthony Tang Carl Gutwin Carla Simone C´esar Collazos Dominique Decouchant

Flavia Santoro Gerhard Schwabe Gert-Jan de Vreede Gilson Sato Gregorio Convertino Gwendolyn Kolfschoten Hugo Fuks Hugo Paredes Ilaria Liccardi

Universidade Federal do Rio de Janeiro, Brazil Universidad Aut´ onoma de Baja California, Mexico Pontif´ıcia Universidade Cat´ olica do Rio de Janeiro, Brazil Universidade Federal Fluminense, Brazil Georgia Institute of Technology, USA University of Saskatchewan, Canada University of Milano-Bicocca, Italy Universidad del Cauca, Colombia Universidad Aut´ onoma Metropolitana, Cuajimalpa, M´exico and LIG laboratory, France Universidade Federal do Estado do Rio de Janeiro, Brazil Universit¨ at Z¨ urich, Switzerland University of Nebraska at Omaha, USA Universidade Tecnol´ogica Federal do Paran´a, Brazil Xerox Palo Alto Research Center, USA Delft University of Technology, The Netherlands Pontif´ıcia Universidade Cat´ olica do Rio de Janeiro, Brazil Universidade de Tr´as-os-Montes e Alto Douro, Portugal Institut National de Recherche en Informatique et Automatique, France

VIII

Conference Organization

Jesus Favela

J¨org M. Haake Jos´e A. Pino Julita Vassileva Luigina Ciolfi Luis Carri¸co Marco Aurelio Gerosa Marcos R.S. Borges Mark Klein Michael Koch Milton Ramos Nelson Baloian Nuno Preguica Pedro Antunes Raquel Prates Robert O. Briggs Sasa Junuzovic Sergio F. Ochoa Stephan Lukosch Till Sch¨ ummer Tom Erickson Tom Gross Traci Carte Vaninha Vieira Werner Geyer Wolfgang Prinz Yannis Dimitriadis

Centro de Investigaci´on Cient´ıfica y de Educaci´ on Superior de Ensenada, Baja California, Mexico FernUniversit¨ at in Hagen, Germany Universidad de Chile, Chile University of Saskatchewan, Canada University of Limerick, Ireland Universidade de Lisboa, Portugal Universidade de S˜ ao Paulo, Brazil Universidade Federal do Rio de Janeiro, Brazil Sloan School of Management, MIT, USA Bundeswehr University Munich, Germany Instituto de Tecnologia do Paran´ a, Brazil Universidad de Chile, Chile Universidade Nova de Lisboa, Portugal Universidade de Lisboa, Portugal Universidade Federal de Minas Gerais, Brazil University of Nebraska at Omaha, USA Microsoft Research, USA Universidad de Chile, Chile Delft University of Technology, The Netherlands FernUniversit¨ at in Hagen, Germany IBM T.J. Watson Research Center, USA University of Bamberg, Germany University of Oklahoma, USA Universidade Federal da Bahia, Brazil IBM T.J. Watson Research Center, USA Fraunhofer FIT, Germany Universidad de Valladolid, Spain

Doctoral Consortium Chair Flavia Santoro

Universidade Federal do Estado do Rio de Janeiro, Brazil

Organization Chair Marcos R.S. Borges

Universidade Federal do Rio de Janeiro, Brazil

Table of Contents

Theoretical Foundations An Ontological Model to Blend Didactic Instruction and Collaborative Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Yusuke Hayashi, Seiji Isotani, Jacqueline Bourdeau, and Riichiro Mizoguchi Boosting Participation in Virtual Communities . . . . . . . . . . . . . . . . . . . . . . Francisco Gutierrez, Nelson Baloian, and Gustavo Zurita Context-Awareness on Software Artifacts in Distributed Software Development: A Systematic Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rafael Leonardo Vivian, Elisa Hatsue Moriya Huzita, Gislaine Camila Lapasini Leal, and Ana Paula Chaves Steinmacher

1

14

30

Interference Management Mechanisms and Socio-cognitive Constructs in Cooperative Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hengameh Irandoust

45

Motivation and Its Mechanisms in Virtual Communities . . . . . . . . . . . . . . Juliana de Melo Bezerra and Celso Massaki Hirata

57

Empirical Studies Collaborative Refactoring: Results of an Empirical Study Using Grounded Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pedro J.F. Treccani and Cleidson R.B. de Souza

73

Communicating in a Transnational Network of Social Activists: The Crucial Importance of Mailing List Usage . . . . . . . . . . . . . . . . . . . . . . . Saqib Saeed, Markus Rohde, and Volker Wulf

81

Does “Virtually Being There” Help? Comparing Collaborative Work between 3D and 2D Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hannes Olivier and Niels Pinkwart

89

Methods and Techniques A Software Architecture for Collaborative Training in Virtual Worlds: F-16 Airplane Engine Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Benjamim Fonseca, Hugo Paredes, Lt. Jorge Rafael, Leonel Morgado, and Paulo Martins

102

X

Table of Contents

A Transfer Approach for Facilitation Knowledge in Computer-Supported Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stefan Werner Knoll, Jana Schumann, Thomas Matzdorf, Ayneta Adege, Martin Linnemann, and Graham Horton Beyond GSS: Fitting Collaboration Technology to a Given Work Practice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tanja Buttler, Jordan Janeiro, Stephan Lukosch, and Robert O. Briggs

110

126

Collaborative Features in Content Sharing Web 2.0 Social Networks: A Domain Engineering Based on the 3C Collaboration Model . . . . . . . . . . Lucas Santos de Oliveira and Marco Aur´elio Gerosa

142

Identifying the Need to Intervene: Analysis and Representation of Interaction Patterns in Group Programming Learning . . . . . . . . . . . . . . . . Thais Castro, David Robertson, Hugo Fuks, and Alberto Castro

158

Tools for Communication and Cooperation A Collaboration Support Environment for Decision Enhancement in Business Process Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mercy Amiyo and Josephine Nabukenya A Collaborative Environment for Offshore Engineering Simulations . . . . . Ismael H.F. dos Santos, Alberto Raposo, Paulo G. Rodrigues, Rog´erio P. Souza, and Wagner Gomes do Amaral Design and Implementation of a 3D Collaborative Telerobotic Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Claudinei Dias, Marcelo da Silva Hounsell, Maur´ıcio Aronne Pillon, and Carla Diacui Medeiros Berkenbrock Hey yaa: A Haptic Warning Wearable to Support Deaf People Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maria Paula Saba, Denise Filippo, Fernando Reiszel Pereira, and Pedro Luiz Pereira de Souza Trusty: A Tool to Improve Communication and Collaboration in DSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gabriela Noemi Aranda, Aurora Vizca´ıno, Jos´e Lu´ıs Hern´ andez, Ram´ on R. Palacio, and Alberto L. Mor´ an Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

175 191

207

215

224

233

An Ontological Model to Blend Didactic Instruction and Collaborative Learning Yusuke Hayashi1, Seiji Isotani2, Jacqueline Bourdeau3, and Riichiro Mizoguchi4 2

1 Information Technology Center, Nagoya University, Japan The Institute of Mathematics and Computational Sciences, University of Sao Paulo, Brazil 3 LICEF research center, TÉLUQ-UQAM, Canada 4 The Institute of Scientific and Industrial Research (ISIR), Osaka University, Japan [email protected]

Abstract. Didactic learning that follows the “traditional” model of a teacherstudent relationship is often considered completely different from collaborative learning. As a result, few studies have explored the potential to effectively connect these two forms of learning. Nevertheless, in practice, a well-thoughtout linkage between these different approaches is essential to leverage and facilitate the learning process. Thus, in this paper, we propose an ontological model that captures the similarity between the two forms of learning, with a focus on participants’ interactions. One of the benefits of this model is the creation of a flexible framework to describe learning independently of the approach used to learn. Second, it also enables us to describe the design rationale of learning scenarios and to organize theoretical knowledge for designing such scenarios in the same manner. To validate this model, we show its advantages with the examination in modeling theories for didactic and collaborative learning, and describe the development of an authoring tool for learning design that uses the model to facilitate the design of theory-based blended learning scenarios.

1 Introduction In the field of education, teachers create eclectic blends of various forms of learning (e.g. Fig. 1.4 in [18]) in order to compensate for the shortcomings of a single form. For example, a lesson may comprise a teacher’s instruction, collaborative learning in the form of a discussion among students, and a supplemental e-learning system in conjunction with a lecture. One of the difficulties in conducting such blended learning is that no support is available in designing each form of learning and effectively fitting them together. For example, LAMS [16] provides users such as teachers, educators and technical developers with a highly intuitive visual authoring environment for creating sequences of learning activities, including a range of individual tasks, small-group work and whole class activities. The users can share their design in the global community because LAMS supports educational specifications such as IMS Content Packaging, IMS Metadata, and IMS Learning Design. However, LAMS is currently A.S. Vivacqua, C. Gutwin, and M.R.S. Borges (Eds.): CRIWG 2011, LNCS 6969, pp. 1–13, 2011. © Springer-Verlag Berlin Heidelberg 2011

2

Y. Hayashi et al.

just an environment to describe any sequences of learning activities in shareable format, and offers no supportive function to help teachers ensure correct and consistent content design. We believe the difficulties in content design stem from the lack of the following: (1) (2)

a unified content-oriented framework for a learning scenario that includes various forms of learning; management of design knowledge, such as learning and instructional theories and best practices.

This study, from the viewpoint of ontological engineering [3, 4,17], aims to develop a computer-based unified modeling framework of learning scenarios for two typical forms of learning, such as didactic and collaborative learning. This paper examines the feasibility of such a computer-based unified framework and an authoring system based on it. The structure of this paper is as follows: the next section discusses a common model of didactic and collaborative learning. Section 3 discusses a learning scenario for didactic and collaborative learning using the common model. Section 4 presents the functionality of a prototype of a unified theory-aware authoring system for both forms of learning based on the common model. Finally, the last section concludes this paper and discusses future directions for research.

2 A Common Model of Didactic and Collaborative Learning Generally speaking, many people consider that didactic and collaborative learning are fundamentally different from each other [6,18]. Figure 1 illustrates supposed conceptual models of didactic and collaborative Learning learning. The main difference between them is that the interactions are characterized as instruction “instruction” in didactic learning, but “collaboration” in collaborative learning. Instructor Learner (a) Didactic learning Although this difference may seem essential Learning Learning at first glance, if we focus carefully on the meaning of the interactions between the collaboration participants, the two manners of interaction do not have to be considered fundamentally Learner Learner different. The common characteristic of (b) Collaborative learning interactions in both forms of learning is that they Fig. 1. Supposed conceptual models both support/facilitate the learning of others1 [1]. of didactic and collaborative learning The key concept for a common model of didactic and collaborative learning in this study is an “I_L event” [8] as defined by the OMNIBUS ontology. The characteristic of this concept is its definition of learning: “learning” is the state change of a learner that is brought about by the learner’s actions, and “instruction” is any action that facilitates 1

Note that we are not claiming that no difference exists between interactions within didactic and collaborative learning settings. Instead, we claim that we could find a common model of interaction that comprises both learning forms.

An Ontological Model to Blend Didactic Instruction and Collaborative Learning

3

the learning action of the learner. Figure 2 shows models of typical didactic and collaborative learning expressed in terms of an I_L event. As shown in the legend of Fig. 2, an I_L event is composed of an instructional action (I-action), a learning action (L-action) and the state change of a learner (S-change). In an I_L event, an agent of an L-action is always a learner that has an S-change. However, an agent of an I-action is the learner him or herself, or another individual, depending on the situation. The former case appears in collaborative learning, as mentioned below. In terms of this concept, the major difference between the two forms of learning is the existence or nonexistence of intended learning. Legend *I.action *L.action *S.change

*Externalize *Recognize *Recognized

*Externalize *Recognize *Recognized

Learning Learning

instruction (facilitation) Instructor

*Externalize *Recognize *Recognized

Learner

(a) Didactic learning

Learner-A

*Externalize *meta-recog. *meta-recog.

*Externalize *Recognize *Recognized

Learning Learning

Learning

facilitation

facilitation

facilitation Collaboration

facilitation Collaboration Learner-B

(b) Collaborative learning-1

Learner-A

Learner-B

(c) Collaborative learning-2

Fig. 2. Models of typical didactic and collaborative learning with the concept of I_L event

Fig. 2(a) illustrates a model of didactic learning. A learner learns by recognizing a learning topic and an instructor facilitates it by externalizing his/her knowledge. Here, for a learner, the action of an instructor, externalization, is an instructional action; a learner’s learning action2 is to recognize what was externalized by the instructor. Fig. 2(b) shows a typical model of collaborative learning. This is a case of cognitive flexibility theory [20]. The focus of this theory is on learning in complex and poorly-structured domains. The learning environment created by this theory emphasizes the presentation of information from multiple perspectives. Therefore, for each learner, an instructional action is “to externalize knowledge from one’s own perspective” by the other one and a learning action is “to recognize it.” Fig. 2(c) illustrates another example of collaborative learning: of the peer tutoring theory in action [5]. In this theory, participants play the role of tutor (peer-tutor) or tutee (peer-tutee). A peer-tutee learns a topic through being taught by peer-tutors, and a peer-tutor meta-recognizes his or her own understanding of the topic by externalizing this understanding for the peer-tutee. It is important to note in this example that the right side of the Fig. 2(c) is the same as that in Fig. 2(a). The difference is on the left side of the three figures. In Fig 2(c), an I_L event occurs wherein Learner A learns through meta-recognition by externalizing understanding of the topic for Learner B, and in the case of didactic learning3 there is no I_L event for the Instructor (the left side in Fig. 2(a)). Consequently, if we consider the meaning of interaction among the participants, both forms of learning can be described within the concept of an I_L event. In 2

Note here that this description is given at a very high level of abstraction, and that there are many more kinds of interaction discussed at a lower level of abstraction, as seen in section 3. 3 Of course, teachers do learn through teaching. However, it is not usually an explicit aim of the learning scenario.

4

Y. Hayashi et al.

particular, the role of instructor in didactic learning could be viewed as variation on the role of peer tutor in collaborative learning [19].

3 A Unified Modeling Framework of Didactic and Collaborative Learning Scenarios This study, based on the above discussion, proposes a unified modeling framework of learning scenarios for both didactic and collaborative learning. Here, ‘learning scenario’ refers to a sequence of interactions that the participants perform in order to achieve learning goals. A scenario promotes interactions among participants according to their roles and should be consistent with learning goals. In collaborative learning in particular, each learner plays various roles, depending on his or her own goals and those of an entire group. Interactions among learners differ according to the roles assigned to each learner [12, 14]. In contrast, didactic learning could be viewed as a special case in which the roles of tutor and tutee are fixed, and the tutor is not expected to learn. Thus, when designing a scenario, the important points to keep in mind are as follows: the description of a learner’s interaction with others, depending on their roles, and the composition of an interaction sequence consistent with the learning goals of each learner and the entire group. In order to support these points, this section discusses types of interaction between participants and how the goal-oriented structure of a learning scenario can affect its design. 3.1 Modeling Interactions between Learners in a Learning Scenario One of the important points in designing a learning scenario is to design the interactions of one learner with others according to a role of each learner. In order to I_L evtA

I_L evtB

I_L evtA

I_L evtB

I_L evtA

I_L evtB

externalize

externalize

let to do

externalize

let to do

externalize

meta-recog.

recognize

externalize

recognize

externalize

recognize

meta-recog. recognized L evtA L evtB (1) AL-II-PL

externalized recognized L evtA L evtB (2) AL-LI-PL

I_L evtA

I_L evtB

I_L evtA

diagnose

diagnose

let to do

recognize recognized L evtA L evtB (4) AL-II-NL I_L evtA = I_L event of Learner A I_L evtB = I_L event of Learner B

I_L evtB let to do

externalized recognized L evtA L evtB (3) PL-LI-PL

Legend An instructional A learning action action

apply applied L evtA L evtB (5) NL-II-PL L evtA = Learning event of Learner A L evtB = Learning event of Learner B

An action of Learner A

A state of Learner A

An action of Learner B

A state of Learner B

Effect of oneself

Effect of others

Fig. 3. Classification of relations between learners and describes them in terms of I_L events

An Ontological Model to Blend Didactic Instruction and Collaborative Learning

5

build a basis for describing interactions, this study classifies relations between learners and describes them in terms of I_L events, as shown in Figure 3. The criteria for this classification are the following: attitude towards learning and overlapping of actions between I_L events. Before giving a definition of these criteria and an explanation of each pattern, it is worth noting the appropriateness of the classification. Among 18 mechanically possible combinations of I_L events based on the above criteria, we found only five of them to be meaningful in collaborative learning. We examined these patterns by examining six collaborative learning theories modeled in CL ontology: anchored instruction [2], peer tutoring [5], cognitive flexibility [20] and so on. We were able to model the interactions in all six theories. While the sufficiency of these criteria is open to discussion, at least the above collaborative learning theories can be described successfully with only these five types of patterns. The first criterion, attitude towards learning, classifies how contributors facilitate learning. The types of contributors include the other participant (passive), a participant oneself (active) or no learning (learning is not carried out). This can be described as the difference between or sameness of the agent of instruction and learning actions in an I_L event. • Passive learning (PL): learning is facilitated by others. The agent of an instructional action is different from the agent of a learning action. • Active learning (AL): learning is facilitated by the learner him/herself. The agent of an instructional action is the same as the agent of a learning action, like Learner A in Fig. 2(c). • No learning (NL): learning is not carried out in the scope of an I_L event. This is mainly used to model didactic learning where the state of the agent of an instructional action does not need to be explicit represented. Although this seems not to meet the definition of collaborative learning, this is also an exceptional pattern in collaborative learning. In some part of collaborative learning scenario the state of the agent of an instructional action may not need to be explicit represented, as mentioned later. The second criterion, overlapping of actions between I_L events, classifies relationships between the learning of two participants. The relationships can be described as a relationship between two I_L events (See figure 3). • Overlapping of instructional actions (II): An instructional action for a learner also works as an instructional action for the other learner. In a pair of I_L events, this can be described as the sameness of an instructional action for both of the two I_L events. • Overlapping of learning and instructional actions (LI): A learning action for a learner works as an instructional action for the other learner. In a pair of I_L events, this can be described as the sameness of an instructional action in an I_L event and a learning action in the other one. Here, we simply explain each meaningful correlation pattern using examples. 1. AL-II-PL defines the case where one participant performs active learning, while the other performs passive learning, and the action of Learner A works

6

Y. Hayashi et al.

2.

3.

4.

5.

as an instructional action both for Learner B and Learner A. A typical example of this pattern is Peer tutoring [5], which is mentioned in the previous section. In terms of an I_L event, this interaction is modeled as one in which Learner A’s “externalize” action works as the instructional action for Learner B, who recognizes what is externalized, as well as for Learner A him/herself, who meta-recognizes (see Fig. 2(c)). AL-LI-PL defines the case where a learning action by Learner A works as an instructional action for Learner B. A typical example of this pattern is found in Cognitive flexibility [20], where learners have different expertise/ perspectives and exchange them when doing a task together. Learner A explains a topic to be learned by externalizing it, and this action by Learner A is useful for the learning of Learner B. In terms of an I_L event, this interaction is modeled as one for which Learner A’s action “externalize” is a learning action for him/herself, as he or she gains experience in explaining; this is also the instructional action for Learner B, who recognizes what is externalized. PL-LI-PL defines the case where both participants perform passive learning and the learning action of Learner A works as an instructional action for Learner B. While this is almost the same as the above pattern, the difference is in the driver behind Learner A’s learning action. While, in the above pattern, Learner A externalizes proactively, in this pattern Learner A is permitted to do so by Learner B. AL-II-NL defines the case where one participant performs active learning, while the other does not learn, and the action of Learner A works as instructional action for both Learner B and Learner A. However, the learning of Learner B is not carried out in this situation. A typical example of this pattern is learning by diagnosis in Anchored instruction [2], where a learner playing an anchor-instructor role trains meta-cognition by diagnosing a solution of a real problem presented by a learner playing an anchor-holder role. The anchor-holder’s “situation” is simply assessed by the anchorinstructor. In terms of an I_L event, this interaction is modeled as one in which the “diagnose” action of Learner A as an anchor-instructor works as the instructional action for both Learner A and Learner B. The action facilitates the learning of Learner A, who learns by recognizing the understanding of Learner B, although it does not facilitate the learning of Learner B because learning is not required him/her in this particular task. NL-II-PL also defines the case where one participant performs no learning, while the other performs passive learning. Here the action of Learner A works as an instructional action both for Learner A and Learner B. The difference between this pattern and AL-II-NL is that learning of Learner A is not carried out in this pattern. A typical example of this pattern is that Learner A just facilitates an action. Learner A’s action “let Learner B do” works as the instructional action for Learner B, who learns by applying a piece of knowledge or skill in a task, event though this action has no effect on Learner A’s learning. This is the basic pattern of didactic learning and can be viewed as a special case in collaborative learning. This pattern is necessary, even in collaborative learning, to describe some scenarios in which the learning of some participants is not an intended goal.

An Ontological Model to Blend Didactic Instruction and Collaborative Learning

7

3.2 A Goal-Oriented Structure of a Learning Scenario for Both Didactic and Collaborative Learning Another important point in designing a learning scenario is to compose an interaction sequence consistent with the learning goals of each learner and the entire group. This study proposes creating such a sequence with the idea of an I_L event decomposition tree [8], which is a goal-oriented structure of a sequence of interactions between an instructor and learners in a didactic learning scenario. As discussed in Section 2, each interaction performed in both didactic and collaborative learning can be described in terms of an I_L event. Therefore, collaborative learning scenarios could be structured in the same way. The challenge is to keep a consistency between learning goals and sequence of interactions. Each learner has his or her own goal, and hence it is necessary to describe multiple I_L event decomposition trees for learners. A relationship between the trees should be managed according to the relationships between learners. large

The goal of the whole scenario Scenario model (design rationale)

grain size

Learning scenario

small Learning contents

Legend I_L event

WAY

Learning object (LO)

Fig. 4. an overview of an I_L event decomposition tree

Figure 4 gives an overview of an I_L event decomposition tree for a didactic learning scenario. Each node represents an I_L event. This structure is not an “is-a” structure but is a “whole and parts” structure based on the relationship of achievement. The root represents the goal of an entire scenario and the leaves represent the actual interaction of an instructor with learners. Each I_L event is decomposed into a couple of sub I_L events that achieves a learning goal in the event, or is linked with learning objects used in the event. Here, the design rationale of a scenario is explained as hierarchically-organized intermediate nodes (I_L events). Figure 5 explains the basic unit of I_L event decomposition. We call the relationship linking an I_L event (macro I_L event) and the sub I_L events (micro I_L events) as WAY. The key of this structure is to distinguish “what to achieve (WHAT)” and “how to achieve (HOW).” A macro I_L event and micro I_L events represent WHAT and HOW, respectively. This distinction allows WHAT to have

8

Y. Hayashi et al.

some alternatives to achieve it as HOW. For example, in the case of Fig. 5, WAY1 and 2 can be alternatives for the same I_L event. That is to say, if WAYs from different theories share the same I_L event as their macro I_L event, they can be alternatives for achieving the I_L event as a learning goal.

* Advance development * Develop (understanding) * Have developed (understanding)

* Instructional action * Instructional action * Learning action * Learning action * State change * State change (terminal state) (terminal state)

I_L event

I_L event (collaborative)

OR

WAY1 is-achieved by

Macro I_L event

* Instructional action * Learning action * State change (terminal state)

decomposition AND

* Make the learner recognize * Recognize * Have recognized the topic

Micro I_L events * Let the learner cognitive action * Organize * Have organized the topic

WAY2

is-achieved by

Legend Macro I_L event

WAY Micro Micro I_L event I_LMicro event I_L event

AND

* Make the learner * Make the learner recognize recognize * Recognize Recall * Have recognized * * Have Recalled the topic

* Let the learner cognitive action * Organize * Have organized the topic

* Let the learner cognitive action * Organize * Have organized the topic

Fig. 5. Examples of WAYs for didactic and collaborative learning

The contribution of the idea of the I_L event decomposition tree in modeling a collaborative learning scenario is that it explains its design rationale in detail. Currently, CSCL scripts have been represented using IMS Learning Design specifications (IMS-LD) [7, 11]. A CSCL script is a computer-readable description of a collaborative learning scenario. However, it has many limitations when used for describing fully collaborative learning scenarios. Isotani et al. have proposed a CL ontology that provides a formal and semantically rich structure necessary to create computer-understandable CSCL scripts. The ontology includes a conceptual framework, named the Growth Model improved by Interaction Pattern (GMIP) [14], to relate learning goals and interaction among learners in collaborative learning. The advantage of GMIP is that it is a computer-understandable description of the design rationale of a collaborative learning scenario. The framework can be used to describe a design for collaborative learning sessions as well as the content of collaborative learning theories [14]. The proposed framework in this paper provides a more powerful description than the CL ontology. Figure 6 gives an example of a GMIP enhanced with I_L event decomposition trees. I_L event decomposition trees explain the design rationale of links between a set of learning goals and a sequence of interaction in a GMIP. GMIP has two components: a model of the state change of a learner, called the Learner Growth Model (LGM), and a model of a flow of interaction between learners called Interaction Pattern (IP). This model is based on Peer tutoring theory [5], as mentioned above, which defines two participant roles: a peer tutor and a peer tutee. Therefore, two LGMs are defined for the respective roles. Each goal is described as the state change of a learner in the LGM. These goals become the root node of each I_L event decomposition tree and these two trees are merged into a symbiotic tree. Leaf nodes of the symbiotic tree correspond to interactions described in the IP. In addition to the rich description of design rationale, another advantage of describing design rationale with an I_L event decomposition tree is to provide the interoperability of theories between didactic and collaborative learning. This means

An Ontological Model to Blend Didactic Instruction and Collaborative Learning

9

S(0,0) S(0,0)

S(1,0)

S(3,0) S(0,2)

S(2,0)

S(0,1)

S(2,0)

S(0,1)

S(1,1)

S(3,1) S(2,1)

Learner LearnerGrowth Growth Model (LGM) Model (LGM)

S(1,0)

S(3,0)

S(0,2)

S(1,1)

S(3,1) S(2,1) S(4,0)

S(4,0)

S(2,2) S(0,3)

S(2,2)

S(0,3)

S(1,2)

S(1,2) S(3,2)

S(3,2) S(4,1)

S(2,3)

S(1,3)

Learning Learning Learning Learning goal goal goal goal I_L I_Levent event decomposition decompositiontree tree

S(4,1) S(2,3)

S(1,3)

S(3,3)

S(4,3)

S(4,2)

decompose

S(3,3)

S(4,3)

S(4,2)

decompose

merge Actual Actualinteraction interactionbetween betweenlearners learners 2: Requesting problem’s details 1: Knowledge Transmission

6: Affirmative reaction 3: Demonstration how to solve a problem

4: monitoring

5: Notifying how the learner is

Interaction InteractionPattern Pattern(IP) (IP) Fig. 6. Example of a GMIP enhanced with a symbiotic I_L event decomposition tree

that, in designing a learning scenario, an author can freely utilize didactic or collaborative theories, or blend them together. So far we have modeled 11 instructional theories based on the OMNIBUS ontology and six collaborative learning theories based on the CL ontology. We can describe all these models of theories in the same form, using WAY, that we call WAY-knowledge. For example, WAY1 and WAY2 in Fig. 5 are used for didactic and collaborative learning, respectively. These WAYs work as alternatives sharing the same macro I_L event and whose goal is to develop an understanding. A scenario author can apply each of them in a scenario in the same manner. That is to say, in this case, the user selects a form of learning within the proposed framework in this study by selecting a WAY.

4 Blended Learning Scenario Design Support with OMNIBUS and CL Ontology The proposed unified modeling framework provides interoperability between didactic and collaborative learning. So far we have developed two separate learning scenario

10

Y. Hayashi et al.

(A) (B) An applicable WAY-knowledge for didactic learning

Didactic learning part

(D)

Decomposed

Applied

(C) An applicable WAY-knowledge for collaborative learning

Didactic learning part

Collaborative learning part

Fig. 7. Screen shots of the integrated system both for didactic and collaborative learning

authoring systems: CHOCOLATO [13] for collaborative learning and SMARTIES [9] for didactic learning. We have investigated the usefulness of these systems in practice and these systems have worked well for responsive form of learning in some experiments [10, 15]. Based on the integration of these systems and the proposed unified framework, we have been developing an advanced authoring system to support the design of didactic, collaborative, and blended learning scenarios. Here, we demonstrate the interoperability of didactic and collaborative learning with an example. Figure 7 shows screen shots of the integrated system under development where the user can seamlessly blend both forms of learning in a scenario. Fig.7 (A) displays a scenario in the process of creation. The top-level decomposition of this model describes the outline of a lecture. The I_L event sets the goal of “to develop understanding” for learners, and the system provides the user with WAYs to this goal from both didactic and collaborative learning theories. Here, as examples, the system proposes WAY1 and WAY2 in Fig. 4, as shown in Fig. 7(B) and Fig. 7(C), respectively. WAY1 emerges from a didactic learning theory, specifically Dick and Carey’s instructional model [5], in which an instructor makes a learner recognize the topic to be learned and then lets the learner organize the topic. On the other hand, WAY2 emerges from a collaborative learning standpoint. The authoring system suggests peer tutoring [5], in which learners are separated into groups of peer-tutors, who already understand the topic, and peer-tutees, who do not. Peer-tutors then teach peer-tutees. For peer tutors, the learning goal is to recall the topic and organize it to deepen understanding. The user (author) can select a WAY beyond these two suggestions, according to the user’s preferences or the requirements for the scenario. The system automatically applies a selected WAY to the learning scenario model, as shown in Fig. 7(D). In this manner, didactic and collaborative

An Ontological Model to Blend Didactic Instruction and Collaborative Learning

11

learning can be seamlessly blended in a scenario based on both didactic and collaborative learning theories. The system has been developed, nevertheless, some challenges remain. For example, in designing collaborative learning, it is necessary for teachers to form groups of learners. CHOCOLATO supports this group formation process and its support function must be included in the integrated system. This is an issue for future research.

5 Conclusion In this paper we have proposed a unified modeling framework for didactic and collaborative learning scenarios. It is understood that two forms of learning are fundamentally different from each other. Therefore, developing a framework requires a new device to unify them. As a solution, we built a common model of interactions between them by exploiting the concept of an I_L event. This model successfully captures a common ground between the two forms of learning; that is to say, the meaning of interaction in both of them is interpreted as to facilitate/support learning. This viewpoint provides the following two advantages. One is that the role of instructor in didactic learning can be viewed as a variation on peer tutoring in collaborative learning. Both roles facilitate another's learning, although the instructional action of a peer tutor does also serves to his/her own learning. The other advantage is that we found that interactions described in the six collaborative learning theories are distilled into five patterns of relation between two I_L events. These findings enable us, in both forms of learning, to describe the design rationale of learning scenarios by I_L event decomposition trees and to organize theoretical knowledge for designing such scenarios in the same manner of WAY-knowledge. This achievement is a first step toward a comprehensive theory-aware authoring system for various forms of learning. As shown in Section 4, the authoring systems based on this system enable its users to use eclectic pieces of theoretical knowledge in designing didactic, collaborative or blended learning scenarios. Scenarios designed in the system have a clear description of design rationale in the form of an I_L event decomposition tree and are theory-compliant if an author uses any pieces of WAYknowledge. However, some open issues remain. The most significant is the necessity of maintaining consistency within a scenario made by blending didactic and collaborative learning. First of all, there is no theory that allows for blending different forms of learning, and hence it is impossible to support the design of theoretically valid blended scenarios at present. The contribution of this study is to enable us to design each form of learning scenario to comply with various theories on a unified modeling framework. We have already investigated the usefulness of OMNIBUS and CL ontology and demonstrated these ontologies and systems based on these ontologies work well in practice [10, 15], although there is still a lot more work left to do, for example, in making them usable for teachers. Although there is no currently usable guideline for blending several forms of learning, this study will contribute to building such a guideline through the organization of various theories on the proposed unified framework.

12

Y. Hayashi et al.

References 1. Carr-Chellman, A.A., Hoadley, C.M.: Looking back and looking forward. Educational Technology 44(3), 57–59 (2004) 2. Cognition and Technology Group at Vanderbilt: Anchored Instruction in Science Education. In: Duschl, R., Hamilton, R. (eds.) Philosophy of Science, Cognitive Psychology, and Educational Theory and Practice, pp. 244–273. SUNY Press, Albany (1992) 3. Devedzic, V.: Semantic Web & Education. Springer Science Business Media, Heidelberg (2006) 4. Dicheva, D.: O4E: Ontologies for Education, http://compsci.wssu.edu/iis/nsdl/ 5. Dick, W., Carey, L., Carey, J.O.: The systematic design of instruction, 5th edn. AddisonWesley Educational Publisher Inc., Reading (2001) 6. Endsley, W.R.: Peer tutorial instruction. Educational Technology, Englewood Cliffs (1980) 7. Harrer, A.: An Approach to Organize Re-usability of Learning Designs and Collaboration Scripts of Various Granularities. In: Proceedings of the IEEE International Conference on Advanced Learning Technologies (ICALT), pp. 164–168 (2006) 8. Hayashi, Y., Bourdeau, J., Mizoguchi, R.: Ontological Support for a Theory-Eclectic Approach to Instructional and Learning Design. In: Nejdl, W., Tochtermann, K. (eds.) EC-TEL 2006. LNCS, vol. 4227, pp. 155–169. Springer, Heidelberg (2006) 9. Hayashi, Y., Bourdeau, J., Mizoguchi, R.: Using Ontological Engineering to Organize Learning/Instructional Theories and Build a Theory-Aware Authoring System. International Journal of Artificial Intelligence in Education 19(2), 211–252 (2009) 10. Hayashi, Y., Kasai, T., Mizoguchi, R.: Ontological Modeling for Reflective Instructional Design: A Case Study on Modeling a Lesson Plan. In: Proceedings of the International Conference on Computers in Education (ICCE), pp. 25–32 (2010) 11. Hernandez-Leo, D., et al.: COLLAGE: A collaborative Learning Design editor based on patterns. Educational Technology and Society 9(1), 58–71 (2006) 12. Inaba, A., Ikeda, M., Mizoguchi, R.: How Can We Form Effective Collaborative Learning Groups? - Therotical of Opportunistic Group Formation With Ontological Engineering. In: Gauthier, G., VanLehn, K., Frasson, C. (eds.) ITS 2000. LNCS, vol. 1839, pp. 282–291. Springer, Heidelberg (2000) 13. Isotani, S., Mizoguchi, R.: Deployment of Ontologies for an Effective Design of Collaborative Learning Scenarios. In: Haake, J.M., Ochoa, S.F., Cechich, A. (eds.) CRIWG 2007. LNCS, vol. 4715, pp. 223–238. Springer, Heidelberg (2007) 14. Isotani, S., Inaba, A., Ikeda, M., Mizoguchi, R.: An Ontology Engineering Approach to the Realization of Theory-Driven Group Formation. International Journal of ComputerSupported Collaborative Learning 4(4), 445–478 (2009) 15. Isotani, S., Mizoguchi, R., Isotani, S., Capeli, O.M., Isotani, N., de Albuquerque, A.R.P.L.: An Authoring Tool to Support the Design and Use of Theory-Based Collaborative Learning Activities. In: Aleven, V., Kay, J., Mostow, J. (eds.) ITS 2010. LNCS, vol. 6095, pp. 92–102. Springer, Heidelberg (2010) 16. LAMS Foundation, LAMS (Learning Activity Management System), http://www.lamsfoundation.org/ 17. Mizoguchi, R., Bourdeau, J.: Using Ontological Engineering to Overcome Common AIED Problems. International Journal of Artificial Intelligence in Education 11(2), 107–121 (2000)

An Ontological Model to Blend Didactic Instruction and Collaborative Learning

13

18. Reigeluth, C.M.: What Is Instructional-Design Theory and How Is It Changing? In: Instructional-Design Theories and Models: A New Paradigm of Instructional Theory. Lawrence Erlbaum Associates, Inc., Mahwah (1999) 19. Reigeluth, C.M., Carr-Chellman, A.A.: Understanding Instructional Theory. In: Instructional-design theories and models: Building a Common Knowledge Base, pp. 3–26. Routledge, New York (2009) 20. Spiro, R.J., Coulson, R.L., Feltovich, P.J., Anderson, D.K.: Cognitive flexibility theory: Advanced knowledge acquisition in ill-structured domains. In: Proceedings of Annual Conference of the Cognitive Science Society, pp. 375–383 (1988)

Boosting Participation in Virtual Communities Francisco Gutierrez1, Nelson Baloian1, and Gustavo Zurita2 1

Computer Science Department (DCC), Universidad de Chile, Blanco Encalada 2120, Santiago, Chile {frgutier,nbaloian}@dcc.uchile.cl 2 Management Information Systems Department, Universidad de Chile, Diagonal Paraguay 257, Santiago, Chile [email protected]

Abstract. We have been experiencing an explosion in the market of social websites that aim not only to entertain us, but also to help us enlarge our professional networks, to redefine business models and capture new customers, to modify the way learning and teaching are performed, among others. So far, little research has been done on what drives individuals to contribute to online communities, as there is not enough empirical evidence to validate wellestablished models. In this research we propose to design, develop and test a set of principles and functionalities a virtual community should have in order to attempt to achieve a high degree of activity by its members. We will focus, at first, on the particular case of educational virtual communities. We would like our results to cover more of the scenarios and area regardless of its content and context. Keywords: Motivation, Participation, Virtual Communities, Social Networks, Collaborative Work, Collaborative Learning.

1 Introduction Over the last few years, we have witnessed an explosion in the development of social networks on the Web, dramatically changing the way applications and services offered by various providers are used. This is the case of participative websites like YouTube, with more than 10 billion videos played each month, Wikipedia, with more than 10 million articles in 250 different languages and of different social networks such as Facebook, with more than 500 million users, MySpace, LinkedIn, among many others that expect to reach 1 billion users by 2012 [1]. In the particular case of social networks, and mainly virtual communities, social websites are well accepted and widely used in everyday life by a large number of web users. These communities exist because people with similar goals, beliefs or values lay the basis of an agreement to form and sustain a virtual existence [2]. This way, internet users belonging to a particular community can track interesting information being promoted, discussed or tagged on the Internet [3]. However, these ties may not be strong enough to sustain the existence of the community over time, resulting in members gradually leaving the virtual community, A.S. Vivacqua, C. Gutwin, and M.R.S. Borges (Eds.): CRIWG 2011, LNCS 6969, pp. 14–29, 2011. © Springer-Verlag Berlin Heidelberg 2011

Boosting Participation in Virtual Communities

15

leading to its extinction. For example, Butler states that 50% of social, hobby and work mailing lists had no traffic over a 122-day period of monitoring. Moreover, the lack of a minimal number of contributions is a problem even in successful communities: fewer than 50% of subscribers had not posted even a single message in a 4month period [4]. Some researchers have already studied the reasons why some people are willing to contribute and why others tend to be passive. For example, in [5] the authors say that research on members who have never actively participated (also referred as to “lurkers”) has revealed many reasons for such inactivity. A study by Preece, Nonnecke and Andrews [6] found that because lurkers felt they did not need to post or that they needed to find out more about the group before posting. They thought they were already being helpful by participating in the community, they could not make the software work, and in some cases, because they did not like the group. On the other hand, there is a group of community members that Kim [7] describes as “elders”, who are active members of the community, regularly posting to share their knowledge and the culture of the community. Some of the contributions on why less involved members do not participate can be seen in [5] and [8]. Online communities are also used as a way for companies to enhance demand for their products [9]. They are also sometimes depicted as one of the most effective business models. However, the achievement of this goal depends on a comprehensive understanding of the members’ motivation for contribution, so that the community has enough public goods for consuming. Public goods are defined as those that anyone might benefit from, regardless of whether they have helped to contribute to their production [10]. Moreover, current business model trends regarding e-content show a shift from getting revenues from selling content to the end users towards getting revenues from advertisement, and sometimes even providing content free of charge [11]. Today, companies are interested in developing more new business opportunities, based on participative web sites, where social media and customer-oriented virtual communities are the key factors in developing revenues for companies in terms of advertising, and increasing customer satisfaction with regard to brands, products and services. In the e-learning field, even if online participation and interaction do not necessarily translate into higher grades at the end of an academic period, students who did not pass the course have been seen to interact less frequently than students who did pass [12]. Therefore, motivating students to participate in educational virtual communities would be a plausible way to improve their learning experience. So far, there is not enough field testing on which elements may trigger participation in virtual communities. However, design principles of which functionalities may motivate members to contribute can be seen in [7] and [13], such as improving the usability and sociability of user interfaces, as well as defining roles and members’ lifecycle in the community among others. Janzik and Herstatt present a set of incentives, such as: peer recognition, status, reputation and identification, in which community members can contribute [14]. More than listing a review of what is currently trendy in the fields of participation and virtual communities, we are interested in defining a model that helps us understand why people contribute to these kinds of web sites and how it is possible to boost participation and increase contributions in both quality and quantity.

16

F. Gutierrez, N. Baloian, and G. Zurita

In this research we propose to design, develop and validate a set of principles and functionalities that a virtual community should have in order to increase the chances that it will be successful. By successful we mean that there will be a high degree of activity by its members. In the following sections, we will present the results of preliminary testing one of these functionalities, as an example of the methodology, because presenting all of them would go beyond the limits of this paper.

2 Previous Work There are already some previous research works providing guidelines on improving participation in virtual communities. In this section we will present some of them: 2.1 Design Principles One of the first well-established works on this topic is presented in [7]. This work presents nine design strategies that characterize successful, sustainable communities. Taken together, these summarize an architectural, system-oriented approach to community building (called Social Scaffolding by the author). The Reader-to-Leader framework [13] presents guidelines for designing robust virtual communities. The authors claim users are relatively shy at first and do not interact in an appropriate way with the platform. The longer users are engaged, they pass through a natural evolution process, from reader to contributor, to collaborator and finally to leader. Interfaces should include well-thought-out usability and sociability features, such as adaptation to the general context of the community, easy access to relevant content through navigation or search, and easy-to-use bookmarking mechanisms, among others. Girgensohn and Lee [15] present some design strategies for virtual communities. The main idea behind their model is to perform a continuous design idea for the growth and changes of the community, as well as creating and maintaining feedback loops and empowering members through time. The social interaction is based on a persistent identity which is based on the users’ behavior, the possibility of modifying rules over time pertaining to collective resources and having means to monitor and control users’ activities on the site. In order to ensure an appropriate level of activity, as well as regular updates of the site, notifications should stand as the core instrument for the system administrator to utilize in tuning the system. According to Koh, Kim, Butler and Bock [16], it is important for virtual communities to support various kinds of multimedia content, as well as to clearly define roles following a lifecycle having a leadership pattern. In online groups, sometimes members seem to lack loyalty, as they often switch from one community to another or use their community less over time. Brandtzaeg and Heim [17] discuss the reasons why users become less active or even quit online communities. On the other hand, Arguello et al. [18] refer to identifying factors such as: Group Identity, Cross-posting, Group Size and Volume, Newcomer Status, Messages’ Topical Coherence, Word Choice, Linguistic Complexity. A framework for social web design is presented in [35]. It is worth highlighting the AOF Method, a simple prioritization scheme for designing social web applications.

Boosting Participation in Virtual Communities

17

This method proposes to focus on the activities (i.e., what is the audience doing?), to identify the social objects and to choose a core feature set. 2.2 Theories Derived from Social Psychology Beenen, Ling, Wang and Chang [19] state that although not all users in a virtual community need to contribute to make a group successful, those with a large proportion of non-contributors have more difficulties providing the services required by its members. Also, if contributions tend to be unique, community members will be more motivated to work collaboratively as they feel they will have a greater impact in the final result. Cheng and Vassileva [20, 21] propose a motivation strategy based on persuasion theories of social psychology addressing the problem of having too few users willing to make contributions in online communities. They introduce a set of hierarchical memberships into a Peer-to-Peer community and reward active users with better quality of services by defining a function that measures participation in both quantity and quality of contributions. Ludford, Cosley, Frankowski and Terveen [22] claim that some of the factors that may trigger participation are: satisfaction of personal needs, learning, and contribution to the common good. However, in a group, sometimes people think others will do the work. A common belief is that the more the members of a group are similar, the better the reception among the other team members will be, thus improving the quantity and quality of contributions. However, users of a group with dissimilar members tend to contribute more, as they like to find out how they are unique within a group thus providing them with this information increases their participation. New users in a virtual community who find their declared friends in the network collaborating, are more eager to share more information thereafter [23]. This is because people tend to follow other people’s behavior, even without external stimuli. A model that may help to explain ways to motivate member contributions to online communities is presented in [24]. External rewards may affect the degree of intrinsic motivation, so socially-advanced users’ contributions may cause lurkers to be more active in the community. In order to improve contributions, trust is an important factor, and it also lowers the costs and risks of contributing. Also an easy-to-use website will have a positive impact in the quantity of contributions, as well as offer a sense of group identity and cohesion. 2.3 Motivation in Online Learning Communities It is worth highlighting the particular case of virtual communities supporting elearning and cooperative learning, since there are many sites devoted to this goal. Laghos in [34] presents the concepts of e-learning and e-learning communities, as well as a review of relevant research in these areas. Cooperative learning has been shown to be a successful teaching strategy in which small teams, each with students with different levels of ability, use a variety of learning activities to improve their knowledge. Students work through the assignment until all group members successfully understand and complete it [25]. When using an electronic platform, such as an e-learning management system, there is a real advantage

18

F. Gutierrez, N. Baloian, and G. Zurita

when providing integrated functionalities for content authoring and management, interpersonal communication activities, assessment, learner tracking, among others [26]. However, assessment may be considered the “weakest link” in e-learning systems. E-learning designers have relied predominantly on tools that are aimed at supporting the construction of test items. The drawback of such items is that they tend to focus on the measurement of low-level retention of isolated facts, rather than on the application of knowledge to solve ill-structured problems [27, 28]. This problem is tackled and some guidelines are presented in [29]. Lebrun explains in [30] and [31] the methodology to design a proper e-learning platform, as well as the problem of motivation, or lack of it. Vonderwell and Zachariah found in [32] that technology, user interface design, content-area experience, student roles and tasks and information overload have a key factor on influencing online learners participation and their patterns.

3 A Framework for Boosting Users’ Participation In this research we aim to define a framework with the key social factors that might have an impact on the success of virtual communities by triggering motivation and boosting participation. Therefore, we decided to test some ideas derived from social psychology theories and some strategies designed by some authors. Because of the expanded use of virtual communities and collaborative work in a large number of fields, this research may have a positive impact towards creating “social cohesion” among its members by triggering participation. The promise of social participation applications is huge, generating a steady flow of entrepreneurs and technology activists who are experimenting with new approaches with either commercial or personal goals [13]. Until now, some authors have recognized and tested particular factors that may improve participation in social groups. However, evidence provided by these works is only valid for a particular factor and situation. We propose to define a framework that might be validated (or rejected) with empirical testing, also giving hints about the relative degree of impact of each one of the factors. At first, we will consider these factors simply as claims. In this research, we propose five social factors in which that we would like to quantify their impact: rankings, peer moderation, challenges, matchmaking and notifications. As literature suggests, these are the most critical ones when designing a virtual community. Our goal here will be to test the pertinence of these elements, as well as analyze the impact they have on users. We will study the reasons why people get motivated to participate in social websites and in which areas community managers and interface designers can exploit in order to ensure members’ participation over time. We will focus at first in the problem of motivating learners in the context of educational virtual communities. However, we expect to generalize some of these results, as well as testing the proposed claims in other different kinds of communities in the near future.

Boosting Participation in Virtual Communities

19

The framework we propose is seen in figure 1. In such a framework there should be a model of the type of community for which we are going to address. In this case this is represented by a standard core structure with the following functionalities: • • • • • •

User Profile Friends and Private Messages Groups Like/Unlike a comment/action/entity Public Blog and Forum Wiki Pages (for Collaborative Work)

In order to achieve this, we developed a small prototype where we are testing, one at a time, the different functionalities that form our proposed model. We chose them because of the reported impact they have on triggering participation in previous research experiences when studied independently. The model we propose is divided in three main sections: Social Network Model: we address the social networking model that we will be working on. This includes the main features that are expected on these kinds of websites, including standard features, such as forums, blogs, messages, comments and wiki pages, among others. Technologies: including web-based virtual communities as well as mobile-based virtual communities. We aim to work in different kinds of mobile devices, such as smartphones and tablets including geolocation features and an exploration in the use of audio-user interfaces. We will also be interested on exploring the use of web standards (HTML5 and CSS3). Features that are being tested: including the functionalities that were designed and are being tested for validating (or rejecting) them. 1) Rankings: we aim to measure the value of contributions by measuring quantity and quality, as Cheng and Vassileva did in [20, 21]. In fact, by adding this kind of feature we expect to encourage members to contribute and engage more with the group. We will also be interested in exploring how this feature would impact the context of a specific virtual community, as well as the way metaphors (this is, the specific terminology in the form of labels, tags and categories) need to be defined. A reward system linked to users’ ranking in contributions will also be designed. We will also define a "participation function" that will calculate a quantitative factor that reflects the level of participation of a user in a given time in the community. We will consider different elements, such as the number and time of log-ins to the server, the number of blog/forum topics created, the number of comments that are made in posts, the active use of the features offered in the website, among others. Each one of these define an "expected task" that will be associated to a weight-factor that will finally add-up the value of this function. The iterations of this method will be performed periodically (for example, once a week). During a first stage, users will be left free to use the different tools and then they will be initially classified into three groups: HIGHparticipation (10% of the users), MEDIUM-participation (60% of the users) and LOW-participation (30%). Each group will obtain rewards that are linked to their

20

F. Gutierrez, N. Baloian, and G. Zurita

Fig. 1. Functionalities to be tested during the whole research. In this first paper, we will discuss one of them: Rankings.

category and will either improve or lower their rank. This category will be displayed to the whole community, either in form of a simple text-label or an icon that reflects it (a golden star for HIGH level users, a red warning sign for LOW ones). 2) Peer moderation: as an extension of the previous point, we will add a feature that ensures a certain level of quality on contributions when added to the computation of a ranking function, as well as empowering members over time by establishing a set of categories (as suggested by Kim on [7] and Preece and Shneiderman in [13]). This idea has been previously explored and tested by one of the researchers in the development of an iPhone application dedicated to informal mobile learning in Chinese language for French-speaking people [33] and we expect this time to gather more field evidence on how members’ relationships are built, as well as members’ life

Boosting Participation in Virtual Communities

21

cycle in the community. This kind of feature can be linked to with the ranking system, where we will also consider the moderation made by the whole group in order to ensure a certain level of quality of the collaborations. If the users get a higher rank, they will be given more permission in order to edit or delete content and ensure their role as "community leaders". 3) Feedback and Notifications: the idea behind this point is explored in [20, 21], [15] and [13], among many others. It states that sending feedback to users inside the application or via email might help to boost participation at specific stages defined by the community manager. During this research, we will analyze the relative impact of this feature when boosting participation, as well as studying the existence of a critical mass of notifications and its effects, such as a decrease in the number of collaborations due to information overload. 4) Match-making and Partnership: this idea, explored in [22], addresses the uniqueness and group dissimilarity and their impact on motivating participation. This point turns out to be particularly interesting since it could be a way to introduce new members into the community and facilitate relationships building between users with similar interests. We will also be interested in studying the pertinence of using decision-making algorithms for matching users in the community for collaborative work. Each user will be assigned a "partner" based on their personal affinities and characteristics. This can be established by a profile-form applied to the group of users. This can also be linked to the "challenge" feature, where users can be forced to reach specific goals by cooperation and collaboration. Users will keep their partner as long as they reach a certain level of participation; otherwise they will be separated and, maybe, be forced to change them. Following a natural evolution of the community, these groups will eventually be merged with others, thus ensuring a kind of interaction with the whole group or the entire community. As before, a small questionnaire will be applied to the members in order to obtain feedback from them regarding their feelings towards this kind of interaction. 5) Challenges: linked to the previous idea, we are interested in studying the power of challenging users in collaborative tasks, when they are forced to perform them individually or in groups. Previous research states that performance, rewards and high-reachable goals are interrelated [24]. That way, we expect to introduce new ways to participate in a community (other than posting, rating and commenting), improving the relative value of a website. This can turn out to be an important tool to motivate users to take part in marketing campaigns (in the form of participative call-to-action tasks), as well as analyzing the power of gaming features in geolocation applications in mobile-based virtual communities. We will place community members in both, individual and collective challenges. We think this will boost peer collaboration and cooperative work (in the case of communities that allow this kind of participation). For achieving this, we will define a set of reachable goals that then reward or punish users depending on their results. In order to ensure participation, we will establish a ranking where users will be graded either by the administrator of the community, or by the whole group. A small questionnaire will be distributed to the members for feedback on their feelings about this topic. A conceptual design model that would help the task of design for participation, pointing out the kinds of interactions that motivate users, will come out as a result of

22

F. Gutierrez, N. Baloian, and G. Zurita

analyzing the behavior of community members towards each proposed functionality in different kinds of communities. This is the final goal of our whole research work. As we first focus on communities linked to teaching and learning, we tested the "ranking" feature with a group of students enrolled in the Advanced Programming of Distributed Applications course at Waseda University during February 2011. This experience gave us the first feedback on the interest of students using these kinds of tools, as well as data, allowing us to redefine the design of the different functions.

4 First Results During the first stage of the research, we aimed to test some of the principle ideas we think will boost participation, as well as gather field information about social patterns in collaborative-work environments. For doing this, we developed a small web application, as well as a website to provide support for the Advanced Programming of Distributed Applications course at Waseda University in February 2011. The web support was developed in a standard Apache-MySQL environment, using the PHP framework Elgg as a core structure for the social network. Several modifications had to be made to the original front-end and back-end Elgg environment in order to adapt the different social functionalities offered to the course. These were: personal blogs, public forum, collaborative page creation (wikis), status updates (such as intrasite tweets), assignments module (for uploading, commenting and rating the assignments prepared by all the students). The users of this website were divided in two groups: administrators (two of the researchers) and end-users (the group of 7 students enrolled in this course). Naturally, they were given different degrees of permissions, but the idea behind it was that all the students would be able to see the files uploaded by their classmates, first step into collaboration in the way of asking for and offering help. Also, the use of a public blog, forum and wikis allowed students to take and share notes with everybody. All the students were free to use these tools as they liked, but we asked them to upload their assignments in the section that was dedicated to this. During the second week, we added a rating system to the assignments section (one of the core functionalities, in our opinion), as well as a rating system where all the users could easily see the level of participation of each student. These levels were: low, medium, high and they were calculated periodically (daily), considering the number of threads and topics created in blogs and forums, as well as the use of the different functionalities offered and the number of log-ins into the website. We formulated the following set of hypotheses to test: (H1) Giving feedback to the students as a visible tag of their current level of participation triggers participation (H2) The use of public blogs and forums helps students to work collaboratively in their assignments (H3) The possibility of rating peers’ assignments boosts participation when asking or offering help (H4) End-users feel the website is more attractive when there are social functionalities (H5) End-users feel that a rating system motivates them to participate in the community

Boosting Participation in Virtual Communities

23

(H6) End-users feel this kind of platform allows them to work better during their assignments (H7) End-users feel that this kind of platform finally improved their learning In order to test these hypotheses (either validate or refute them), we gathered information directly from the interaction between users on the website, as well as their individual behavior. Thus, we kept a log of the sessions where we placed attention on the blog/forum features and the interaction done in the Assignments section (if any). Using this data and during the second week of the study, we calculated on a daily basis, a “participation factor” which directly modifies the profiles of users with a label indicating their current level of participation, as well as giving advice on how they can boost this factor. We classified the whole group at first, for having a 25% of “high” participation students, a half of them with the “medium” tag, and finally a 25% of “low”. A table was completed with their daily participation levels in order to keep track of the evolution of the process through the second week of the study (hypotheses H1 through H3). This information was completed with a questionnaire that was applied during the last lecture of the course (hypotheses H4 through H7). This survey allowed us to find out if students were conscious of their having boost their own participation through the experience, as well as obtain their opinion on the usability and interest on the social features offered in the website. Figure 2 shows the evolution of the social participation considering the actions performed by each member of the community. Figure 3 shows the difference of raw participation score between two consecutive iterations for each student. For calculating each participation score, we considered the total number of collaborations to the community. These were creating a blog entry or a forum thread (earning

Fig. 2. Evolution in the Participation Score of each Student during the Experience

24

F. Gutierrez, N. Baloian, and G. Zurita

Fig. 3. Differences of the Participation Score between Iterations, for each Student

2 points each), posting comments on assignments or blogs entries or forum threads (1 point each), rating classmates' assignments (1 point per rating, limited to one point per assignment and a student can't rate his own work) and 1 point bonus for outstanding use of the different tools offered by the site (for example, exploring how to send messages to a specific user, update their own profile, among others). Table 1 presents the evolution of each student's rank: Table 1. Evolution of the Rank of Students Enrolled in the Course

Student A B C D E F G

Starting Point February 13 MEDIUM MEDIUM LOW HIGH MEDIUM MEDIUM HIGH

Iteration #1 February 14 MEDIUM MEDIUM HIGH HIGH MEDIUM LOW HIGH

Iteration #2 February 15 MEDIUM MEDIUM HIGH HIGH LOW MEDIUM HIGH

Iteration #3 February 16 LOW MEDIUM HIGH HIGH LOW MEDIUM HIGH

Based on this data, we conclude: 1) These results only apply to this specific group, because the population is not large enough to be considered as statistically representative. 2) The group of users tends to modify their behavior towards the community when their assigned rank is "LOW". In fact, after the starting point during iteration #1 and during iteration #2, the students C and F modify dramatically their ranks, maintaining

Boosting Participation in Virtual Communities

25

them until the end of the experience. It is worth noting that the student with the worst raw score at the beginning of the evaluation period came up with the best score at the final iteration. 3) One user in particular (student G) takes spontaneously the role of "community leader" by keeping a log of his class notes in the website, allowing classmates to read them at any time. He also encouraged discussions and created several topics for allowing his classmates to participate. He got the best raw score at the beginning of the evaluation period. 4) Once the users got the label "HIGH", they kept it during the whole evaluation period by participating constantly. Otherwise, those who were put in the "MEDIUM" group were not eager to modify their rank as long as they do not lower their reputation in the community. In future experiences, it would be worth considering "rewards" and "punishments" for users who grade up or down in their ranks. 5) One of the most critical features used by the users to improve their participation in the site was the "rating" (in the form of golden stars) given to the different assignments of their classmates. 6) The quality of contributions (posts / comments) remained of high quality during the whole evaluation period. Some students even used the forum to create discussions not necessarily related to their lectures, their assignments or they used it for asking for help. However, this may be due to the fact the evaluation period was quite short and the users maybe did not understand how their scores were calculated nor the impact of creating a topic or commenting on different posts. After this first analysis, we may validate in this group hypothesis (H1) - "Giving feedback to the students as a visible tag of their current level of participation triggers participation", since users C and F dramatically changed their ranks after noticing their status. In the same way, we confirm for this group hypothesis (H2) - "The use of public blogs and forums helps students to work collaboratively on their assignments" after examining the kind of threads and blog entries created, that were related to asking for help while performing their tasks. Finally, we confirm for this group hypothesis (H3) as well - "The possibility of rating peers’ assignments boosts participation when asking or offering help", since this element was positively used by students to improve their ranks. Table 2 summarizes the mean score given to each item in the questionnaire taken by the group of students at the end of their course: Table 2. Mean Score given to each Item in the Questionnaire

Item Do you think the social features of the website make it more attractive? Do you think the rank given to you in the website (HIGH – MEDIUM – LOW) motivated you to participate more in the website? Were you interested in using the website to ask for help when doing your assignments? Do you think you improved your learning by discussing the blogs or forums in the website with your classmates?

Mean Score (Out of 5) 4.50 4.33 4.17 3.83

26

F. Gutierrez, N. Baloian, and G. Zurita

Hypothesis (H4) – “End-users feel the website is more attractive when there are social functionalities” – was validated in this group. In fact, the mean score given to this item in the questionnaire was the highest one of all. In an open question, we asked the students to state the elements they considered to have motivated them to participate on a website. The range of answers here starts from standard web 2.0 tools (such as blogs and forums), towards a more interactive and synchronous participation in the form of online chat rooms (because they think it takes time to get replies in a blog or forum). One of the students also stated the use of the “my state” feature (a microblogging service, in the same spirit as Facebook status and Twitter). Hypotheses (H5) – “End-users feel that a rating system motivates them to participate in the community” – and (H6) – “End-users feel this kind of platform allows them to work better during their assignments” – were related to the interest of the students towards the website when working and participating. We may also validate them according to the mean score given to each item by this particular group. However, some students criticize the fact that the lessons, worked examples and supports were not updated regularly enough and there was a lack of feedback and comments from professors in order to encourage them to participate more between them (some students feel the others are too proud to ask and offer any kind of help). Finally, from the results of hypothesis (H7) – “End-users feel that this kind of platform finally improved their learning” – we conclude there has to be a strong feedback from professors in order to encourage students to participate, as well as enhancing the values of collaboration and of the community. Perhaps, a teacher should take a more active role in the form of a “community manager”, going further than sharing knowledge and enabling students to ask and offer help while doing their assignments. It is worth pointing out that these claims are only applicable to this specific group, because it is not statistically representative (the number of users and the duration are too slam to produce significant results) and since it is not clear if the contribution trends will continue of the experiment lasts longer. In fact, previous work [20, 21] shows that contribution levels usually spike after introducing the incentive mechanism but later they decline, which could be due to the “novelty effect”. This first field experience was a very short-term study aimed to explore the usefulness of the research methodology.

5 Future Work This paper presents the first results on this research. In order to validate the model we propose, we are currently testing the design of the other functionalities with a group of Chilean high-school students (14-18 years old) and teachers, in collaboration with Innovacien (http://www.innovacien.org), a centralized network of schools. These schools are physically separated from one another (some of them in different cities), and they work independently on different learning projects guided by this group. By developing this virtual community, we aim to make the different groups to interact with each other and finally work collaboratively. This virtual community will be in service during, at least, for three months and it will serve as support to the educational projects carried out by this group. Moreover,

Boosting Participation in Virtual Communities

27

students and teachers will have a place where they are able to collaborate in order to achieve common goals, as well as have a central communication hub. Our goal with this experiment is to measure how and why the different elements involved in a virtual community are used, quantify the degree of participation before and after enabling in the community our designed features and, as a general objective, analyze the ways that impact the group members' behavior in order to trigger motivation and boost participation. This virtual community was developed taking the framework we designed and using the social networking engine Elgg with some minor and major modifications in its core structure. It runs under an Apache-MySQL-PHP environment supported by Innovacien. Also, a set of customized plugins was developed in order to test each social feature. Members are divided in three categories: system administrators, group leaders (which will be mainly teachers) and students. Each role interacts within its scope, defined by the project that they are enrolled in. Teachers will also have access to guidelines prepared by Innovacien in order to work smoothly with their students. In a future work, we plan to redefine this framework in order to be able to deal with mobile virtual communities, as well as exploring the pertinence and impact of using these social functionalities. Some ideas to explore at this stage are the use of geolocation support and audio-user interfaces (AUI) to ensure mobility. We will also explore the use of web standards (HTML5 and CSS3) and how this impacts the development of these kinds of applications in different kinds of devices, both desktop-based and mobile. The last stage of this research will concern decision-making patterns, as well as intelligent recommender social algorithms in collaborative and cooperative relationships.

6 Conclusions In this paper we presented the design of a model of functionalities that may have an impact on boosting participation in virtual communities. Finding ways to trigger motivation in social groups will have a wide impact on a large group of fields, from ebusiness, marketing and management where companies use social media techniques for generating revenues and increasing their market share, to education, where boosting participation will be reflected in a better learning experience. We explored one of the features we designed in a group of college students and the results are quite promising. As this paper is being developed, we are performing experiments testing the other functionalities defined in the proposed model. We learned from this first experiment that the members of a virtual community can easily adopt this initial approach, as it was positively revealed during this experience. Therefore, we will carry out more elaborated research trying to test more social features, as well as evaluating the perceived impact on the members. We will also quantify the eventual changes on the level of participation of each user and refine the model in order to develop a methodology for designing social features to boost participation in virtual communities. In a future work, we will study the effects of such a redefinition in mobile virtual communities, mainly working with geolocation features and audio-user interfaces. We will also explore the use of Web Standards, such as HTML5 and CSS3, and analyzing

28

F. Gutierrez, N. Baloian, and G. Zurita

the pertinence of decision-making patterns and algorithms, as well as intelligent recommender systems. Finally, a conceptual design model that would help the task of design for participation will come out as a result of analyzing the impact of these functionalities in different kinds of communities.

References 1. Alexa: The Web Information Company (February 15, 2009), http://www.alexa.com 2. Figallo, C.: Hosting Web Communities: Building Relationships, Increasing Customer Loyalty and Maintaining a Competitive Edge. John Wiley & Sons, Chichester (1998) 3. Wellman, B., Gulia, M.: The Network Basis for Social Support: A Network is More than the Sum of its Ties. In: Wellman, B. (ed.) Networks in the Global Village, pp. 83–118. Westview Press, Boulder CO (1999) 4. Butler, B.: Membership Size, Communication Activity and Sustainability: A ResourceBased Model of Online Social Structures. Information Systems Research 12(4), 346–362 (2001) 5. Bishop, J.: Increasing Participation in Online Communities: A Framework for HumanComputer Interaction. Computers in Human Behavior 23, 1881–1893 (2007) 6. Preece, J., Nonnecke, B., Andrews, D.: The Top Five Reasons for Lurking: Improving Community Experiences for Everyone. Computers in Human Behavior 20, 201–223 (2004) 7. Kim, A.J.: Community Building on the Web: Secret Strategies for Successful Online Communities. Peachpit Press, Berkeley (2000) 8. Vassileva, J.: Motivating Participation in Peer to Peer Communities. In: Petta, P., Tolksdorf, R., Zambonelli, F. (eds.) ESAW 2002. LNCS (LNAI), vol. 2577, pp. 141–155. Springer, Heidelberg (2003) 9. Miller, K., Fabian, F., Lin, S.-J.: Strategies for Online Communities. Strategic Management Journal 30, 305–322 (2009) 10. Wang, Y., Fesenmaier, D.: Understanding the Motivation of Contribution in Online Communities: An Empirical Investigation of an Online Travel Community, Illinois (2001) 11. Konow, R., Tan, W., Loyola, L., Pereira, J., Baloian, N.: Using Recommender Systems to Improve Revenues from Advertising in e-Content Sites (2010) 12. Davies, J., Graff, M.: Performance in e-Learning: Online Participation and Students Grades. British Journal of Educational Technology 36, 657–663 (2005) 13. Preece, J., Shneiderman, B.: The Reader-to-Leader Framework: Motivating TechnologyMediated Social Participation. AIS Transactions on Human-Computer Interaction, 1(1), 13–32 (2009) 14. Janzik, L., Herstatt, C.: Innovation Communities: Motivation and Incentives for Community Members to Contribute. In: Management of Innovation and Technology, ICMIT, pp. 350–355 (2008) 15. Girgensohn, A., Lee, A.: Making Web Sites Be Places for Social Interaction. In: CSCW 2002 Proceedings of the 2002 ACM Conference on Computer Supported Cooperative Work, New York (2002) 16. Koh, J., Kim, Y.-G., Butler, B., Bock, G.-W.: Encouraging Participation in Virtual Communities. Communications of the ACM 50 (2007)

Boosting Participation in Virtual Communities

29

17. Brandtzaeg, P., Heim, J.: User Loyalty and Online Communities: Why Members of Online Communities are not Faithful. In: Proceedings of the 2nd International Conference on Intelligent Technologies for Interactive Entertainment, Brussels (2007) 18. Arguello, J., Butler, B., Joyce, E., Kraut, R., Ling, K., Rosé, C., Wang, X.: Talk to Me: Foundations for Successful Individual-Group Interactions in Online Communities. In: Proceedings of CHI 2006, Montreal (2006) 19. Beenen, G., Ling, L., Wang, X., Chang, K., Frankowski, D.: Using Social Psychology to Motivate Contributions to Online Communities. In: CSCW 2004, Chicago (2004) 20. Cheng, R., Vassileva, J.: User Motivation and Persuasion Strategy for Peer-to-Peer Communities. In: Proceedings of the 38th Hawaii International Conference on System Sciences, Hawaii (2005) 21. Cheng, R., Vassileva, J.: Design and Evaluation of an Adaptive Incentive Mechanism for Sustained Educational Online Communities. User Modeling and User-Adapted Interaction 16, 321–348 (2006) 22. Luford, P., Cosley, D., Frankowski, D., Terveen, L.: Think Different: Increasing Online Community Participation Using Uniqueness and Group Dissimilarity. In: CHI 2004, Vienna (2004) 23. Burke, M., Marlow, C., Lento, T.: Feed Me: Motivating Newcomer Contribution in Social Network Sites. In: CHI 2009, Boston (2009) 24. Tedjamulia, S., Olsen, D., Dean, D., Albrecht, C.: Motivating Content Contributions to Online Communities: Toward a More Comprehensive Theory. In: Proceedings of the 38th Hawaii International Conference on System Sciences, Hawaii (2005) 25. http://edtech.kennesaw.edu/intech/cooperativelearning.html (last consulted on February 26, 2011) 26. Trentin, G.: Networked Collaborative Learning: Social Interaction and Active Learning. Chandos Publishing, Oxford (2010) 27. Baker, E.L., Mayer, R.E.: Computer-Based Assessment of Problem Solving. Computers in Human Behavior 15, 269–282 (1999) 28. Reeves, T.C.: Alternative Assessment Approaches for Online Learning Environments in Higher Education. Journal of Educational Computing Research 23, 101–110 (2000) 29. Sluijsmans, D., Martens, R.: Performance Assessment in Integrated e-Learning. In: Jochems, W., Van Merriënboer, J., Koper, R. (eds.) Integrated E-Learning: Implications for Pedagogy, Technology & Organization, pp. 39–50. Routledge Farmer, London (2004) 30. Lebrun, M.: Des Technologies pour Enseigner et Apprendre. De Boeck Université, Brussels (2007) 31. Lebrun, M.: E-Learning pour Enseigner et Apprendre. De Boeck Academia Bruylant, Louvain-la-Neuve (2005) 32. Vonderwell, S., Zachariah, S.: Factors that Influence Participation in Online Learning. Journal of Research on Technology in Education (2005) 33. Gutierrez, F.: Développement de Fonctionnalités de type Réseau Social pour l’Apprentissage Mobile – Étude de Cas sur l’Application Parlez-vous Chinois? In: Engineering Internship report at Centre d’Appui aux Pratiques d’Enseignement, Ecole des Mines de Nantes, Ecole Centrale de Nantes, Nantes (2010) 34. Laghos, A.: E-Learning Communities. In: Zaphiris, P., Siang Ang, C. (eds.) Social Computing and Virtual Communities, pp. 69–89. Taylor and Francis Group, Boca Raton (2010) 35. Porter, J.: Designing for the Social Web, pp. 21–40. New Riders, Berkeley (2008)

Context-Awareness on Software Artifacts in Distributed Software Development: A Systematic Review Rafael Leonardo Vivian1, Elisa Hatsue Moriya Huzita1, Gislaine Camila Lapasini Leal2, and Ana Paula Chaves Steinmacher3 1

Department of Computer Science, State University of Maringá, Maringá-PR, Brazil 2 Department of Production Engineering, State University of Maringá, Maringá-PR, Brazil 3 Coordination of Computer Science, Technological Federal University of Paraná, Campo Mourão-PR, Brazil {rlvivian.uem,chavesana}@gmail.com, [email protected], [email protected]

Abstract. Distributed Software Development (DSD) has brought several competitive advantages, but also many challenges, such as communication among physically distributed teams. In order to establish the collaboration in software development, communication and awareness on artifacts generated and shared among team members are essential. The purpose of this article is to present a systematic review identifying papers in the current literature that address acquisition and presentation techniques of contextual information when software artifacts are generated or updated in DSD. Some important properties and contextual information, such as relationship among artifacts and their change history during the software development, were identified and are presented as well. Keywords: Awareness, Contextual Information, Artifacts, Global Software Development, Collaboration.

1 Introduction Nowadays, organizations are seeking greater competitiveness by increasing product quality, improving productivity and distributing their activities. This is also reflected in software development, leading to increased adoption of Distributed Software Development (DSD) by organizations [1,2]. DSD has provided advantages but has also brought new challenges to software projects, such as cultural and language differences, trust, coordination and control, communication and knowledge management, caused by physical dispersion and temporal distance [3,4]. According to Jiménez et al. [5], studies and related literature combining DSD and awareness have increased, which motivated us to perform this research. Awareness represents the understanding of the activities of others, which provides a context for the individual's own activity [6]. Awareness techniques combined with A.S. Vivacqua, C. Gutwin, and M.R.S. Borges (Eds.): CRIWG 2011, LNCS 6969, pp. 30–44, 2011. © Springer-Verlag Berlin Heidelberg 2011

Context-Awareness on Software Artifacts in Distributed Software Development

31

contextual information of the environment improve communication among individuals involved in collaborative work [7]. Awareness mechanisms are essential to offer individuals contextual information about the actions that occur on the entities such as software artifacts. However, physical dispersion and temporal distance among collaborative teams hinder awareness of contextual information about the creation and maintenance of software artifacts. This is turn affects the understanding of development teams on objects resulting from cooperative work. In this paper, a systematic literature review is presented on awareness support in distributed development environments. The objective was to identify awareness studies featuring techniques of acquire and present contextual information on software artifacts generated in distributed software development. The systematic review also identified aspects upon which researchers have focused until now, and so, allowing us to analyze and identify current challenges and opportunities for future works. This paper is organized as follows. Section 2 describes the systematic review procedure applied; Section 3 presents the results obtained from the review; Section 4 summarizes and discusses the opportunities identified in this review; and finally, Section 5 provides the findings and limitations of this review.

2 Method A systematic review is a process of evaluation and interpretation of all available research related to a research question or topic of interest [8]. Kitchenham [8] also discusses several reasons to conduct a systematic review, the most common being to synthesize the available research on a treatment or technology, identifying issues for research and formulation a new position in research activities. As described in Kitchenham [8], this section presents the review protocol used, which consists of the following stages: (i) research questions; (ii) search strategy; (iii) criteria and selection procedures; (iv) quality assessment; and (v) data extraction and synthesis. 2.1 Research Questions In order to examine the evidence of the state of research on context-awareness on DSD software artifacts, the following research questions were considered: RQ1: What sources of information and visual resources have been used to implement, respectively, the acquisition and presentation of contextual information on the development of software artifacts in DSD? RQ2: What types of software artifacts are addressed by research concerning contextawareness? RQ3: What contextual information and properties are important for contextawareness on software artifacts in DSD?

32

R.L. Vivian et al.

2.2 Search Strategy The literature search consisted of two stages. In stage 1, we conducted a manual search in conferences, workshops and journals. We looked for full papers focusing on awareness and DSD, written in English and Portuguese, published between 2000 and 2010. The conferences, workshops and journals, selected based on consultations with experts, are presented in Table 1. Table 1. Conferences, workshops and journals selected Type Conference

Workshop

Journal

Source Conference on Collaboration and Technology Conference on Computer Supported Cooperative Work Conference on Computer Supported Cooperative Work in Design European Conference on Computer-Supported Cooperative Work International Conference on Global Software Engineering Brazilian Symposium on Collaborative Systems International Workshop on Distributed Software Development International Workshop on Global Software Development Global Sourcing Workshop Workshop on Distributed Software Development ACM Queue Advances in Engineering Software Communications of the ACM Computer Empirical Software Engineering IEEE Software IEEE Transactions on Software Engineering Information and Software Technology Information Systems Research Information Technology and People Journal of Systems and Software Journal of the Brazilian Computer Society

Acronym CRIWG CSCW CSCWD ECSCW ICGSE SBSC DiSD GSD GSW WDDS ACMQ AES CACM IEEEC ESE IEEESW TSE IST ISR ITP JSS JBCS

In stage 2, electronic databases were searched using the keywords “distributed software development” and “context-awareness” listed in Table 2. Keywords in each category were combined using the Boolean operator “OR”; both categories were then combined using the Boolean operator “AND”. The databases searched were: - IEEE Xplore (http://ieeexplore.ieee.org) - ACM Digital Library (http://portal.acm.org/dl.cfm) - EI Compendex (http://www.engineeringvillage.org) - ScienceDirect (http://www.sciencedirect.com) - Scirus (http://www.scirus.com)

Context-Awareness on Software Artifacts in Distributed Software Development

33

Table 2. Keywords used in this work Reference C1

Category Distributed Software Development

C2

Context-Awareness

Keywords Global software development Geographically distributed development Collaborative development Distributed development Distributed software project Global software engineering Globally distributed work Distributed teams Global software teams Collaborative work Virtual teams Context-aware Awareness Context-sensitive

As in stage 1, during stage 2 we looked for full papers focusing on awareness and DSD, written in English and Portuguese, published between 2000 and 2010. The search string was defined as a combination of C1 and C2 using the Boolean operators “AND” and “OR”, as presented below: (“distributed software development” OR “global software development” OR “geographically distributed development” OR “collaborative development” OR “distributed development” OR “distributed software project” OR “global software engineering” OR “globally distributed work” OR “distributed teams” OR “global software teams” OR “collaborative work” OR “virtual teams”) AND (“contextawareness” OR “context-aware” OR “awareness” OR “context-sensitive”). The search string was adapted for each database, since the search options differ and the manner in wich the string must be built is specific for each engine. 2.3 Criteria and Selection Procedures After the studies were obtained, using the search string in the selected data sources, the papers were analyzed considering the relevance to research questions, according to the inclusion (I) and exclusion (E) criteria, defined as follows: I1. Sources of information and visual resources used to implement, respectively, the acquisition and presentation of contextual information on the development of software artifacts in DSD. I2. Types of software artifacts addressed by research on context-awareness. I3. Contextual information and important properties for context-awareness on DSD software artifacts. E1. Sources of information and visual resources that are not used to implement, respectively, the acquisition and presentation of contextual information on software artifacts development in DSD.

34

R.L. Vivian et al.

E2.Types of software artifacts addressed by studies that are not related to contextawareness. E3. Contextual information and properties that are not important for understanding context-awareness on software artifacts in DSD. The steps of this process were: (i) read the articles titles and abstracts, and then exclude those deemed irrelevant to the research questions; (ii) the papers selected in the previous step were read in full; and (iii) after reading, the selected papers were documented on a pre-defined form. 2.4 Quality Assessment Data obtained from quality assessment of studies can be used to develop a detailed criterion for inclusion/exclusion and/or to help data analysis and synthesis [8]. In our case, the quality assessment of studies was used mainly as a means to guide the interpretation of results for data analysis and synthesis [8], in order to avoid misinterpretation of results. The assessment goal was not to classify the studies according to a total quality score, so no score was assigned. Thus the binary scale was used to classify them, considering the criteria defined by Dyba [9] as follows: a) Is the article based on research or is it merely a “lessons learned” report based on expert opinion? b) Is there a clear statement of the aims of the research? c) Is there an adequate description of the context in which the research was carried out? d) Was the research design appropriate to address the aims of the research? e) Was the recruitment strategy appropriate to the aims of the research? f) Was there a control group with which to compare treatments? g) Was the data collected in a way that addressed the research issue? h) Was the data analysis sufficiently rigorous? i) Has the relationship between researcher and participants been adequately considered? j) Is there a clear statement of findings? k) Is the study of value for research or practice? 2.5 Data Extraction and Synthesis Data from selected studies were extracted according to a pre-defined form. This allowed us to record the details on standard items about the papers. Thus, the data extracted were author, title, source, year, volume, pages, abstract, keywords and features discussed. In addition, all papers were categorized based on the classification used in Zelkowitz and Wallace [10]. The categories used in the review were: (i) case study; (ii) experimental; (iii) literature review; (iv) lessons learned; and (v) simulation. We used JabRef, an Open Source reference manager, to support the extraction and recording information on the studies.

Context-Awareness on Software Artifacts in Distributed Software Development

35

Once the data on the studies were recorded, a quantitative and qualitative analysis was applied. From this analysis, characteristics and properties were identified according to the objectives and research questions proposed, as reported on Sections 3 and 4.

3 Results The review was conducted over a period of three months between September and November 2010, according to the plan presented in Section 2. After performing the procedures defined in Sections 2.1, 2.2 and 2.3, a total of 32 primary studies were selected, as illustrated on Fig. 1. As shown on Fig. 1, 498 studies were found from the manual search and implementation of the search string. Then, based on reading the title and abstract, 64 studies were pre-selected. Next, with the selection process, comprising the complete reading of the papers, 32 studies were selected for in-depth analysis.

Fig. 1. Filtering of studies and the final number of primary studies

Table 3 shows the distribution of studies according to search source. As shown, the lack of a standard terminology in the subject DSD combined with context-awareness resulted in a large number of papers found (498). However, only some were selected (32) according to the inclusion and exclusion criteria as defined in Section 2.3. The

36

R.L. Vivian et al.

number of articles found in conferences underscores the importance of conducting searches in the conference proceedings in the field. Table 3. Distribution of the studies found in accordance with to source Source

Papers found

Conferences Workshops Journals IEEE ACM Compendex ScienceDirect Scirus Total

114 32 44 83 24 136 17 48 498

Exclusion (pre-selection) title + abstract 12 3 9 17 5 14 2 2 64

Exclusion (selection) complete reading 7 2 5 8 0 7 1 2 32

Primary studies found 7 2 5 8 0 7 1 2 32

The number of primary studies published per year indicates that the subject context-awareness on software artifacts in DSD had not been widely studied until a few years ago. Fig. 2 shows that 2010 is the year in which the largest number of studies was published, taking into account that the research was completed in November of that year. The results show an increase in research related to contextawareness, highlighting its importance in scientific community.

Fig. 2. Number of primary studies published per year

The 32 studies included in this review are presented in the Further Reading Section, with numbers preceded by PS (Primary Study) to distinguish them from the numbering of References. Table 4 presents the application of criteria for evaluating the quality of the studies, with a (√) indicates “yes” and a blank space indicates “no”. The list of criteria is developed in Section 2.4.

Context-Awareness on Software Artifacts in Distributed Software Development

37

Table 4. Quality assessment of the studies Ref. [PS01] [PS02] [PS03] [PS04] [PS05] [PS06] [PS07] [PS08] [PS09] [PS10] [PS11] [PS12] [PS13] [PS14] [PS15] [PS16] [PS17] [PS18] [PS19] [PS20] [PS21] [PS22] [PS23] [PS24] [PS25] [PS26] [PS27] [PS28] [PS29] [PS30] [PS31] [PS32]

a √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √

b √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √

c √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √

d

e

f

g

h

i

j √ √ √

√

√ √

√

√

√

√

√

√ √ √

√

√

√

√

√

√

√ √ √ √

√

√ √ √

√ √ √

√ √ √

√ √

√ √

√ √

√ √

√

√

√

√

√

√

√ √

k √ √ √ √ √ √ √ √ √

√ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √

√

√ √ √ √ √

√ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √

Table 5 shows the distribution of studies according to the categories defined in Section 2.5. Table 5. Category of the studies Category Experimental

Lessons learned Literature review

Studies [PS02], [PS03], [PS04], [PS05], [PS06], [PS07], [PS08], [PS09], [PS10], [PS11], [PS13], [PS14], [PS15], [PS16], [PS17], [PS18], [PS19], [PS21], [PS22], [PS23], [PS24], [PS25], [PS26], [PS27], [PS28], [PS29], [PS30], [PS31], [PS32] [PS12], [PS20] [PS01]

Frequency 29

2 1

38

R.L. Vivian et al.

4 Discussion This section summarizes and discusses the contents and characteristics of the primary studies, found through systematic review, in order to extract relevant information. Thus, this section is structured according to the research questions as defined in Section 2.1. The citations for the 32 primary studies included in this section are presented in Further Reading Section. What sources of information and visual resources have been used to implement, respectively, the acquisition and presentation of contextual information on the development of software artifacts in DSD (RQ1)? Sources of information were identified for 31 primary studies, as shown in Table 6, corresponding to RQ1. In central repository, a repository system makes it possible to manage the artifacts, offering benefits such as a consistent method to handle and access all information on the artifact in the repository [PS04]. In local workspace, each team member can access the awareness information of the artifact through the other developer's local workspace [PS02]. In version control systems, the log files include information about the changes that each team member makes, the affected files, the number of changes and differences between the old and new versions of the files [PS12]. In text, information in emails or instant messengers discussing specific references about an artifact, for example a bug or piece of code [PS08]. In bug tracking, discussions about the design and implementation of an artifact can be monitored [PS27]. In continuous integration, automated build detects integration errors, immediately informing the team about failures [PS20]. Table 6. Sources of information considered in primary studies Information Source Studies Central repository

Local workspace

Version control systems Text Bug tracking Continuous integration

[PS02], [PS04], [PS05], [PS06], [PS07], [PS08], [PS10], [PS12], [PS14], [PS15], [PS16], [PS18], [PS20], [PS22], [PS23], [PS27], [PS28], [PS31] [PS02], [PS04], [PS09], [PS13], [PS17], [PS18], [PS21], [PS22], [PS24], [PS25], [PS26], [PS27], [PS28], [PS29], [PS30], [PS32] [PS06], [PS07], [PS08], [PS12], [PS13], [PS15], [PS20], [PS26], [PS27], [PS28], [PS29], [PS31] [PS01], [PS03], [PS05], [PS08], [PS12], [PS16], [PS19], [PS28] [PS07], [PS12], [PS20], [PS27] [PS20]

Frequency (# of studies) 18

16

12

8 4 1

Context-Awareness on Software Artifacts in Distributed Software Development

39

Visual resources were identified for 18 primary studies, as shown in Table 7, corresponding to RQ1. In color, the text emphasized by color makes it easier to monitor and display the contributions of team members [PS32]. In graph, one can view the dependencies among artifacts [PS14]. In timeline, the developer can navigate through all the evolutions of the project that occurred during the project development cycle [PS29]. In zoom, a slider allows the developer to enlarge the image to view details [PS19]. Table 7. Visual resources considered in primary studies Visual resource

Studies

Color

[PS02], [PS03], [PS06], [PS13], [PS15], [PS18], [PS23], [PS25], [PS26], [PS27], [PS28], [PS29], [PS32] [PS03], [PS06], [PS10], [PS14], [PS17], [PS18], [PS24] [PS29] [PS19]

Graph Timeline Zoom

Frequency (# of studies) 13

7 1 1

What types of software artifacts are addressed by research concerning contextawareness (RQ2)? For 30 primary studies, software artifacts were identified such as: code, documentation and diagram, as shown in Table 8, corresponding to RQ2. From that, 46.6% involved code; 20% documentation; 10% UML diagram; 16.7% involved code, documentation and diagram; and, 6.66% addressed both code and diagram. Table 8. Software artifacts considered in primary studies Software artifact

Studies

Code

[PS02], [PS04], [PS06], [PS07], [PS08], [PS09], [PS10], [PS11], [PS12], [PS14], [PS15], [PS17], [PS20], [PS22], [PS23], [PS25], [PS26], [PS27], [PS28], [PS31], [PS32] [PS01], [PS02], [PS03], [PS05], [PS07], [PS10], [PS11], [PS14], [PS16], [PS18], [PS19] [PS02], [PS07], [PS09], [PS10], [PS11], [PS13], [PS14], [PS21], [PS29], [PS31]

Documentation

Diagram

Frequency (# of studies) 21

11

10

What contextual information and properties are important for context-awareness on software artifacts in DSD (RQ3)? For 23 primary studies, contextual information was identified as shown in Table 9, corresponding to RQ3. In change history, team members can see all changes made to the artifacts, because all changes are recorded to keep track of them [PS28]. In

40

R.L. Vivian et al.

relationship among artifacts, the dependency that a software artifact has with another is defined, during all stages of development, which increases the understanding of their construction [PS14]. In relationship artifact/tool, the tool used to generate the artifact is defined [PS04]. Table 9. Contextual information considered in primary studies Contextual information Change history

Relationship among artifacts Relationship artifact/tool

Studies [PS03], [PS04], [PS07], [PS13], [PS16], [PS18], [PS22], [PS25], [PS26], [PS27], [PS28], [PS29] [PS02], [PS04], [PS06], [PS09], [PS10], [PS11], [PS14], [PS18], [PS21], [PS26], [PS31] [PS04], [PS07], [PS08], [PS19], [PS26], [PS30], [PS32]

Frequency (# of studies) 12

11

7

For 14 primary studies, properties were identified, as shown in Table 10, correspondig to RQ3. Traceability represents the ability to describe and follow the life of an artifact developed during the software life cycle, propagating events related to changes in an artifact to the dependent artifacts and, thus, increasing the contextawareness on the project [PS14]. In filter and information search, the developer looks for artifacts of interest in applying search filters [PS08]. Table 10. Properties on software artifacts considered in primary studies Property on software artifacts Traceability Filter and information search

Studies [PS03], [PS04], [PS07], [PS09], [PS13], [PS14], [PS18], [PS26], [PS29], [PS31] [PS04], [PS07], [PS08], [PS19], [PS26], [PS30], [PS32]

Frequency (# of studies) 10 7

Besides contents and characteristics of primary studies summarized in this section, it is possible to highlight other research topics that can be explored. Firstly, studies that deal with awareness to overcome issues related to indication of which artifacts have consumed most effort among development teams were not found. Another research opportunity is related with context-awareness on all the software artifacts of project to the automatic generation of new software artifacts. Another point that could be better explored is related on how to obtain contextual information not only from central repository and the developer's own local workspace, but also from sources as tools for Software Configuration Management, as is the case with version control systems, bug tracking and continuous integration. With the purpose to present contextual information, most of the primary studies explore color to awareness on the software artifacts. However, Cepeda et al. [PS29] propose timeline as visual resource to understand the evolution of the artifact during

Context-Awareness on Software Artifacts in Distributed Software Development

41

the software development cycle. So, the merge of above discussed features could be an interesting research topic, once the acquisition of contextual information from tools such as Software Configuration Management and their presentation to development teams members would increase their awareness about the project. Also, keeping a change history and the relationship among software artifacts could increase the chances of traceability and, thus, propagate the communication in distributed teams through the context-awareness on software artifacts.

5 Conclusion This work presented a systematic review of techniques for acquisition and presentation of contextual information on generating software artifacts in DSD. It can provide support for further research focused on DSD environments. A systematic review aims to evaluate and interpret all available research related to a research question or topic of interest through a rigorous and reliable methodology [8]. The results were presented in two phases. In the first phase, quantitative data were presented, including the number of studies per selection phase, source search and year. In the second phase, the primary studies were synthesized and some characteristics of the state of art were discussed, according to the research questions. This allowed us to obtain an overview about the current state of the art on awareness support in DSD environments and the contributions and challenges were identified. The proposals found in the analyzed studies were, in general (57.6%), mainly concerned with the exploration of contextual information on software artifacts from central repository and the own local workspace of developer. Furthermore, it should be observed that tools for Software Configuration Management, such as version control systems, bug tracking and continuous integration, also store contextual information on the creation and maintenance of software artifacts. Also, for presentation of contextual information, the use of timeline added to visual resources as graphs and colors is an interesting alternative to visualize the evolution of artifact during the software development cycle. Another observed point is that more studies are necessary about traceability on software artifacts and so promote context-awareness of the changes on them. Change history added with information of relationship among artifacts become an important success factor increasing productivity and understanding among the members involved in the development process. This makes it possible to improve the communication and awareness among team members in colaborative work. Finally, it is necessary emphasize that the search was reduced to a limited number of search engines and were excluded the studies on the subject of DSD and contextawareness but not contributed with any significant method or technique in the research context. However, since this is a wide area, some these works present interesting parallels subjects for the development of this research, and, therefore, would be important study in a future work. Thus, some primary studies, mainly related to tools which are not included in the context of DSD, but are useful in areas related to communication and collaboration, were included as well.

42

R.L. Vivian et al.

Acknowledgments. The author Rafael Leonardo Vivian thanks CAPES (Coordenação de Aperfeiçoamento de Pessoal de Nível Superior) for financial support.

References 1. Audy, J., Prikladnicki, R.: Desenvolvimento Distribuído de Software: desenvolvimento de software com equipes distribuídas. Elsevier, Rio de Janeiro (2001) 2. Huzita, E.H.M., Silva, C.A., Wiese, I.S., Tait, T.F.C., Quinaia, M., Schiavone, F.L.: Um conjunto de soluções para apoiar o desenvolvimento distribuído de software. In: Proceedings of the Workshop de Desenvolvimento Distribuído de Software - II WDDS, pp. 101–110 (2008) 3. Herbsleb, J.D., Moitra, D.: Guest editor’s introduction: Global Software Development. IEEE Software 18(2), 16–20 (2001) 4. Ivcek, M., Galinac, T.: Aspects of quality assurance in global software development organization. In: Proceedings of the 31st International Convention, MIPRO 2008 (2008) 5. Jiménez, M., Piattini, M., Vizcaíno, A.: Challenges and Improvements in Distributed Software Development: A Systematic Review. In: Advances in Software Engineering, vol. 2009, pp. 1–14. Hindawi Publishing Corporation (2009) 6. Dourish, P., Belloti, V.: Awareness and coordination in shared workspaces. In: Proceedings of the ACM Conference on Computer-Supported Cooperative Work, CSCW 1992, pp. 107–114. ACM Press, New York (1992) 7. Herbsleb, J.D., Mockus, A., Finholt, T.A., Grinter, R.E.: Distance, dependencies, and delay in a global collaboration. In: Proceedings of the 2000 ACM Conference on Computer Supported Cooperative Work, CSCW 2000, pp. 319–328. ACM Press, New York (2000) 8. Kitchenham, B.A.: Guidelines for performing systematic literature reviews in software engineering. Technical report, EBSE-2007-001, UK (2007) 9. Dyba, T., Dingsoyr, T., Hanssen, G.K.: Applying systematic reviews to diverse study types: An experience report. In: ESEM 2007 First International Symposium on Empirical Software Engineering and Measurement, pp. 225–234 (2007) 10. Zelkowitz, M.V., Wallace, D.R.: Experimental models for validating technology. Computer 31(5), 23–31 (1998)

Further Reading [PS01] Mendoza-Chapa, S., Romero-Salcedo, M., Oktaba, H.: Group awareness support in collaborative writing systems. In: Proceedings of the Sixth International Workshop on Groupware, CRIWG 2000. IEEE Computer Society, Los Alamitos (2000) [PS02] Farshcian, B.A.: Integrating geographically distributed development teams through increased product awareness. Journal Information Systems 26(3), 123–141 (2001) [PS03] Lee, B.G., Hari Narayanan, N., Chang, K.H.: An integrated approach to distributed version management and role-based access control in computer supported collaborative writing. Journal of Systems and Software 59(2), 119–134 (2001) [PS04] Boldyreff, C., Nutter, D., Rank, S.: Active artefact management for distributed software engineering. In: Proceedings of the 26th Annual International Computer Software and Applications Conference, COMPSAC 2002. IEEE Computer Society, Los Alamitos (2002)

Context-Awareness on Software Artifacts in Distributed Software Development

43

[PS05] Dustdar, S., Gall, H.: Process awareness for distributed software development in virtual teams. In: Proceedings of the 28th Euromicro Conference. IEEE Computer Society, Los Alamitos (2002) [PS06] Sarma, A., Van Der Hoek, A.: Palantir: coordinating distributed workspaces. In: Proceedings of the 26th Annual International Computer Software and Applications Conference, COMPSAC 2002. IEEE Computer Society, Los Alamitos (2002) [PS07] Boldyreff, C., Brittle, J., Korhonen, C., Kyaw, P., Lavery, J., Nutter, D., Rank, S.: Webbased support for managing large collections of software artefacts. In: Proceedings of the 27th Annual International Computer Software and Applications Conference, COMPSAC 2003. IEEE Computer Society, Los Alamitos (2003) [PS08] Cheng, L.T., Souza, C.R.B., Hupfer, S., Patterson, J., Ross, S.: Building collaboration into IDEs. Queue 1(9) (2003) [PS09] Henrich, A., Morgenroth, K.: Supporting collaborative software development by context-aware information retrieval facilities. In: Proceedings of the 14th International Workshop on Database and Expert Systems Applications. IEEE Computer Society, Los Alamitos (2003) [PS10] Boldyreff, C., Nutter, D., Rank, S.: Supporting Collaboration Within the e-Science Community. In: Proceedings of the Requirements Capture For Collaboration in eScience (2004) [PS11] Chisan, J., Damian, D.: Towards a model of awareness support of software development in GSD. In: Proceedings of the 3rd International Workshop on Global Software Development (2004) [PS12] Gutwin, C., Penner, R., Schneider, K.: Group awareness in distributed software development. In: Proceedings of the 2004 ACM Conference on Computer Supported Cooperative Work, ACM, New York (2004) [PS13] Tam, J., Greenberg, S.: A framework for asynchronous change awareness in collaboratively-constructed documents. Journal Groupware: Design, Implementation and Use, 67–83 (2004) [PS14] De Lucia, A., Fasano, F., Francese, R., Oliveto, R.: Traceability Management in ADAMS. In: Proceedings of the International Workshop on Distributed Software Development, DiSD 2005, pp. 135–149 (2005) [PS15] Gutwin, C., Schneider, K., Paquette, D., Penner, R.: Supporting group awareness in distributed software development. Journal Engineering Human Computer Interaction and Interactive Systems, 383–397 (2005) [PS16] Adler, A., Nash, J.C.: Evaluating and implementing a collaborative office document system. Journal Interacting with Computers 18(4), 665–682 (2006) [PS17] Sarma, A., Van Der Hoek, A.: Towards awareness in the large. In: Proceedings of the International Conference on Global Software Engineering, ICGSE 2006, pp. 127–131. IEEE, Los Alamitos (2006) [PS18] Sinha, V., Sengupta, B., Chandra, S.: Enabling collaboration in distributed requirements management. IEEE Software 23(5), 52–61 (2006) [PS19] Tee, K., Greenberg, S., Gutwin, C.: Providing artifact awareness to a distributed group through screen sharing. In: Proceedings of the 2006 20th Anniversary Conference on Computer Supported Cooperative Work, pp. 99–108. ACM, New York (2006) [PS20] Damian, D., Izquierdo, L., Singer, J., Kwan, I.: Awareness in the wild: Why communication breakdowns occur. In: Conference on Global Software Engineering, ICGSE 2007. IEEE Computer Society, Los Alamitos (2007) [PS21] Nunes, V.T., Santoro, F.M., Borges, M.R.S.: Capturing Context about Group Design Processes. In: Proceedings of the 11th International Conference on Computer Supported Cooperative Work in Design - CSCWD 2007, pp. 18–23. IEEE, Los Alamitos (2007)

44

R.L. Vivian et al.

[PS22] Holmes, R., Walker, R.J.: Promoting developer-specific awareness. In: Proceedings of the 2008 International Workshop on Cooperative And Human Aspects Of Software Engineering, pp. 61–64. ACM, New York (2008) [PS23] Ignat, C.L., Oster, G.: Awareness of Concurrent Changes in Distributed Software Development. Journal on the Move to Meaningful Internet Systems, 456–464 (2008) [PS24] Antunes, P., Zurita, G., Baloian, N.: A model for designing geocollaborative artifacts and applications. Journal Groupware: Design, Implementation and Use, 278–294 (2009) [PS25] Duque, R., Noguera, M., Bravo, C., Garrido, J.L., Rodríguez, M.L.: Construction of interaction observation systems for collaboration analysis in groupware applications. Journal Advances in Engineering Software 40(12), 1242–1250 (2009) [PS26] Omoronyia, I., Ferguson, J., Roper, M., Wood, M.: Using developer activity data to enhance awareness during collaborative software development. Journal Computer Supported Cooperative Work 18(5), 509–558 (2009) [PS27] Ye, E., Neiman, L.A., Dinh, H.Q., Liu, C.: SecondWATCH: A workspace awareness tool based on a 3-D virtual world. In: Proceedings of the 31st International Conference on Software Engineering-Companion Volume, pp. 291–294. IEEE, Los Alamitos (2009) [PS28] Bani-Salameh, H., Jeffery, C., Al-Gharaibeh, J.: A Social Collaborative virtual environment for software development. In: Proceedings of the International Symposium on Collaborative Technologies and Systems, CTS 2010, pp. 46–55. IEEE, Los Alamitos (2010) [PS29] Cepêda, R.S.V., Magdaleno, A.M., Murta, L.G.P., Werner, C.M.L.: EvolTrack: improving design evolution awareness in software development. Journal of the Brazilian Computer Society, 1–15 (2010) [PS30] Christian, D., Rotenstreich, S.: An Evaluation Framework For Distributed Collaboration Tools. In: Proceedings of the Seventh International Conference on Information Technology: New Generations, ITNG 2010, pp. 512–517. IEEE, Los Alamitos (2010) [PS31] Lima, E.J.C., Xexeo, G.B., Souza, J.M.: ARARA - A collaborative tool to requirement change awareness. In: Proceedings of the 14th International Conference on Computer Supported Cooperative Work in Design, CSCWD 2010, pp. 134–139. IEEE, Los Alamitos (2010) [PS32] Salinger, S., Oezbek, C., Beecher, K., Schenk, J.: Saros: an eclipse plug-in for distributed party programming. In: Proceedings of the 2010 ICSE Workshop on Cooperative and Human Aspects of Software Engineering, pp. 48–55. ACM, New York (2010)

Interference Management Mechanisms and Socio-cognitive Constructs in Cooperative Relationships Hengameh Irandoust Defence Research & Development Canada Valcartier 2459 blvd. Pie-XI North, Quebec, QC, G3J 1X5 Canada [email protected]

Abstract. Collaboration tools are increasingly being used to allow distributed agents/individuals or teams to interact effectively to perform some tasks and achieve some goals. There have been many research efforts in providing comprehensive treatment of cooperation in teams or socio-technical systems. With a multi-disciplinary approach based on human factors research, organization studies, and artificial intelligence findings, this paper offers a conceptual framework in which cooperation and other social relationships can be defined in terms of the fundamental concepts of goal fit, intentionality, motivation, interference, and dependence. It is shown that social relationships are established and sustained by means of particular interaction mechanisms used for interference management, as well as socio-cognitive constructs that emerge from and feed these interactions. This framework can be used to determine the level of cooperation between different individuals or teams for a given task and therefore be used to better inform the requirements of the collaborative tools designed for them. Keywords: Cooperation, collaboration, interference management, goal fitness, shared mental models.

1 Introduction Collaboration tools are increasingly being used to allow distributed agents/individuals or teams to interact effectively to perform some tasks and achieve some goals. There has been an interest in understanding and modeling cooperative behavior and team dynamics both from social sciences and artificial intelligence, more particularly multiagent systems, studies. As in many artificial intelligence fields, the modeling goal requires a deconstruction of complex actions and behaviors, which retroactively, provides new insights for their study by social sciences. Adopting a multidisciplinary approach based on human factors research, organization studies, and artificial intelligence, this paper offers a conceptual framework in which cooperation, but also neighboring concepts such as collaboration, teamwork, or competition, are viewed as social relationships that can be characterized in terms of the fundamental concepts of goal fit, intentionality, motivation, interference, and dependence. It is shown that each social relationship brings into play a set of interaction mechanisms for interference A.S. Vivacqua, C. Gutwin, and M.R.S. Borges (Eds.): CRIWG 2011, LNCS 6969, pp. 45–56, 2011. © Springer-Verlag Berlin Heidelberg 2011

46

H. Irandoust

management and socio-cognitive constructs that emerge from and, in turn, feed these interactions. This framework, although more general in scope, can be used to determine the level of cooperation between different individuals or teams in a given activity and therefore be used to better inform the requirements of the collaborative tools designed for them. Section 2 discusses the general concepts that underlie cooperative and noncooperative relationships, such as goals, intentionality, interference, motivation, and dependence. In Section 3, the mechanisms used for interference management in cooperative relationships are developed and illustrated. The socio-cognitive constructs that provide ground for or emerge from cooperative contexts are discussed in Section 4. Section 5 provides concluding remarks and a brief discussion on the use of the framework for collaboration technology.

2 Basic Concepts A minimal condition for the establishment of a social relationship is co-existence in a physical or virtual space. When co-existing, agents (individuals or artificial agents) can be in a state of discretion, meaning that the agents’ actions are disjoint and each agent pursues its own agenda independently of the others. Social interaction begins when there is some kind of interference between the agents’ actions. When sharing an environment, the actions of an actor-agent x bring about changes in the state of the world that may affect other recipient-agents y at different degrees and at different points in time. Such interferences may be deliberate or not and can have positive or negative effects for their recipients. 2.1 Goals, Interference, and Intentionality It has been shown that intentionality is a necessary condition for cooperation [1]. This means that two agents cannot be considered as cooperating if they are not doing so intentionally, even if their actions incidentally achieve the same goal. Along the same line, we consider that for an agent y to consider that some social relationship can hold, it must recognize the actions of x as purposeful and goal-oriented. Thus, consequently to interference or in anticipation of it, agents perform some kind of goal recognition. This is not systematic, however, since some kinds of interference have to be dealt with immediately without any estimation of the goal or intention of the actor-agent. For example, in presence of imminent danger, an agent will attempt to neutralize or avoid the harm to be done without considering the reasons that led to that situation or the motivations of the agent causing that harm. Also, there are sometimes loose interferences among the activities of some agents x and y without x being aware of the motives or even the existence of y or vice versa. However, for social action to occur, actor-agents have to act purposefully and recipient agents have to be aware of the intentions of those agents who interfere with their goals. Goal recognition allows agents to recognize other cooperative agents but also non-friendly ones. For example, only the presence of the intent of causing harm will differentiate a danger (no intent, capability to harm) from a threat (intent and capability to harm).

Interference Management Mechanisms and Socio-cognitive Constructs

47

2.2 Goal Fit There are basically four possibilities of interference among co-existing agents: no interference, positive interference, combined interference, and negative interference. Positive interference occurs when the actions of an agent favor goal maintenance or goal achievement for another agent [2]. Cooperation and other cooperative relationships are naturally based on positive interference. Combined interference occurs when the same action has positive effects for one agent and negative ones for another. Exploitation1 is one such relationship. Yet, this is not a simple case, as it illustrates the complexity of goal recognition. In a situation of exploitation, recipientagents may not be aware of some of their goals being threatened or they may accept to concede those goals to satisfy some more immediate goals. Agents pursue different goals at different levels of abstraction, and therefore while some goals may be contradictory at one level, they can be consistent at another. Although, an agent y may be aware that agent x is exploiting its activities, it may still accept this situation to further some other goals, for instance in order to obtain some advantages, resources or opportunities that x can offer. Finally, there is negative interference when the effects of the action of one agent threaten the goals of the other. Here again, the kind of interference may be different at different goal levels. For instance, in an adversarial context such as a battlefield, although an agent x may be aware of the policy of an agent y that it considers as a hostile nation, it must, in that particular situation, be able to establish the hostile intent of y from the observed actions and determine whether that intent can be achieved in order to react to it. Essentially, the fit between the goals of two agents, at a given level, can be expressed as the goals being common, different, or simply compatible. Compatible or common goals can give rise to cooperative relationships. However, the goal fit can arise in different ways. For example, cooperation can occur opportunistically (realizing its benefits, agents cooperate to achieve common or different goals), but it can also be driven structurally (the environment requires / imposes / favors cooperative behavior). Teamwork is a particular kind of cooperation that illustrates the latter case, as it is always supported by an underlying organizational structure. Because they are embedded in an organizational context, teams have performance goals set by higher instances, and joint action is used as a means to achieve those goals, a feature that differentiates teams from other cooperating individuals or groups. According to Hoc’s [3] (loose) definition of cooperation, two agents are in a cooperative situation if they meet two minimal conditions: (i) Each one strives towards goals and can interfere with the other on goals, resources, procedures, etc.; (ii) Each one tries to manage the interference to facilitate the individual activities and/or the common task when it exists. This definition does not suppose the generation of a common goal or common plan, yet individual activities are not independent (there is positive interference or at least desire to produce positive interference). We would only add the conditions of compatibility of goals and bilateral intentionality to this definition. Cooperation would be defined as a relationship where purposeful agents positively interfere with the actions of other agents to further the achievement of a common goal or goals compatible with their own. 1

Italics are used for the first occurrence of a social relationship definition.

48

H. Irandoust

Indeed, commonality of goals is not a necessary condition for cooperation. Generally, cooperation is better defined in terms of mechanisms such as goaladoption [2] and facilitation [3] rather than that of a common goal. Positive interference, rather than pursuance of well-defined goals is probably the feature which best explains a phenomenon such as emergent cooperation. Similarly, antagonistic relationships cannot be defined uniquely in terms of (absence of) goal fit. Conflict, for example, is a state of discord caused by the actual or perceived opposition of needs, values and interests. It occurs when two or more parties seek to undermine each other’s goals or capabilities. Although generally associated to goal difference, conflict may also arise when parties with same goals do not agree on the manner to reach them. 2.3 Dependence Dependence is a strong case of interference. Different kinds of dependence have been distinguished [2,4], although not with the same definitions, including unilateral, mutual (x and y depend on each other for realization of common goal) and reciprocal (x and y depend on each other for realization of different goals). Cooperation is generally characterized by mutual dependence. But, cooperative agents can also be reciprocally dependent. However, more tight cooperative relationships, such as collaboration or teamwork, are based on mutual dependence. Competition describes a relationship where agents must compete for resources and/or pursue goals that cannot be achieved in a consistent manner. The action of each party threatens the achievement of the goal by the other. As either party tries to reach the goal, the attempts of the other party to reach the same goal is undermined. Competitive agents thus act at the same goal level. Teamwork and competition are symmetric relationships. Both are supported by underlying organizations or otherwise formal structures, which means that they are not initiated by agents’ inner motives. While the former is based on positive interference and mutual dependence, the latter is based on negative interference and reciprocal dependence. 2.4 Motivation Goal fit can be measured during the whole lifetime of a social relationship where agents interfere with each other’s goals. Naturally, goal fit is not the only trigger of cooperation. Interpersonal relationships are probably the most important factor in human contexts. Engaging in a cooperative relationship will be influenced by an agent’s representation of self and that of the potential partner [5]. Agents also need to have certain motivations to engage in a social relationship, based on what they perceive as being its feasibility, and the costs and benefits for the different parties. It is generally agreed that cooperation is a relationship where there is a fitness gain for all participants/agents. Cooperative has thus been opposed to competitive or individualistic orientations [5], as well as to altruistic, selfish, or spiteful behaviors [6]. Furthermore, cooperation can be conditional (e.g., based on the expectation that the recipient will later reciprocate) or unconditional (e.g., kindirected altruism) or still be some kind of group-selected altruism [7].

Interference Management Mechanisms and Socio-cognitive Constructs

49

3 Interference Management Mechanisms Social relationships are co-determined by the objectives pursued by agents, the intention and willingness of agents to take part in these relationships, and the actions they take that are relevant to the nature of those relationships. These actions or interferences are, in cooperative situations, channeled towards an efficient achievement of goals. As one moves from neutral to cooperative contexts (from left to right in Fig. 1), different interaction mechanisms come into play for interference management. These include: monitoring, communication, coordination, facilitation, goal adoption, and joint action. Figure 1 shows the associations between the interaction mechanisms (indicated by arrows) and the increasingly more prosocial states/relationships of coexistence, collective activity, cooperation and collaboration. Each interaction mechanism subsumes the previous (e.g., goal adoption implies communication).

Fig. 1. Interaction mechanisms in neutral and cooperative relationships

3.1 Monitoring The most basic type of mechanism, which holds as soon as there is co-existence, is monitoring. Agents observe each other, try to infer each others’ goals and determine whether these goals interfere with their own or not. Before explicit communication, human beings coordinate their actions by monitoring each other’s behavior or its results, and letting the others do the same [2]. As one moves towards collaborative contexts (in a team setting or not), agents are required to monitor the execution of the common task, to broadcast task failures or task irrelevance whenever they occur, and to replan doing the task if necessary.

50

H. Irandoust

Moreover, monitoring allows agents to anticipate each other needs and provide proactive assistance [8]. Monitoring also holds in non-cooperative situations where agents have to monitor other agents (adversaries or other known or unknown agents) in order to recognize their behavior, activities and plans as to predict their future actions and react accordingly. More generally, monitoring is the mechanism by which an agent creates an awareness of the current environment, which then enables it to dynamically adapt its behavior to that environment and the changes that occur therein. All agent actions are taken based on the observation of the results of previous actions and their effects on the environment. 3.2 Coordination As soon as there is interference, there is coordination. Coordination consists in (efficiently) managing conflicts or dependencies between actions, resources and individuals. Generally, coordination is situated at a planning level and viewed essentially as an important component of cooperative activities. But coordination has a much larger scope, including adversarial contexts. Coordination can be aimed at avoiding negative interference of other agents in the same environment, or consist of adapting one’s behavior to benefit from the circumstances that prevail in a given environment. In neutral situations, agents merely make use of weak coordination. As agents engage in cooperation, coordination is first used to avoid redundancy between the actions of different agents and then aimed at optimizing them so that the goal is achieved in an effective and efficient manner. These are examples of strong coordination. Coordination can be implicit or explicit, and can be reactive or deliberative. The necessity for coordination often surges from dependencies between agents’ actions and the need to meet constraints. Far from the idea that coordination is a weak type of cooperation, the concept must be interpreted purely in terms of a mechanism for interference management. Another evidence of this is the fact that even competition and conflict in all its forms require a certain degree of coordination. Indeed, it would be impossible to carry out such antagonistic relationships in a world where agents ignore each others’ actions and do not respond to them adequately. 3.3 Communication Despite its importance, communication, as observed in [2], is not a necessary component of social action and interaction. For example, one can harm another agent, which is a social action as another, without communicating with him. Also, many prosocial actions do not require communication, at least verbal communication. In fact, some kind of communication becomes necessary as soon as coordination alone becomes insufficient to manage interference. Collective activity requires some kind of communication, be it direct or indirect. Through communication, agents in cooperative relationships provide information to each other, establish interpersonal relationships, make their intentions explicit, influence one another and exchange information on common tasks, if any. Communication is necessary for establishing and maintaining cooperation.

Interference Management Mechanisms and Socio-cognitive Constructs

51

3.4 Facilitation Facilitation goes further than coordination in the sense that it is not only concerned with dependency management. One can facilitate other agents’ activities or facilitate other agents’ goal achievement, by many means, within a common task or simply by assistance. The antagonistic mechanism to facilitation is blocking, which consists in performing actions that aim at preventing an agent from achieving its goal(s). These are the two basic mechanisms that are respectively used in cooperative and conflicting relationships. In fact, when conflict does not concern the goals but only the means to achieve them, cooperation can be distinguished from conflict on the sole basis of positive/negative interference that is facilitation and blocking [3]. 3.5 Goal Adoption As mentioned before, cooperation in the large sense, requires no more than compatible goals. Goal adoption enables agents to cooperate on the same tasks and activities, creating a more integrated cooperative relationship. Altruistic, selfinterested, and truly cooperative agents can all adopt goals of other agents if they are interested in them [2]. In cooperative goal adoption, agents can adopt a common goal, or one can adopt the goal of the other. Help is an example of goal adoption; however, to be considered as cooperative, it must involve bilateral intentionality, i.e. the recipient agent must be aware of being helped. As a matter of fact, donating money or goods to individuals with whom no direct interaction has taken place cannot be considered as cooperation. When agents establish common goals together for mutual benefit, they direct their efforts and activities towards that goal in an efficient way. With jointly established goal, agents bring their cooperative activity as close as possible to a symmetric and positive relationship, and optimize their action coordination. 3.6 Joint Action Joint action is a prerequisite for collaboration, a strong form of cooperation. Only in joint action, where agents develop a common reference frame, share the same experience, and collaborate in an integrated manner, can they build a common situation awareness and situation understanding. As shown in Figure 1, collaboration, at the far end of the spectrum has more restrictive conditions than cooperation, implying a common goal and moreover, joint synchronous effort for its achievement. Collaboration means that agents perform an action together synchronously and synergistically, rather than perform sub-actions that can be united in a common goal at a more abstract level, which is the case of the more general concept of cooperation. Although often used interchangeably, some authors have rightly emphasized the difference between the two. For Baker [9], the defining characteristics of collaboration, as opposed to cooperation, are that the former requires joint action and a commitment to maintaining mutual understanding, whereas tasks may be achieved cooperatively by dividing responsibilities and adopting the goals of the other. In [10], collaboration is defined as ‘A coordinated, synchronous activity that is the result of a continued attempt to construct and maintain a shared conception of a problem.’ Cooperation, on the other hand, can be accomplished by a division of labour, or even

52

H. Irandoust

be reduced to ‘communication concerning goals’. Baker [9] puts it as follows: ‘Cooperation involves willingness on the part of the interlocutors to communicate their goals with a view to possibly obtaining shared goals, willingness to adopt the others’ goals when they do not conflict with one’s own, and the possible execution of plans to achieve goals by dividing task responsibilities. Collaboration involves continued effort to maintain a shared understanding of a problem representation, the existence of shared goals, and joint action designed to achieve them’.

4 Socio-cognitive Constructs Social relationships and the interaction mechanisms they employ require or give way to different socio-cognitive processes and behaviors, as shown with large arrows in Figure 2. 4.1 Mind Reading Mind reading is the cognitive corollary of monitoring. Mind reading is an ability which is referred to in cognitive psychology as the theory of mind [11]. This concept describes the ability of social beings to attribute mental states - desires, pretending, knowledge, etc. - to oneself and others and to understand that others have beliefs, desires and intentions that are different from one’s own [11]. Having a theory of mind allows one to represent the thoughts, desires, and intentions of others, to predict or explain their actions, and to posit their intentions. As defined, it enables one to understand that mental states can be the cause of - and thus be used to explain and predict - others’ behavior. These mental representations are the basic tool with which humans manage social life. Thus mind reading can be observed at the most general level of collectivity, i.e., co-existence.

Fig. 2. Socio-cognitive constructs related to neutral and cooperative relationships

Interference Management Mechanisms and Socio-cognitive Constructs

53

4.2 Trust In literature, a distinction is made between trust and reliability. The former being attached to ethical issues and the latter being relative to actions (i.e. trusting a professional to do his job right). Our view is that trust is in fact the expectation we have from other individuals to behave in a certain way. Trust is often associated to cooperative contexts, viewed in an ethically ideal sense: we would trust another person ‘to further our goals out of a sense that the person is truly cooperative, even in the absence of self-interest or fear of sanctions’ [12]. Yet, trust does not need to involve belief in the honesty, competence or morals of the other party. Some degree of trust is necessary for collective activity, otherwise interactions would not take place. Even persons engaged in criminal activities usually trust each other to some extent. This view is corroborated by the social theory perspective [13]. Coleman argues that placement of trust allows actions to be conducted based on incomplete information on the case in hand; that trust involves no commitment; that a time lag exists between trusting and the result of the trusting behavior, as well as between that result and the extension of trust. From this angle, trust is an observable behavior and not a moral issue. Trust is a statement about what is otherwise unknown – for example, because it cannot be verified, or is in the future. Trust is therefore already present in collective activity, but is strengthened as one moves towards more cooperative contexts. 4.3 Commitment Cooperation, as discussed, cannot be established without goals and social commitment to those goals. When cooperating, individuals assume that the other party has the intention to do a certain action, is capable and has the opportunity of doing it, and is committed to that action [2]. Commitment is an implicit or formal guarantee given to partners once a common goal has been adopted and as such is the most important structure of groups and organizations [2]. Social commitment creates rights and duties between two agents and allows a certain degree of predictability on their future behavior. It not only provides evidence of intentionality or joint purpose, it also allows interdependent individuals to fulfill their respective role while assuming that the others will do their part. This commitment makes an agent truly trustworthy of others. Commitment is absolutely a necessary condition for relationships such as cooperation and collaboration. 4.4 Shared Mental Models Shared mental models emerge when agents acting in the same environment, and performing the same task, are mutually involved in the perception of elements in the environment, analyze and make sense out of the information they perceive in that environment, and take actions in consequence. Shared mental models allow individuals to reason and perform functions within a common reference frame. Joint synchronous action, as in collaboration and teamwork, gives rise to shared mental models, which cover different types of knowledge: a common semantics; knowledge of goals; knowledge of each other’s capacities, knowledge, roles, interests; and a shared model of the situation in which the participants have to act or operate.

54

H. Irandoust

In a team setting, shared mental models have been defined as [14]: ‘knowledge structures held by members of the team that enable them to form accurate explanations and expectations for the task, and in turn, to coordinate their actions and adapt their behavior to demands of the task and other team members.’ Shared mental models mean: shared awareness of current context; common understanding of goals and plans; flexibility and dynamic adaptation to changes; anticipation of other agents’ needs; proactive communication and help; smooth coordination. In turn, shared mental models enable effective joint action. Thus there is a circular relation between shared mental models and collective endeavor, each one enabling the other. Viewing collaboration from an organizational, management perspective, Denise [15] notes that when agents collaborate, they arrive at a ‘shared understanding that neither party could, by itself, create or even derive’. Michael Schrage [16] writes: ‘... collaboration is the process of shared creation: two or more individuals with complementary skills interacting to create a shared understanding that none had previously possessed or could have come to on their own’. Collaboration creates a shared meaning about a process, a product, or an event. Cooperations are initiated mostly in response to performance goals or simply to new needs, to new constraints or to new opportunities. Collaborations are interpersonally rather than structurally determined and are oriented towards specific outcomes. They are about creativity, spontaneity, and fashioning a new approach [15]. This creativity is generated through the effort of participants to form a shared representation of the problem they solve together. Thus, ‘collaborations end in some common ground but they do not begin there’ [15].

5 Discussion In the preceding, it was argued that cooperative behaviors can be viewed as a spectrum where one moves from simple interference to mutual dependence, from monitoring and weak coordination to goal adoption and joint action, and from cognitive representation of intentionality to shared mental models. A set of social relationships were refined, by determining the basic mechanisms that they bring into play to manage interference and preserve goal fitness. It was also discussed that these interactions presuppose or give rise to particular mental states and social attitudes. As cooperative relationships become more integrated, constructs such as cognitive and ethical consideration give way to shared mental representations. We did not cover however the affective links that bond the actors/agents and the processes they use to maintain the group or team’s performance. Several social relationships were discussed, as we attempted to illustrate the interplay between goal fit and interference management. Cooperation and conflict were shown to be distinguishable only on the basis of positive and negative interference. Teamwork and competition, their organizational counterparts, were characterized by mutual and reciprocal dependence respectively. Collaboration was shown to be a tighter relationship than cooperation, involving joint action, common and sustained task representation, and synchronous effort. While trust and commitment are associated to cooperation at large, shared mental models were shown to arise only in collaborative action.

Interference Management Mechanisms and Socio-cognitive Constructs

55

The framework discussed here is aimed at the modeling of interference management in cooperative, neutral and adversarial relationships. Its application to collaboration tools is however evident as the latter are aimed at supporting cooperative relationships in socio-technical systems. The use of such tools is becoming widespread in different communities to support distributed individuals and teams engaged in collaborative planning, collaborative decision making and synchronized action. To be efficient, it is important that the content and the format of the information conveyed by these collaborative tools be tailored to the cooperation needs of the individuals/agents and teams involved and the context in which they perform their common task. The design of collaborative systems should be guided by questions such as: is the common task a collective effort involving some kind of coordination/facilitation or is it genuine teamwork where individuals are engaged in joint synchronous action? Are the individuals or the teams physically co-located having the benefit of a high level of high-quality interactions or do they have remote and thus less effective communications? What level of situation awareness and therefore what kind of interaction mechanisms have to be supported? Is it necessary for the different parties using a given system or the automated system itself to provide explanations of actions and recommendations to gain trust? More generally, what are the socio-cognitive constructs that have to be supported? Many factors, including the agents’ roles, needs and preferences, the task type and its inherent constraints, the communication capacities of the collaborative system, the environment (static or dynamic) and its constraints on the teams activities, all determine the level of desired and possible cooperation among a set of agents or teams. This picture of the situation determines the features and functionalities of the needed collaboration tools.

References 1. Bratman, M.E.: Shared Cooperative Activity. The Philosophical Review 101(2), 327–341 (1992) 2. Castelfranchi, C.: Modelling Social Action for AI Agents. Artificial Intelligence 182, 157– 182 (1998) 3. Hoc, J.-M.: Towards a Cognitive Approach to Human-Machine Cooperation in Dynamic Situations. International Journal of Human-Computer Studies 54, 509–540 (2001) 4. Wooldridge, M.: An Introduction to Multi-Agent Systems. John Wiley and Sons, Chichester (2002) 5. Abric, J.: Cognitive Processes Underlying Cooperation: The Theory of Social Representation. In: Cooperation and Helping Behavior: Theories and Research. Academic Press, London (1982) 6. Freeman, S., Herron, J.: Evolutionary Analysis, 2nd edn. Prentice-Hall, Englewood Cliffs (2001) 7. Giraldeau, L., Caraco, T.: Social Foraging Theory, Monographs in Behavior and Ecology. Princeton University Press, Princeton (2000) 8. Fan, X., Yen, J.: Modeling and Simulating Human Teamwork Behaviors Using Intelligent Agents. Physics of Life Reviews 1(3), 173–201 (2004) 9. Baker, M.: Le Rôle de la Collaboration dans la Construction d’Explications. Actes des Deuxièmes Journées Explication du PRC-GDR-IA du CNRS, 25–40 (1992)

56

H. Irandoust

10. Roschelle, J., Behrend, S.: The Construction of Shared Knowledge in Collaborative Problem Solving. In: Computer Supported Collaborative Learning. Springer, New York (1995) 11. Premack, D., Woodruff, G.: Does the Chimpanzee Have a Theory of Mind? Behavioral and Brain Sciences 1, 515–526 (1978) 12. Allwood, J., Traum, D., Jokinen, K.: Cooperation, Dialogue, Ethics. International Journal of Human-Computer Studies 53, 871–914 (2000) 13. Coleman, J.S.: Foundations of Social Theory. Harvard University Press, Harvard (1990) 14. Cannon-Bowers, J.A., Salas, E., Converse, S.: Shared Mental Models in Expert Team Decision Making. In: Castellan, N.J. (ed.) Individual and Group Decision Making, pp. 221–246. Lawrence Erlbaum Associates, Mahwah (1993) 15. Denise, L.: Collaboration versus C-Three (Cooperation, Coordination, and Communication). Innovating 7(3) (1999) 16. Schrage, M.: Shared Minds. Random House, NY (1990)

Motivation and Its Mechanisms in Virtual Communities Juliana de Melo Bezerra and Celso Massaki Hirata Computer Science Department, Instituto Tecnologico de Aeronautica - ITA, S.J. Campos, Brazil {juliana,hirata}@ita.br

Abstract. Participation is a key aspect of success of virtual communities. Participation is dependent on the members’ motivation that is driven by individual and environmental characteristics. This article investigates the individual and environmental factors that contribute to motivation and discusses mechanisms to improve motivation in virtual communities. The study is based on the Hersey and Blanchard’s motivation model, the Maslow’s hierarchy of needs, and the virtual community model. For the discussion of motivation mechanisms, we reviewed the literature and made qualitative interviews with members of the Wikipedia community. Keywords: Motivation, participation, virtual community.

1 Introduction Participation is seen as a measure of the success of virtual communities [29]. According to Wenger [34], participation refers to a process of taking part and also to the relations with others that affect this process. To be effective, participation requires both action and connection. In each virtual community there is a way to express participation, depending on the community objectives. For example, the participation in online forums, whose objective is information exchange, can be understood as posting and responding messages. Virtual communities are a particular kind of community. Members in general communicate, collaborate, and interact using a system. They may not know personally other members. In general, their main motivation to be part of the community is aligned with the community goals. Therefore it may not be easy to obtain participation of members in virtual communities if their motivation decreases or ceases. So, it is necessary to understand motivation in the virtual community context in order to manage it properly. Participation and motivation of members in virtual communities have attracted attention of researchers concerned with the encouragement of members in the community’s activities and the development of the community itself. Distinct communities are studied, for example, e-learning communities [15,18,38], online forums [4,9], open source communities [19,33], e-government communities [1,37], online crowdsourcing [20], online game communities [14], and open content communities [17,25,39] for different reasons. Some researchers are interested to A.S. Vivacqua, C. Gutwin, and M.R.S. Borges (Eds.): CRIWG 2011, LNCS 6969, pp. 57–72, 2011. © Springer-Verlag Berlin Heidelberg 2011

58

J. de Melo Bezerra and C.M. Hirata

identify the success factors for virtual communities, and analyze quantitatively or qualitatively the correlation among factors related to motivation, such as reputation, trust, and learning. In general these articles investigate distinct sets of factors. Tedjamulia et al. [31] discuss the importance of motivation mechanisms (called reinforcements) as contributors to members’ motivation in virtual communities. Other articles concern about both establishing motivation mechanisms and verifying if they improve members’ contributions, however they do not analyze the motivating factors as a way to improve or suggest motivation mechanisms in virtual communities. In this article we propose an approach to reason about motivation in virtual communities, in order to achieve an adequate participation level of members in the execution of the community activities. The approach is based on the identification of factors that contribute to motivation as well as the application of mechanisms that improve motivation by handling such factors. We conjecture that after understanding the factors, it is easier to propose motivation mechanisms. In order to understand the relationship between motivation and participation in virtual communities, we use both the Hersey and Blanchard’s motivation model [12] and the virtual community model [3]. As motivation is driven by personal characteristics of an individual and can be influenced by perceptions about the community itself [12], we review the literature to identify individual and environmental factors that contribute to motivation. With respect to individual factors, we consider the human needs model proposed by Maslow [22]. For environment factors, we consider norms and system as entities as part of virtual communities. After outlining the factors, we discuss existent motivation mechanisms in virtual communities, using examples of mechanisms provided in Wikipedia [36]. The article is organized as follows. Section 2 provides a discussion about motivation in virtual communities. Section 3 concerns about the identification of individual and environmental factors that influence motivation. Section 4 describes mechanisms to address the identified factors, using examples of Wikipedia. Section 5 provides discussions about this article. Section 6 concludes and indicates future work.

2 Motivation in Virtual Communities In this section we present our approach to reason about motivation in virtual communities. The approach is based on a motivation model proposed by Hersey and Blanchard [12], which is useful to understand the relation between motivation and participation. We investigate the relationship between the motivation model and the virtual community model in order to indentify the factors that influence motivation. 2.1 Motivation and Participation Motivation can be defined as an impulse to act according to the one’s desires. If people are forced to make something, they are reacting to the pressure. If they are motivated, they choose to realize something, because it has a meaning for them [35]. Hersey and Blanchard [12] propose a model, illustrated in Fig. 1, to explain the relation between motivation and behavior of individuals in organizations. We argue that the model is also suitable to explain how the participation of members in virtual communities is related to their motivation.

Motivation and Its Mechanisms in Virtual Communities

59

Motives are the origin of the behavior. They are something inside the individual that moves him/her to act. Objectives are outside the individual. Objectives can be understood as expected achievements that satisfy the motives. For example, a motive is starvation, and the associated objective is to be fed. The behavior includes activities performed by the individual in order to reach the objectives. In the previous example, the activities can be finding, preparing, and ingesting food. A person has a large number of motives, whose prioritization determines the strength of each motive. Urgent motives induce actions toward objectives to satisfy them, while less critical motives can wait to be handled. Hersey and Blanchard [12] note that the presence of objectives in the environment can also affect the motives’ intensity.

Fig. 1. Motivation model (adapted from [12])

The experiences of the individual are an internal agent responsible for the formation of expectative, which influences motives. The experiences comprise personality, intellectual education, spiritual and moral education, and values, which are acquired during life. Behavior aims to achieve objectives and can also contribute to the composition of experiences. The external stimuli refer to facilities or limitations that the environment imposes to the objectives’ achievement. For example, the objectives of a person can be influenced by the pattern of the group that he/she belongs, and also by the adjacent groups. External stimuli may be ephemeral or eventual, i.e. they can be seen as opportunities or temporal restrictions that may not persist or may occur in the future. Experiences and external stimuli influence each other. The attention regarding the external stimuli makes the person accumulates experiences. Iteratively, experiences offer methods to help the interpretation of external stimuli and the perception of future, so experiences can influence the way the individual perceives the environment. Behavior, or participation, dictates how the activities are performed by a person. Underperformed or badly performed activities can compromise the achievement of community’s goals. To stimulate one’s behavior, it is then necessary to act on his motivation. As motives are influenced by individual (the experiences) and environment (the external stimuli) factors, and we are interested on identifying these factors in virtual communities, we analyze the virtual community entities in the next section. 2.2 Virtual Community Preece [28] defines virtual community as a group of people, who come together for a purpose online, and who are governed by norms. Considering this definition, we

60

J. de Melo Bezerra and C.M. Hirata

consider three main entities that compose a virtual community model, proposed by Bezerra and Hirata [3], and illustrated in Fig. 2: members, norms and system.

Fig. 2. Virtual community model (adapted from [3])

Members are a group of people that belong to a community. Norms are specific to a social context, and they are generally established in order to regulate the people relationships. A norm is a type of principle, precept or rule that states obligation, permission, power attribution or competence attribution. In general a norm can be imperative (that imposes duties) and/or attributive (that confers rights) [26]. A virtual community is supported by an information system based on Internet technology (webbased system). The system, also named as community system, teamware, and groupware, is used as a means for the members to achieve the community goal. We relate the virtual community entities with the motivation model in Fig. 1 as follows. The individual factors, also called experiences, are inherent to members. The individual factors are in general associated to the human needs, considering the Maslow hierarchy [12,22] discussed later. According to Cottrell [7], performance can be enhanced or impaired in the presence of persons who can approve or disapprove our actions. Cottrell [7] argues that there are apprehensions or inhibitions related to the fact of having individuals organized in groups. So, we consider social fears as individual factors that influence motivation in virtual communities. The environmental factors, also called external stimuli, include the factors driven by the virtual community environment, which includes norms and system. The environmental factors are also influenced by the environment outside the virtual community, for example the political, religious and economics contexts, which can guide the definition of norms in virtual communities [3]. In this paper we consider the environmental factors restricted by the perspective of norms and system. Once one identifies individual and environmental factors that contribute to motivation in virtual communities, it is possible to propose mechanisms to address the critical ones. Motivation mechanisms can be designed and implemented in virtual communities through improvements and changes in the norms and system. It is expected that they act as external stimuli of individuals in the motivation model. As external stimuli, the mechanisms can improve motivation by encouraging individuals to realize benefits of new objectives and motives, in order to stimulate participation. One example of a motivation mechanism in an online forum is the mechanism that provides and manages a status (senior, guru, veteran, etc) to a member according to the number of questions and answers posted. The mechanism allows members to upgrade their status and induces them to establish objectives to satisfy their motive of improving reputation. So, moved by a motive, members can change their behavior

Motivation and Its Mechanisms in Virtual Communities

61

and increase their contribution to community, which characterizes an improvement of participation. It is important to note that a mechanism can affect members in different ways, because the individuals are unique due to their experiences.

3 Identification of Factors Related to Motivation In this section we identify individual and environmental factors that can motivate members in a virtual community. We investigate the individual factors through an inquiry into the human needs and social fears. We investigate the environmental factors through the identification of services and restrictions imposed by norms and system in a virtual community. 3.1 Identification of Individual Factors The study of human needs helps the identification of individual factors that affect motivation. Maslow [22] proposes a scheme to address human needs. It consists of a pyramid that reflects, through its levels, the intensity of each need. The pyramid, from the basis to the top, is composed by the following needs: physiological, safety, belonging, esteem, and self-actualization. Individuals behave towards the satisfaction of unsatisfied higher levels in the hierarchy. However, each individual has a personal combination of needs, which can lead to a deformation of the pyramid. The physiological needs are related to human vital needs of subsistence, for example air, food, shelter, and clothing. Once the physiological needs are satisfied, the influence of safety needs become relevant to the individual behavior. The safety needs are those related to self-preservation, which means to be free of the physical dangers and the privation of basic needs. They are related to the guarantee of the physiological needs in a predictable future. The physiological and safety needs are mainly related to the real world, because they are essentially of physical and economics order. Regarding virtual communities, we focus on the belonging, esteem and self-actualization needs. The identified factors are provided in Table 1. As people are social beings, they have the necessity to be part of a group and to be accepted by it, so the belonging needs constitute another level in the Maslow hierarchy of needs. The main factors associated to belonging needs are identification and socialization. Identification is the process whereby one individual want others to see oneself as unique in a group; it affects group cohesion and altruism [11]. Socialization is the process of learning the behaviors and attitudes essential to play a role in a group [5]. For virtual communities, Yamamoto et al. [37] suggest other social factors related to awareness in online public decision making, as a member usually wants that others inform their presence and opinion. After satisfying the need to participate of a group, in general the person desires not only to be a member, but also to receive the recognition of others. The respect of others sometimes increases the respect for oneself, contributing to esteem, the next level in the Maslow hierarchy. The esteem includes two factors: prestige and power [12]. Prestige is the need of a person to have your importance recognized in the group. Prestige includes concepts as status and success [12], visibility and reputation [33], appreciation [32], self-marketing [20], and recognition [18]. Power is the ability to influence the group, and it is associated to building trust and obtaining respect from others [12].

62

J. de Melo Bezerra and C.M. Hirata Table 1. Individual factors related to human needs and social fears Category Belonging needs

Esteem needs

Self-actualization needs

Social fears

Factors Identification Awareness of others' presence Socialization Awareness of others' opinion Prestige Reputation Trust Status Appreciation Respect Success Self-marketing Recognition Visibility Power Competence Career plans Learning Personal realization To seek new challenges To take risks To evaluate the own progress Fear of being identified Fear of expressing opinion Fear of disrupting own image Fear of being criticized Fear of disapproval or punishment Fear of being judgment Fear of misleading others

The last level in the Maslow hierarchy is the self-actualization need, which is the necessity to maximize your own potential. The self-actualization needs are related to competence and personal realization factors. Competence refers to the desire to learn more, to seek new challenges, and to take risks [12]. Factors associated to learning include receiving answers to questions, and getting access to useful information, expertise and best practices [24]. Concerns about the career are another factor associated to self-actualization need, especially in open source communities [19]. People motivated by personal realization, are in general not interested on awards, but they are interested on receiving a feedback about your activities. For these people, it is important to evaluate the own progress and compare to the others [12]. In a virtual community, distinct needs coexist as individual factors that motivate members. For example, Ling and Mian [20] investigate the motives to use an online crowdsourcing, a platform where customers contribute to continuous innovation of products. The studied factors are learning, direct compensation, self-marketing, and social motives. Learning is the intention to expand skills, and represents the selfactualization needs. Direct compensations are related to be awarded with monetary or nonmonetary prizes, which in general are related to the esteem needs, because the prizes can indicate status and reputation. Monetary compensation can also represent the safety needs. Self-marketing is the use of your achievements to demonstrate competency, which is aligned to the esteem needs. Social motives include the expected reactions of others, which characterize the social needs. In general members in virtual communities are volunteers. Clary et al. [6] identified six categories that influence volunteers’ motivation: values (the desire to help others), social (the chance to be with others), protective (to share knowledge with

Motivation and Its Mechanisms in Virtual Communities

63

others), enhancement (to publicly exhibit knowledge), understanding (the opportunity to learn new things), and career (to develop yourself to a new or present career). These categories were used by Nov [25] to evaluate what motivates members in Wikipedia community. We argue that these categories are already addressed by the factors listed in Table 1 as follows. Values, social, and protective categories are addressed by factors about belonging needs. Enhancement category is related to factors about esteem needs. Understanding and career categories are factors about self-actualization needs. Besides the human needs, factors that contribute to motivation can include social fears. Social fears are understood as social inhibitions that can impact negatively one’s performance in a group, and that are in general related to the approval or disapproval of others [7]. The social fears, drawn from the related work, are illustrated in Table 1. Some members do not feel comfortable to show the real identity in virtual communities, in this case anonymity might be useful [16]. The fear of being identified can be related to the fear of exposing the private life, to the fear or difficulty of expressing opinions [37], and also to the fear of contributing in activities. Other barrier to motivation is the lack of confidence to contribute, because members can hesitate to share if they have fear of misleading other members with their answers [24]. Members can reduce their contributions in virtual communities due to the fear of being criticized [24]. Other problems are the apprehensions of disapproval, punishment and judgment by others [7]. 3.2 Identification of Environmental Factors To identify environmental factors that influence motivation in a virtual community, we analyze the contributions and difficulties that the community norms and the system that support the community impose to the development of members’ activities. The identified factors are listed in Table 2. Table 2. Environmental factors Category Norms

System

Sufficiency Availability Easy to be understood Usability Security Awareness of opportunities

Factors Adaptability Enforcement Lack of contribution Late contribution

Norms must have the sufficiency characteristic, in order to address all the relevant matters in community and consequently be able to correctly discipline members and organize their activities. Norms shall also be available for members, because the difficulty or impossibility to access them can derail the activities’ execution. Yamamoto et al. [37] argue that in online public decision making, one restriction is members to understand the problem to be discussed and to express their own

64

J. de Melo Bezerra and C.M. Hirata

opinions. Similar problem can be faced by members regarding the interpretation of norms and related procedures, so norms shall be easy to be understood. Virtual communities are not fixed over time; they evolve due to the members’ interests and demands, then the adaptability of norms in a community is other factor to be considered [3]. Airong and Xiang [1], in the e-government context, state that irrational participation, characterized by anarchy and vandalism, is a problem that does not motivate regular members. So, dealing with norm infractions is a critical factor. It can be made by using approaches of norms’ enforcement, in order to both guarantee that norms are being followed, and keep the community credibility [2]. Restrictions to the members’ motivation can also be caused by the system that supports the virtual community. Researchers [10,23,14] state that the productivity of a virtual community depends heavily on the fact that its members accept the community system. The acceptance is mainly related to the satisfaction of usability requirements. Other system factor is security [24]. Security is related to the avoidance of unauthorized participation. Airong and Xiang [1] state that security is critical to the members’ acceptance of e-government systems. Other factors imposed by system are concerned to communication restrictions. For instance, in forums, sometimes there is a lack of awareness of the opportunities to participate, because members do not know that a new topic is under discussion [1,18] or that there are activities to be performed. The communication restrictions affect the elapsed time between a participation request and the participation itself. Three undesirable situations are perceived regarding this issue in online discussions. The first situation is the lack of response, when nobody responds the question of a member. The second situation is the delay of the first responses, when the first contributions take too long to occur, which in general is incompatible to the desire of the member that initiated the discussion. The third situation is when a member makes a comment about a discussion that is already finished, so the contribution is useless.

4 Motivation Mechanisms In this section we discuss mechanisms to handle the factors, identified in the previous section, that influence motivation in virtual communities. The mechanisms were drawn from the literature and an investigation of Wikipedia motivation mechanisms. The investigation of Wikipedia mechanisms was performed by using the information available in this community, and also by performing qualitative interviews with four Wikipedia members, identified as I1, I2, I3, and I4. The interviews were conducted via email in March, 2011. Regarding membership duration, the interviewees had respectively six months, three years, five years, and four years. Table 3 shows the mechanisms identified by analyzing the factors of Table 1 and Table 2. The next sections present discussions of these mechanisms.

Motivation and Its Mechanisms in Virtual Communities

65

Table 3. Motivation mechanisms Category

Belonging needs

Esteem needs

Self-actualization needs

Social fears

Norms

System

Mechanisms Community goals, values and achievements Welcome message by other member Personalized assistance means User pages Discussion boards Award for the quantity of contributions Award for the contribution quality Award that includes other awards Recognition by the colleagues Creation freedom Activities about assets’ quality Activities about users’ management Activities about community promotion Opportunities’ availability To measure and compare own progress Facilitation Request for contribution Possibility of anonymity Educative assistance Accessible norms Enforcement process Members’ participation in norms’ definition Users’ suggestions about usability Security management Information delivery and announcement agent Awards considering quality and response time Discussion enclose

4.1 Mechanisms for Individual Factors Related to Belonging Needs We investigated mechanisms that address the factors related to belonging. For example, the identification factor can be achieved if the member shares the same goals as the community. One mechanism to handle the identification factor is to define and promote the community goals and values, for example in Wikipedia this information is provided in pages as Five pillars, What Wikipedia is not, and Community of Wikipedia. The interviewee I1 stated his identification with Wikipedia goal, when he reported the pleasure of knowing that people read something he contributed. Other mechanism that can contribute to the identification factor is to inform the community history, explaining its achievements, evolution, and reliability; for example in Wikipedia some pages address these issues, such as History of Wikipedia, and Reliability of Wikipedia. One mechanism to handle the socialization factor is to provide a welcome message when the member starts in community. The message is more effective if sent by other member and not by an automatic tool. The welcome message in Wikipedia has instructions pages to learn about article edition, such as: How to edit a page, Editing tutorial, and Manual of Style. The message also informs some means to get assistance, such as: Help page, Village Pump page, and to make questions directly to

66

J. de Melo Bezerra and C.M. Hirata

the member who posted the message. According to Choi et al. [5], socialization can be improved using personalized mechanisms, for instance by reviewing newcomers’ recent work and offering specific assistance to help their engagement in community. Each page in Wikipedia has an associated talk page where discussion about the page is held. In the talk page, it is possible to be aware of others’ presence and opinion, because any member can start a discuss topic or to comment an existent one. If a member desires to know more about other member, he/she can access the other user page. The talk page related to an article is a kind of discussion board, where members can debate aspects of the article and determine which content is appropriate. Other examples of discussion boards in Wikipedia are Community Portal and Collaborations Page, which encourage members to work together [17]. 4.2 Mechanisms for Individual Factors Related to Esteem Needs Mechanisms that address esteem are in general related to prizes or awards. Due to the correlation of some motivating factors, it is difficult to know exactly which ones are addressed by receiving awards. Examples of correlated factors are appreciation, recognition, status, visibility, prestige, and respect. To receive an award is a way to be appreciated and recognized, for instance, the interviewees I2, I3 and I4 reported the satisfaction of having their contribution appreciated in Wikipedia. To have awards is a means to acquire status, visibility and prestige, for instance, the interviewee I2 explained that through his awards other members are informed about his achievements. The quantity of received awards is also a way to conquer respect. Awards are associated to the achievement of some marks, considering the number of contributions or the quality of them. In Wikipedia, the Service Awards take into account the number of edits during the membership period. There are twenty service awards in Wikipedia, for instance: Novice Editor, Veteran Editor, Senior Editor, and Vanguard Editor. In Wikipedia there is also a members’ rank, called List of Wikipedians by number of edits, which only evaluates the number of edits. Number-based awards can be misleading, as reported by the interviewee I1. For instance, in Wikipedia, the problem is that not all edits are representative of good contributions, for example a member working with anti-vandalism can performed many edits, but the edits are not of the same caliber as article work, so the member should not be considered to the award. One way to overcome this problem is to not count all the contributions of a member, but to allow that members evaluate the contributions of each other. This practice is being used in online forums, for instance in StackOverflow [30] there is a way to vote if questions and answers are useful. In Wikipedia, sometimes members show appreciation and respect to others by providing in their user pages a section with names of members who have collaborated with or whom received some help, as reported by the interviewees I2 and I3. The other kind of awards is concerned to the quality of the contributions. Some examples in Wikipedia are: Featured Article (FA), Good Article (GA), and Did You Know (DYK). FAs are considered to be the best articles in Wikipedia. GAs are considered to be of good quality articles that are not yet featured article quality. DYK is a section on the main page that gives publicity to newly created or expanded Wikipedia articles. If a member develops an FA, both he/she and the article receive the FA award, which is represented by a star symbol. Each award has its own symbol,

Motivation and Its Mechanisms in Virtual Communities

67

also called icon in Wikipedia. There are also awards that include a set of distinct awards, for instance in Wikipedia there is the FOUR award, which requires you to start an article from scratch, get it displayed on DYK, make it a GA, and then a FA. The existence of such mechanisms actually improves motivation, and consequently participation. For instance, the interviewees I2 and I3 commented that, if there were no awards, they would still participate but less focused, and maybe they could have contributed less they did. The interviewee I4 complements that there have been times that he was not motivated, but the receiving of an award kept him motivated. 4.3 Mechanisms for Individual Factors Related to Self-actualization Needs A mechanism to address self-actualization is to allow creation freedom during the execution of the community activities. In Wikipedia this freedom is perceived when a member chooses a desired article to contribute or to create. The creation freedom mechanism addresses the learning and challenge factors, for example the interviewee I1 reported that to write about a topic that you are not intimately familiar with can be a great challenge, as long as you make efforts to cover it well and in detail. Other motivation mechanism is to provide members the possibility to participate of other initiatives in the community beyond the ordinary ones. These initiatives include strategic activities related to community organization, including the guarantee of the quality of the assets developed, and the management of users. In Wikipedia this kind of activities is performed by members who assume distinct social roles, for instance the quality of the articles is addressed by reviewers and rollbackers, and the users’ management is handled by checkusers and account creators. Other initiatives comprise of helping the community promotion. In Wikipedia there are the Wikiprojects, which are projects to manage specific topics or family of topics within Wikipedia. There is also a special role, called Wikipedia Ambassador, whose objective is to both help new users and find new potential contributors, particularly teachers who want to bring Wikipedia into the classroom. The possibility to participate of strategic positions stimulates members, because they can learn new activities, acquire experience and assume risks, for instance the interviewee I2 commented that he assumed other roles as rollbacker and Wikipedia Ambassador to pick up experience in many areas. The members in Wikipedia have the possibility not only to participate of distinct initiatives, but also to manage them, for example the interviewee I3 is responsible for the process to grant two awards, namely FOUR and WAWARDS. Other motivation mechanism is to guarantee that the opportunities are available for all members, according to their experiences and competence. It is also found in Wikipedia due to the possibility of a newcomer to conquer additional roles, as occurred with the interviewee I1, a newcomer who already is rollbacker and reviewer. The career factor can be indirectly addressed by the previous mechanisms, for example if member’s job in real life has a close relation with the community goals, as commented by the interviewee I2 who is a social media consultant and occasionally write Wikipedia articles for clients. A mechanism to address the factor about the evaluation of own progress can be implemented by the availability of information about other users, including the received awards and performed positions. In Wikipedia it can be accessed through the

68

J. de Melo Bezerra and C.M. Hirata

user pages. The rank in List of Wikipedians by number of edits is another way to compare own progress with others. 4.4 Mechanisms for Individual Factors Related to Social Fears Jacob and Sam [15] use facilitation techniques to promote student participation in online forums. The techniques include the use of Socratic questioning prompts, for example, questions about clarification, assumptions, reasons and evidences during an online problem solving session. The facilitation is a mechanism that can help to address the fear of expressing opinions and the fear of misleading others, because it helps to structure one’s position. Other mechanism that can help is to request the contribution of the member, because, if the member is invited, he can feel more comfortable to participate. According to the interviewee I2, the invitation to members in Wikipedia occurs mostly for science articles due to the lack of experts to contribute. A mechanism to handle the fear of being identified is the possibility of anonymity. For instance, the interviewee I3 commented that there is always a fear of loss of privacy online. In Wikipedia, members use usernames, so they can expose their identities or other personal information only if they desire. Unregistered members can also contribute to Wikipedia; in this case their work is logged with IP address. Usernames are common in online forums. The anonymity is used as a way to alleviate the pressure of exposing one’s thoughts. The fear of being criticized can be addressed by the establishment of norms in community to avoid this kind of offensive practice. Regarding the fear of disapproval or punishment, the interviewee I1 commented that he was worried, during the article edition, about being reamed out by users who think that every single phrase needs a citation. To address it, the community can implement educative assistance to help members unfamiliar with the community norms. For example, in Wikipedia there is an automatic tool called Sinebot that gives an advice when the member does not sign a post. 4.5 Mechanisms for Environmental Factors Regarding the environmental factors driven from community norms, the availability factor can be managed by conferring access of members to all norms. In Wikipedia, norms are available as general articles. The enforcement factor can be addressed through an enforcement process that has the following activities [2]: events’ monitoring, incidents’ analyses, sanction application, damage recovery, and unexpected event handling. Examples of actions to enforce norms include the blockage of members for a period of time and the suspension of his/her user account. A mechanism to deal with the adaptability of norms is to allow members to participate in the definition norms. In Wikipedia, members are responsible for promoting the evolution of norms, according to their interests and demands, characterizing Wikipedia as a self-organized community [3]. The environmental factors related to the system of a virtual community can be critical, for instance some interviewees presented concerns about the system factors suggesting that they are the main reasons that decrease members’ motivation.

Motivation and Its Mechanisms in Virtual Communities

69

A mechanism to deal with the usability factor is to provide a forum to collect the suggestions of members about issues to be enhanced in the system. In order to assure the accountability of the members’ activities, the security management is critical. To overcome the factor about the lack of awareness of opportunities to participate, Lan and Yan [18] propose the use of an information delivery agent and information announcement agent in an online student discussion forum. The objective is, respectively, to inform learners about new discussions in community, and to show which discussions were not already read by a specific learner. In Wikipedia there is a similar mechanism, known as watch, which allows registering a page to be informed when it changes. According to the interviewees I2 and I3, the inability to get help could keep people from contributing in Wikipedia. We believe that a mechanism to address the factors regarding the lack of contribution and the late contribution can be the specification of a desirable deadline for contributions. For example, a member initiates a discussion and defines the response deadline, so other member that contributes to the discussion, respecting the deadline, can be recognized. Other mechanism can be is the definition of a deadline to close the discussion, so no further comment could be provided about an issue already debated.

5 Discussion We believe that the identification of factors is useful to design motivation mechanisms in virtual communities. It also helps to analyze the motivation mechanisms already implemented in community. It is not our objective to provide an exhaustive list of factors and mechanisms, but to discuss some factors and existent mechanisms. The identified factors that influence motivation are quite general and can be used as suggestions for distinct virtual communities. Given a community, it may be necessary to prioritize the factors and to propose mechanisms to address the critical factors firstly. Each community has to forge its own prioritization of factors, because the factors can vary according to the community goals and maturity, as well as the members’ perceptions. After defining motivation mechanisms, a coverage analysis can be made, in order to guarantee that the proposed mechanisms address all the critical factors. It is important to observe that sometimes a single mechanism can handle more than one motivating factor. We believe that self-organizing communities have an advantage to design motivation mechanisms. The advantage is due to the possibility of members to define norms and influence the changes in the system, so members can act on the environmental factors that affect motivation. Besides, members can work together on the definition and establishment of motivation mechanisms to address individual factors. For example, in Wikipedia, the discussed mechanisms were proposed by the own members and are also managed by them. Two suggestions about motivation mechanisms can be proposed. The first is to divulgate mechanisms in community, so that the users can consider mechanisms in their objectives. The second suggestion is to be able to evaluate their efficacy on stimulating motivation, and consequently participation. The efficacy of a motivation mechanism can be decreased during its life cycle, raising a concern about the

70

J. de Melo Bezerra and C.M. Hirata

deactivation of the mechanism. Sometimes mechanisms lose their ability to motivate due to a variety of reasons, for instance, members’ perception can change. However, the absence of them may be felt by the members. These mechanisms can be characterized as the maintenance factors, discussed by Herzberg et al. [13]. Therefore, if a mechanism cannot be provided for a long term, it is recommended both to specify a duration for the mechanism, and to inform the duration to the members. Besides, before deactivating a mechanism, it is necessary to analyze if it will not result into undesirable consequences to motivation. Even motivated by the presence of motivation mechanisms in the virtual community, a member can face barriers to participate. Some barriers can be associated to the lack of ability to perform an activity, the personal concept of enjoyment [14, 25], and the personal preferences [4,14]. Other barriers are related to lack of specific resources, for instance, the lack of time [4]. These barriers were not specifically analyzed in this article, because we are mainly concerned with factors that can be addressed by motivation mechanisms.

6 Conclusion The participation of members in virtual communities can be encouraged indirectly by improving members’ motivation. We identified factors that improve motivation, using Hersey and Blanchard’s motivation model, Maslow’s hierarchy of needs, and virtual community model, and classify them into individual and environmental factors. To identify individual factors, we used the human needs and social fears. To identify environmental factors, we reasoned about norms and system in virtual communities. Afterwards, we discussed the motivation mechanisms. To help in the discussion, we used examples and a qualitative survey obtained from Wikipedia. The research performed in this article leads to some suggestion of future work. One future work is to investigate the effectiveness of Wikipedia motivation mechanisms to determine if they actually reach their goals. An interesting work is to experiment a mechanism proposed in this article to compensate a member considering both the quality of contribution and the delay to provide it. Other work is to understand how the intensity of human needs and social fears varies for members according to their membership trajectories in a virtual community. We consider that the interactions between members of virtual communities are mainly performed in the virtual world, however, there can be face-to-face or phone call interactions, for example, one member can comment with other about something interesting or ineffective mechanisms in a community. The research question to pursue is how the interactions outside the virtual community influence the members in the virtual community.

Acknowledgments. To the Wikipedia members that participated in the interviews. To Tony Ahn for the availability to contribute with explanations about Wikipedia.

Motivation and Its Mechanisms in Virtual Communities

71

References 1. Airong, A., Xiang, G.: Study on motivation of citizens participation under the conditions of e-government. In: International Conference on Management of e-Commerce and eGovernment. IEEE Press, Los Alamitos (2008) 2. Bezerra, J.M., Hirata, C.M.: Enforcement of Norms in Self-Organizing Virtual Communities. In: International Conference WWW/INTERNET. IADIS Press (2010) 3. Bezerra, J.M., Hirata, C.M.: Self-organization of Virtual Communities: Need and Members’ Participation. In: 7th International Conference on Web Information Systems and Technologies, WEBIST. INSTICC Press (2011) 4. Chan, M.L.C.: Recognition and Participation in a Virtual Community. In: 37th Hawaii International Conference on System Sciences. IEEE Press, Los Alamitos (2004) 5. Choi, B., Alexander, K., Kraut, R.E., Levine, J.M.: Socialization Tactics in Wikipedia and Their Effects. In: Conference on Computer Supported Cooperative Work, CSCW. ACM Press, New York (2010) 6. Clary, E., et al.: Understanding and assessing the motivations of volunteers: A functional approach. Personality and Social Psychology 74, 1516–1530 (1998) 7. Cottrell, N.B.: Social Facilitation. In: McClintock, C. (ed.) Experimental Social Psychology, pp. 185–236. Rinehart & Winston, New York (1972) 8. Cramton, C.D.: The mutual knowledge problem and its consequences for dispersed collaboration. Organization Science 12(3), 346–371 (2001) 9. Cullen, R., Morse, S.: Who’s Contributing: Do Personality Traits Influence the Level and Type of Participation in Online Communities. In: 44th Hawaii International Conference on System Sciences. IEEE Press, Los Alamitos (2011) 10. Geib, M., Braun, C., Kolbe, L., Brenner, W.: Measuring the Utilization of Collaboration Technology for Knowledge Development and Exchange in Virtual Communities. In: 37th Hawaii International Conference on System Sciences. IEEE Press, Los Alamitos (2004) 11. Han, J.J., Zheng, R.J., Xu, Y.: The Effect of Individual Needs, Trust and Identification in Explaining Participation Intentions in Virtual Communities. In: 40th Hawaii International Conference on System Sciences. IEEE Press, Los Alamitos (2007) 12. Hersey, P., Blanchard, K.H.: Management of Organizational Behavior – Utilizing Human Resources. Center of Leadership Studies, Escondido (1982) 13. Herzberg, F., et al.: The Motivation to Work. John Wiley & Sons, Inc., New York (1959) 14. Hsu, C.-L., Lu, H.-P.: Consumer behavior in online game communities: A motivational factor perspective. Computer in Human Behavior 23, 1642–1659 (2007) 15. Jacob, S.M., Sam, H.S.: Analysis of Interaction Patterns and Scaffolding Practices in Online Discussion Forums. In: 4th International Conference on Distance Learning and Education, ICDLE, IEEE Press, Los Alamitos (2010) 16. Kurdziolek, M.D., Schaefer, M., Tatar, D., Renga, I.P.: Lessons from ThoughtSwaping: Increasing Participants’ Coordinative Agency in Facilitated Discussion. In: Conference on Computer Supported Cooperative Work, CSCW. ACM Press, New York (2010) 17. Kuznetsov, S.: Motivations of Contributors to Wikipedia. ACM SIGCAS Computers and Society 36(2) (2006) 18. Lan, Y.-F., Yan, C.-L.: A Practical Approach to Encourage Students Participation in Asynchronous Online Discussions Based on Expectancy Theory. In: International Conference on Virtual Environments, Human-Computer Interfaces and Measurements Systems, VECIMS. IEEE Press, Los Alamitos (2009)

72

J. de Melo Bezerra and C.M. Hirata

19. Lattemann, C., Stieglitz, S.: Framework for Governance in Open Source Communities. In: 38th Hawaii International Conference on System Sciences. IEEE Press, Los Alamitos (2005) 20. Ling, P., Mian, Z.: An Empirical Study of Social Capital in Participation in Online Crowdsourcing. In: International Conference on E-Product, E-Service and E-Entertainment, ICEEE. IEEE Press, Los Alamitos (2010) 21. Liu, Y., et al.: An Integrated Model of Group Diversity, Conflict and Outcomes: A Process-based Perspective. In: International Conference of Wireless Communications, Networking and Mobile Computing. IEEE Press, Los Alamitos (2008) 22. Maslow, A.H.: Motivation and Personality (1954) 23. Michaelides, R., Morton, S.C.: Managing Innovation through Virtual Global Communities: Challenges and Benefits. In: 4th IEEE International Conference on Management of Innovation & Technology. IEEE Press, Los Alamitos (2008) 24. Mousavidin, E., Goel, L.: A Life Cycle Model of Virtual Communities. In: 42th Hawaii International Conference on System Sciences. IEEE Press, Los Alamitos (2009) 25. Nov, O.: What Motivates Wikipedians? Communications of the ACM 50(11) (2007) 26. Palaia, N.: Noções Essenciais de Direito (In English: Essential Notions of Law). Saraiva Publisher (2005) 27. Pelled, L.H.: Demographic diversity, conflict, and work group outcomes: an intervening process theory. Organization Science 16, 615–631 (1996) 28. Preece, J.: Online Communities: Designing Usability, Supporting Sociability. Wiley, Chichester (2000) 29. Preece, J.: Sociability and Usability in Online Communities: Determining and Measuring Success. Behavior and Information Technology 20(5), 347–356 (2001) 30. StackOverflow, http://stackoverflow.com/ 31. Tedjamulia, S.J.J., et al.: Motivating Content Contributions to Online Communities: Toward a More Comprehensive Theory. In: 38th Hawaii International Conference on System Sciences. IEEE Press, Los Alamitos (2005) 32. Viégas, F.B., Wattenberg, M., Dave, K.: Studying cooperation and conflict between authors with history flow visualizations. In: Conference on Human Factors in Computing Systems, CHI. ACM Press, New York (2004) 33. Wang, F.-R., He, D., Chen, J.: Motivations of Individuals and Firms Participating in Open Source Community. In: 4th Conference on Machine Learning and Cybernetics. IEEE Press, Los Alamitos (2005) 34. Wenger, E.: Communities of practice: Learning, meaning, and identify. Cambridge University Press, Cambridge (1998) 35. Werther, W.B., Davis, K.: Personnel Management and Human Resources. McGraw-Hill, Inc., New York (1981) 36. Wikipedia, http://en.wikipedia.org 37. Yamamoto, S., Ito, K., Ohnishi, S., Nishida, S.: A Method for Expressing Responsible Opinions Toward Public Decisions Making. In: 8th IEEE International Conference on Industrial Informatics, INDIN. IEEE Press, Los Alamitos (2010) 38. Yao, Y.: Comparing Two Discussion Designs in Terms of Student Online Interactions. In: 2nd International Conference on Education Technology and Computer, ICETC. IEEE Press, Los Alamitos (2010) 39. Zhang, X., Zhu, F.: Intrinsic Motivation of Open Content Contributors: the Case of Wikipedia. HKUST and MIT Center for Digital Business. Harvard Business School, Boston (2006)

Collaborative Refactoring: Results of an Empirical Study Using Grounded Theory Pedro J.F. Treccani1 and Cleidson R.B. de Souza2 1

Federal University of Pará (UFPA), Belém, PA, Brazil 2 IBM Research Brazil, São Paulo, SP, Brazil [email protected], [email protected]

Abstract. Due to the current market dynamics, changes in requirements are often faced by the software industry, impacting directly on the software system to be produced. To deal with this situation, software development organizations need to use techniques that enable fast responses. Agile methods have been considered adequate to handle these situations. Our research focuses on understanding how Brazilian organizations are adopting agile methods. In this paper we present the results of an empirical study of refactoring activities, which in the organizations we studied are conducted in a collaborative way. We call this collaborative refactoring. Our results suggest that collaborative refactoring promotes knowledge sharing among the development team especially about the software architecture of the system. On the other hand, we also observed that there is a lack of tools to support collaborative refactoring. Keywords: Agile methods, Refactoring, Collaboration, Grounded Theory, Brazilian organizations.

1 Introduction Current software development organizations face different challenges. Several of these challenges are related to requirements volatility [1-3]. For instance, new functionalities are constantly required, as well as changes in the requirements and even with the exclusion of some of them, impacting the entire development process. Given this context, development organizations need to quickly adapt to changes. Agile methods are regarded as a efficient way to help these organizations achieve the necessary dynamism to handle the volatility of the requirements. This can be seen in the software producer market, where agile methods are gaining more and more space [4]. Agile methods suggest more intense communication between customers and supplier organizations so that changes in the requirements can more easily be made during the development period. One of the premises of the agile movement is that suppliers need to be prepared to make changes in the system according to the customers’ needs, because these changes are a natural part of the software A.S. Vivacqua, C. Gutwin, and M.R.S. Borges (Eds.): CRIWG 2011, LNCS 6969, pp. 73–80, 2011. © Springer-Verlag Berlin Heidelberg 2011

74

P.J.F. Treccani and C.R.B. de Souza

development process [5]. However, these changes often impact the source code being produced, and developers might end up changing this code in a disorganized way. This makes the task of changing requirements more complex and error-prone. Refactoring, one of the fundamental premises of the agile movement [6], is an approach used to restructure the existing code, improve the design and increase the quality of the product without inserting errors [7]. Besides the practice of refactoring, agile methods suggest methods, practices and techniques that can increase the customer satisfaction [8], in addition to enabling software development in a shorter timeframe [9]. They can also enable improvements in the development process, quick responses to requirements changes and incentives to collaboration and communication among stakeholders [3,10,11]. One of the aspects of agile methods is the frequent collaboration among team members (see for instance the ideas of shared planning and pair programming). This aspect is often regarded as one of the most important aspects from the agile methods approaches and it also suggests a great research potential for research on ComputerSupported Collaborative Work that has not been effectively explored, especially in Brazilian organizations. Among the exceptions, we can cite the work of [12-14] and [15] in the global scenario and [16] and [17] in the Brazilian scenario. Based on this motivation, this paper discusses the results of an empirical study that we conducted in Brazilian organizations that have adopted agile methods. We focus on collaborative refactoring, i.e. refactoring activities that are performed in a collaborative way in these organizations. We observed this practice during a qualitative study that used semi-structured interviews [18] as data collection method and grounded theory [19] for data analysis. We discuss how collaborative refactoring helps knowledge sharing among the team members, including knowledge about the software architecture of the system, best practices and technical knowledge. We also highlight how current refactoring tools do not support collaborative refactoring.

2 Methodology 2.1 Context of the Empirical Study This empirical study was performed by conducting 26 semi-structured [18] interviews in five software development companies located in three states of Brazil, namely: Pará, Pernambuco and São Paulo. Each one of these states is located in a different part of the country. Interviewees performed different roles including: developers, test analysts, requirements analysts, team leaders, architects, scrum masters1 and product owners1. They also had different years of experience in the company and were selected based on this experience. For confidentiality reasons, companies’ names will be preserved and in the rest of the paper, they will only be called as Company A, Company B, Company C, Company D and Company E. Interviewees will be called as Interviewee 1, Interviewee 2, and so on. Companies A, B, C and D mainly use SCRUM as the basis of their development process, but they also incorporate practices from other methodologies such as XP [1] (Extreme Programming), FDD[20] (Feature Driven Development), and adopt the 1

Typical roles of SCRUM methodology.

Collaborative Refactoring: Results of an Empirical Study Using Grounded Theory

75

Burndown Chart and the Gantt Chart. Company E uses some practices of XP, SCRUM, KANBAN [25] and LEAN [26], without predominantly adopting any of these methodologies. Company A focuses on the development of on demand of small and medium software systems, being active in many segments (healthcare, education and others). It has around 20 developers and develops software for web and desktop platforms using Java and .Net as programming languages. Company B focuses on software for healthcare. It has a legacy system developed using Delphi, which is being maintained. This company also develops new modules to this system. Company B has 8 collaborators working in new modules and 12 collaborators working in the support and maintenance of its legacy system. Company C developed a software product for service queue management and ticketing. This system was built using Delphi programming language and is also in maintenance phase. This company has 6 collaborators that maintain this system. There is a plan to migrate this system to Java, however it still in early stages. In addition to this team, Company C has 30 collaborators to this system maintenance area, what includes different profiles, such as system analysts, deployment analysts, DBAs, technical support analysts and others. Company D is a state public agency and has many software systems, both in maintenance and under development. A large-size system of internal management processes was chosen for this research. This system is developed by 26 collaborators using Java. Finally, Company E is a company in the websites hosting business that also develops software systems. Its main focus is on web business management systems and infrastructure and development in cloud computing. This company has more than 10 years, uses 5 different agile methods, has around 600 employees and about (100 to 150 of them are employees in the Information Technology area) and develops web and cloud computing applications using Java and Ruby on Rails. The studied team has 13 employees among software engineers and database and network administrators. The system developed by this team aims to be multiplatform integrating with systems in Windows and Linux platforms. 2.2 Data Collection Semi-structured interviews [18] with open questions were used as the data collection method in this study. In this type of interviews, a basic guide is proposed to guarantee that the researcher addresses the points of interest. In addition, semi-structured interviews enable the interviewee to expose his/her thoughts, experiences, and viewpoints about a specific subject. During the interviews, the researcher can ask additional questions about a subject or theme raised by the interviewee to better understand the phenomena of interest [23]. The interview guide of this study was composed by 59 open questions focusing on different aspects of the adoption of agile methods. However, in some cases it was necessary to ask more questions in order to obtain further clarification of some issues. Interviews were conducted in Portuguese. The quotes from the interviews presented later in the paper were freely translated to English by the authors.

76

P.J.F. Treccani and C.R.B. de Souza

Based on this interview guide, 26 interviews were performed distributed as follows among the mentioned companies: 9 interviews were conducted in Company A, 7 in Company B, 6 in Company C, 2 in Company D, and, finally, 2 interviews in Company E. All interviews were recorded and then later transcribed so that they could be analyzed later. To help us during the data collection process, we wrote six small reports after the interviews and wrote down annotations during the whole data collection process. 2.3 Data Analysis After the data collection, we used Grounded Theory (GT) [24] methods to analyze the interviews and guide this empirical study. Codifications were used to give meanings to the data collected. It was performed by giving names, or codes2, to the phenomenon we observed, as a way of abstracting an event, action or interpretation of a meaning. In this stage the data was divided, conceptualized, and their relationships were established [25]. There are two main ways to code qualitative data [26]: (i) the substantive coding is performed through open and selective coding; and (ii) the theoretical coding, that is performed through axial codification. The open coding stage was conducted through the definition of categories (codes) and subcategories of interest. The identification of the occurrence of these categories and subcategories is done by examining, line by line, the collected data and annotations (memos) created during the analysis [25]. Axial coding aims to group the categories and subcategories created in the previous stage into more meaningful concepts and to analyze the implications of this grouping. In the selective coding, we refine the codes already identified. In this stage, a main research aspect or question is defined and is associated with the existing codes. This main research question, and its associated codes, summarize and relate every code with the phenomenon, pointing out its implications, cause and effect and its characteristics. In this paper, the main aspect of this study is the concept of collaborative refactoring, because it is the more relevant aspect that we identified. Then, refactoring can be used to group and connect every other category previously identified. The application of Grounded Theory allowed one to assign meaning to a huge volume of unstructured data (the transcribed interviews). This study is still in a refinement stage and the research is in progress. In order to help the application of Grounded Theory, the MAXqda2 tool [27] was used. This tool enables the creation and grouping of categories and subcategories on the collected data, as well as the relationships among the categories.

3 Results At the end of our data analysis, we had a better understanding about how agile methods have been implemented in the studied companies. Furthermore, we also had 2

A code is an abstract representation of a specific factor or characteristic. Usually it consists of one word, or a set of words, that identify, highlight or categorize a specific phenomena observed in the data. A code may represent a subcategory of the study, while a set of codes, or the abstraction of a set of codes, represents a category [25].

Collaborative Refactoring: Results of an Empirical Study Using Grounded Theory

77

some understanding about the adoption of more collaborative approaches during the execution of some of the development activities. In particular, in this paper we report the results related to how refactoring activities are performed in a collaborative fashion, i.e., collaborative refactoring. Note that, traditionally, refactoring is an activity performed by an expert member of the team: while the planning might be performed collaboratively, the execution of the refactoring per se is done by a single individual. As mentioned before, the companies where we collected data are located in different parts of the country. Despite the geographical distance between the companies, we observed that collaborative refactoring occurs in all of them. In the following sections, we present our findings related to the collaborative refactoring activity. Following the qualitative research tradition [25], we will also present quotes from the interviews as supporting evidence of our conclusions. Finally, we will present a discussion about our findings. 3.1 Collaborative Refactoring Agile methods have as one of their main principles the communication among team members and the idea of collective code. By collective code, we mean that there is no ownership of the code, i.e., any developer can make changes in any part of the code. Therefore, we observed that the studied companies usually perform more activities in a collaborative way, especially complex development activities. Thereby, structural refactoring activities3 are performed in teams, according Interviewee 3 from Company A: “Usually a refactoring that modifies the architecture is performed in group, first to inform everybody about the modification, and then so that everybody can contribute to the task that is being performed.”

Because of the “feeling” that the code belongs to the group, and not of the developer who created it, the interviewees argued that architectural changes should be conducted by the teams. Furthermore, it is safer to conduct the refactorings collaboratively because each developer knows how certain parts of the code were developed and they can better explain how they operate. The following quote, from an interview with the Interviewee 6 of Company B, exemplifies how the collaborative refactoring is performed. This occurs in a similar way in every company in which we collected data. “All developers are called […]. The meeting starts with an expert developer explaining the reason for the modification and where it will occur, another developer shows the affected code. […] After that, it is given a suggestion of improvement, which was discussed earlier between the two developers […]. The developers evaluate the solution and share their ideas about how to solve the problem, often changing the initial solution that was proposed […]. After deciding how the problem will be solved, the responsible developer makes the changes in the code and the other developers just observe it, suggesting improvements when necessary.” 3

Refactoring activities are considered complex or structural when require significant changes in the system architecture, in addition to the application of new technologies or changes in versions of the programming languages used.

78

P.J.F. Treccani and C.R.B. de Souza

We observed that collaborative refactoring brings at least one important benefit to the software development teams: it helps to spread the knowledge about the software architecture of the system among the development team, as well techniques and practices used in software development. According to the interviewees, collaborative refactoring helps to avoid that new bugs are inserted, because all involved know the behavior of the source code. Basically, since each developer has a very good understanding of the modules/features that (s)he developed, (s)he is able to explain specific aspects of these modules/features to other developers. Examples of aspects include the software architecture, features and the way a change should be done in software codebase. The following quote from Interviewee 1 (Company E) exemplifies this advantage: “In almost every meeting [group refactoring] we learn something new, not only about how the architecture will be changed, but also about how to write better and cleaner code, or a new design pattern […]. The most important in the meeting is the knowledge of how the system works, especially of the part that you did not develop. It avoids rework and bugs once we know how it works and to whom we should ask for help to that specific part.” It should be noted that knowledge management is a major issue in software development organizations [28]. This is potentially problematic in organizations that adopt agile methods, because these methods place less emphasis on the documentation [6]. Therefore, the adoption of collaborative refactoring is an important mechanism to alleviate this problem in agile development teams. Although our interviewees recognized the benefits of collaborative refactoring they also indicated some problems with this practice. For example, Company E removed this practice of its process, because the changes in the implementation that were performed during the meetings were too time consuming. Therefore, at the time of the interviews, the meeting for refactoring dealt only with the analysis of the architecture to be refactored. At the end of the meeting, a new architecture diagram was produced. From this moment, each pair of developers was responsible for performing part of the modifications that were approved in the meeting. The following quote from Interviewee 2 (Company E) explains that: “The code refactoring meetings used to last too long, what made them unproductive, therefore we stopped implementing the changes during the meeting […]. Once the team is mature, we do not need to write code during the meeting, we just define what has to be done.” According to the quote above, since the members of the development team had similar knowledge about the software system, the implementation of the refactorings during meetings stopped to aggregate value to developers, i.e., the whole team knew enough about the software project because of their time working in the company and the low level of turnover in the organization. The following quote of Interviewee 1 and 2 from Company E illustrate this: “[…] It’s been a long time that we do not have employees leaving the company, and when new employees arrive, we make a presentation of the system to them […] and because of that we do not need to implement [the refactorings] in the meeting anymore. Everybody knows the system, its architecture, its modules […]. We all have the same development

Collaborative Refactoring: Results of an Empirical Study Using Grounded Theory

79

experience […]; the knowledge we spread before, everybody already knows and already absorbed it.”

Another result that we observed in in the studied companies is their unfamiliarity and lack of use of tools to assist in refactoring activities. About 73% of interviewees claimed that they do not trust in the effectiveness of the tools to correctly identify or execute the refactoring and about 58% of the interviewees is unfamiliar with tools that help one to plan a refactoring. This can be contrasted with the fact that in the last decade a great effort was spent creating tools, models and techniques to assist the refactoring activities, in addition to specific workshops to promote these tools, such as the WRT (Workshop on Refactoring Tools) that exists since 2007. We also noticed during this study the lack of tools that assist collaborative refactoring, since this practice, usual in every studied company, is performed frequently in a manual and non-automated way. This means that the creation of tools, techniques and approaches to assist collaborative refactoring tasks might be an interesting research direction for further exploration. There is, however, the need to perform additional interviews to understand in more details the need for such approaches and their potential adoption by the industry.

4 Conclusions The adoption of agile methods in software development projects is a relatively new theme and has raised a lot of interest, both to the industry and to the academy [3,4,16,18]. This study aimed to get additional insights about these methods by focusing in the refactoring activity. To achieve that, an empirical study was conducted, which used semi-structured interviews [18] for data collection and Grounded Theory [26] methods for data analysis. The results of our study suggest that the refactoring activity (in projects that use agile methods) is a collaborative activity, while previous work on refactoring [7,11] describes it as an individual practice. To the best of our knowledge, this collaborative aspect is not explored in the academy and can be important to help companies to perform their complex refactoring activities with more quality. Another important result of the study was the lack of tools to assist the activity of collaborative refactoring. This result indicates a research opportunity not yet explored by academy and industry. For instance, we envision the possibility of performing collaborative refactoring in a distributed way with the support of tools. As any other empirical study, our study has limitations. First, it focuses solely on Brazilian companies, which means that collaborative refactoring might not be true in other countries. And, since we adopted a qualitative approach, it is not possible to generalize our results; We plan to perform additional data collection to strengthen our results and gain more insights about the possible usage of tools to facilitate collaborative refactoring. Acknowledgments. This research was supported by the Brazilian Government under grant CNPq 473220-2008/3 and by the Fundação de Amparo à Pesquisa do Estado do Pará (FAPESPA) through “Edital Universal N.° 003/2008”. The first author wants to thanks the financial support that he received from UFPA.

80

P.J.F. Treccani and C.R.B. de Souza

References 1. Beck, K.: Extreme programming explained: embrace change. Addison-Wesley, Reading (2000) 2. Boehm, B., Turner, D.: Management challenges to implement agile processes in traditional development organizations. IEEE Software (2005) 3. Pikkarainen, M., Haikara, J., Salo, O., Abrahamsson, P., Still, J.: The impact of agile practices on communication in software development. Empirical Software Engineering (2008) 4. Miller, L., Sy, D.: Agile user experience SIG. In: CHI, Boston, USA (2009) 5. Kniberg, H.: Scrum e XP direto das Trincheiras. C4Media, Infoqueue (2007) 6. Manifesto for Agile Software Development, http://agilemanifesto.org/ 7. Fowler, M.: Refactoring - Improving the Design of Existing Code. Addison-Wesley, Reading (1999) 8. Boehm, B., Turner, D.: Using risk to balance agile and plan-driven methods. IEEE Comput. (2003) 9. Anderson, D.: Agile management for software engineering, applying the theory and constraints for business results. Prentice Hall, Upper Saddle River (2003) 10. Karlström, D., Runeson, P.: Integrating agile software development into stage-gate managed product development. Empir. Softw. Eng. (2006) 11. Fowler, M.: Is Design Dead? Appeared in Extreme Programming Explained (2001) 12. Chong, J., Siino, R.: Interruptions on Software Teams: A Comparison of Paired and Solo Programmers. In: Conference on Computer Supported Cooperative Work, Canada (2006) 13. Whitworth, E., Biddle, R.: Motivation and Cohesion in Agile Teams. In: Conference on Agile Processes in Software Engineering and Extreme Programming (2007) 14. Dybå, T., Dingsøyr, T.: Empirical studies of agile software development: A systematic review. Inf. Softw. Technol. (2008) 15. Lindvall, M., Basili, V., Boehm, B., Costa, P., Dangle, K., Shull, F., Tesoriero, R., Williams, L., Zelkowitz, M.: Empirical Findings in Agile Methods Source. XP/Agile Universe (2002) 16. Silva, A., Kon, F., Torteli, C.: XP South of the Equator: An eXPerience Implementing XP, Brazil, XP, Berlin, Heidelberg (2005) 17. Treccani, P., de Souza, C.: Utilização de Metodologias Ágeis no Desenvolvimento de Software: Resultados de um Estudo Empírico. In: ESELAW, Goiania-Go, Brasil (2010) 18. Dewalt, K., Dewalt, B.: A Guideline for Fieldworkers. Altamira Press (2002) 19. Glaser, B.: Theoretical sensivity. Sociology Press, Mill Valley (1978) 20. Palmer, S., Felsing, J.: A Practical Guide to Feature-Driven Development. Prentice-Hall, Englewood Cliffs (2002) 21. Ikonen, M., Kettunen, P., Oza, N., Abrahamsson, P.: Exploring the Sources of Waste in Kanban Software Development Projects. In: SEAA, Euromicro (2010) 22. Poppendieck, T., Poppendieck, M.: Lean Software Development. Addison-Wesley, Reading (2003) 23. Triviños, A.: Introdução à pesquisa em ciências sociais, São Paulo, Atlas (1987) 24. Glaser, B., Strauss, A.: The discovery of grounded Theory. Aldine de Gruyter, NY (1967) 25. Strauss, A., Corbin, J.: Basics of qualitative research, Thousands Oaks, CA (1998) 26. Glaser, B.: Theoretical sensivity. Sociology Press, Mill Valley (1978) 27. Maxqda2, http://www.maxqda.com/ 28. Rus, I., Lindvall, M.: Introduction: Knowledge Management in Software Engineering. IEEE Software 19(3), 26–38 (2002)

Communicating in a Transnational Network of Social Activists: The Crucial Importance of Mailing List Usage Saqib Saeed, Markus Rohde, and Volker Wulf Department of Information Systems and New Media, University of Siegen, Hölderlinstr. 3, 57076 Siegen, Germany {Saqib.Saeed,Markus.Rohde,Volker.Wulf}@uni-siegen.de

Abstract. Social movements need to coordinate their political activities. They are often characterized by a fragile organizational structure, and sparse personnel, financial and technical resources. In this paper we describe how a transnational networks of social activists, the European Social Forum (ESF), uses a central mailing list as a major communication tool. By means of a longterm field study, we analyzed the work practices of this network and observed the usage of the mailing list. The empirical findings highlight how the mailing list is used for a variety of different activities such as collaborative work, decision making, coordination and information sharing. We discuss the finding with regard to the discourse on cooperative work and come up with implications for design. Keywords: mailing list, email communication, community informatics, social activists, European social forum.

1 Introduction Despite the emergence of advanced communication and collaboration systems, email communication is still the preferred choice for many users. As a result email usage has regained attention of academics, focusing on understanding the email usage by specific communities, observing characteristics of email users and improving email functionality. Non governmental organizations and heterogeneous networks of social activists are challenging settings, where email seems to be the preferred mode of communication [c.f. 1-3]. However, Computer Supported cooperative Work (CSCW) literature lacks longitudinal ethnographic studies on communication practices in networks of social activists, whose members may even belong to different political, cultural, organizational and regional backgrounds. The communication process in these networks can be quite complex. Volunteer workforce, limited knowledge distribution and political sensitivity could easily bias information in such settings. That may result in mistrust or misinterpretation, which could easily impact the raison d’ etre of the whole enterprise. In this paper, we are particularly interested in analyzing how email communication is perceived in social activist networks, what are the problems in communication and A.S. Vivacqua, C. Gutwin, and M.R.S. Borges (Eds.): CRIWG 2011, LNCS 6969, pp. 81–88, 2011. © Springer-Verlag Berlin Heidelberg 2011

82

S. Saeed, M. Rohde, and V. Wulf

how the design of mailing list can be improved to better serve this specific community. In order to collect empirical evidence we looked at European Social Forum (ESF), a part of the social forum initiative which was started by activists involved in the anti globalization movement in 2001 at Porto Alegre, Brazil. The event was termed as World Social Forum (WSF) and after its success the event moved to Asia, as well as to Africa in subsequent years. The success of WSF triggered the creation of many other thematic and regional forums. ESF is the regional platform of European activists; further details of the case settings could be read in our earlier contributions [cf. 4-6]. In our long term ethnographic study, which lasted from January 2008 till October 2010, we closely observed the work practices of ESF activists. The empirical data was gathered using multiple research methods; participant observations, semi structured interviews and content analysis. The observations were carried out during eight field visits, whereas interviews were conducted from 31 different activists, comprising of approximately 20 hours of recorded content, which was transcribed later on. Some of the data has been used in earlier papers [4-6], where we found that mailing list is the most active means of communication among activists. In this paper we analyzed the data from a different perspective. We particularly elaborate the role of a central mailing list for the political process within ESF. We analyzed the mailing list to find the nature of sent content and the problems in the communication process. Based on our findings we develop design guidelines to improve mailing list functionalities in support of networks of social activists. In order to analyze empirical data we used grounded theory approaches [7] instead of hypothesis testing; we focused on identifying findings from empirical data. We followed day-to-day practices of activists and tracked the impact of European Preparatory Assembly (EPA) meetings and ESF actions on the mailing list content to identify the relationships. Long-term analysis of field practices and their impact on mailing lists helped us better understand the needs and problems of this communication medium. The paper is structured as follows. Section 2 discusses the mailing list and classification of messages and section 3 provides the findings from our work. In the last section we reflect on design implications and provide a brief conclusion and future outlook.

2 ESF Communication via the Mailing List The European mailing list is the most important channel of communication among ESF activists. All important activities related to ESF initiatives and EPA meetings such as announcements about the program, venue, schedule of the meetings etc. are mainly accessible through this mailing list. Due to the multi-lingual background of the activists, most of the communication is carried out in English language, but any other language could be used as well. People fluent in several languages could also forward the message using their multi lingual abilities. A practice, which was followed, especially at the start of the mailing list, was that once a message floated on the mailing list, someone tried to translate the message into different languages and resend it to the list. In order to better understand the coordination practices of actors in ESF, it is important to understand the usage details of the mailing list. We have classified the messages based on their nature in the following classes.

Communicating in a Transnational Network of Social Activists

83

2.1 Information Sharing The majority of the email messages were posted to disseminate information about different calls and initiatives carried out in different regions by ESF participants or other civil society actors. As an example of such messages, see the following email sent by an Italian activist in March 2009, who wanted to describe the initiatives planned in Italy, against the G20 meeting in London on 28th March 2009. “In Italy on the 28 March some networks and “X” will send a delegation to participate in the London demonstration ‘Put people first’ at the occasion of G20. In Rome there will be a national demonstration organized by “Y”. On 4 April there will be a national demonstration organized by “X”. An Italian delegation of different groups will participate in the Strasbourg-Kehl activities. The movement is plural!" This message highlights how activists could report their activities to other European partners and announce their own initiatives to get support of other activists. 2.2 Solidarity Support Some messages were used to forward appeals and receive support from other activists. The support could be a letter of support, signing a petition etc. An example of this kind of communication is the following message that floated on the mailing list on 5th November in 2009. “…Below and attached you will find an urgent action call-out from the “X”, San Luis Potosí, Mexico to send to Mexican and Canadian authorities demanding the application of the law and the immediate departure of “X” that has been operating in the Cerro de San Pedro since 1996. The project has engendered severely harmful environmental and social impacts despite the fact that not all of their permits are legal. ………….. Thank you for your solidarity. To send your letter to Mexican and Canadian authorities, please go to: http://weblink More information: http://weblink1 History of Cerro de San Pedro’ resistance: http://weblink2 and http://weblink3” 2.3 Information about Other Forums In order to remain aware of the activities of other social forums, email messages containing information about activities of other social forums (such as world/national/regional) is also floated on this mailing list. An example is the following message where an organization participating in the preparatory phase of the WSF 2011 in Dakar posted this information on the ESF mailing list: “Dakar launches a public consultation on the thematic axes for 2011. See the axes and send your contributions: http://weblink” A similar message where the declaration of the Polish Social Forum meeting is described is the following: “The declaration of founders of the Polish Social Forum. On the 26 June 2009 in Kielce the first meeting of the founders of the Polish Social Forum took place. The goal of the PSF is, like other regional and European forums, to create a common

84

S. Saeed, M. Rohde, and V. Wulf

space for groups and social movements which oppose the neoliberal economy, the domination of capital in social life and all forms of imperialism, and instead look to create a society which puts people first. The founders of the Polish Social Forum wish it to become a platform of common action and free exchange of thoughts, new ideas and experiences. Polish Social Forum” As a result, activists who cannot be active members in all the forums can also get information about state of the affairs. 2.4 Content Sharing Mailing list is also used to share important content, such as declarations, interviews, etc. with each other. The following email dated on 2nd July 2009 is an example of such kind of message. “Dear Friends, I wish to draw your kind attention to the interview with “X”, Vice Chairman of ATTAC Hungary. The interview was published in the International Socialist Journal: http://weblink” The archive of this mailing list containing rich set of information has become an organizational knowledge base. 2.5 Collaborative and Coordinative Work Sometimes mailing list is also used to carry out collaborative work in the ESF process. The most common example is planning of the agenda for EPA meetings, or other joint documents. One activist creates the initial points of the agenda and others give their feedback in order to realize a final version. The following message describes how an activist sets up the deadline for submitting correction in the meeting minutes. “Please send any correction for the minutes by tonight, so that I can send the list, final version. Thank you “X” for your help. Bye.” 2.6 Organizational Issues Another major use of mailing lists is to discuss organizational issues about planning EPA meetings or next ESF events. People could raise their queries, which can be sorted out by respective organizers. A good example for this is the following message from an activist requesting some information from the organizers of the ESF 2010 so as to share it on the Facebook group she was managing. “Thank you very much for your great effort ("final" timeline). Now 10 days before start of the ESF 2010 - no final program could be found on the official website. I`m sorry, but I couldn`t understand this fact. There are many questions on face book (program, payment, ), too and a lot of people want to know where and when the seminars / workshops are going to take place? When will the final program be published? Another important question: A journalist asked me today, where he can make his accreditation for the ESF. Is there any place for that, can you tell me (and us) yet? Thank you for answering the questions!”

Communicating in a Transnational Network of Social Activists

85

2.7 Decision Making Support As the ESF meetings take place only every 3-4 months, sometimes need may arise for decision making during this period, as things may not be going according to the plan. The mailing list is also used for decision making. This means that someone sends an email with a proposal and other activists either support or reject it through their follow up emails. During the organizing process of the ESF 2010, a meeting was scheduled in Brussels in April 2010. The proposed objective of the meeting was to come up with suggestions for merging different activity proposals in order to shorten the program of ESF 2010. During ESF 2010 proposed activities were not too many, so Turkish organizers proposed to cancel the meeting at all. An Italian activist proposed not to cancel it, but connect it with the EPA meeting already planned for Istanbul in May 2010, as can be seen in following email excerpt. “………… Thus, my proposal is: 20th May all day long merging group 21th May in the morning (if necessary) merging group; from 14h on, Networks meeting 22th-23th EPA And, please, in the future let's try to have a good dialogue more often than now….” Other activists accepted this proposal by sending emails and as result the Brussels meeting was merged with the EPA meeting in Istanbul.

3 Findings Although the mailing list is the main channel for information dissemination at the ESF, our investigation identified some significant problems. In this section, we briefly describe our findings from this case study. The storage of old emails for future use is in line with the finding of Mackay [8] who states that emails are used for information retrieval as well. This helps activists to re-use information. On the other hand, it is true that individuals who are not members of the mailing list are able to access the email archive, but finding information according to their needs is difficult. One has to navigate through each email to find useful information from the archive, as search for emails and contents related to a specific theme/keyword is not possible. The tracking of email responses becomes difficult when one uses it to collaboratively prepare a document. This was evident especially when activists sent emails to support some initiative or when the agenda of the EPA meetings was written. It was observed that contributions from some activists could not be added to the final version of the document, due to the oversight of the email. As a result, they had to constantly raise their reservations via email. If initiating activists had not carefully cross-checked that their contributions are present in the final document, then the final document may lack their contributions and they might have misinterpreted it in a way that it was left out intentionally. This means a more thorough revision of the finalized document is required, which, of course, is rather time-consuming. Since this is a loose network with no defined responsibilities, people tend to help each other with as much information as they have. Hence, sometime they may pass on

86

S. Saeed, M. Rohde, and V. Wulf

rather incomplete/old information causing several misunderstandings. A good example is about accommodation requests about ESF 2010. A member of the Greek social forum posted on the mailing list to ask if someone already knew details about free accommodation during ESF 2010, as he had no response from the Turkish organizing committee. A German activist, helping to float the information about the ESF 2010, thought that this member from the Greek social forum had not registered for accommodation and thus advised him to ask for accommodation at an email address. The Greek activist felt angry and thought that someone was making fun of him, as he had already contacted this email address, but left without any further response. Similarly, in another case an Austrian activist kept sending emails in German language to which an Italian activist objected that less than one percent of the people understand it - so why send messages in German? At this moment a French activist intervened and explained that in early 2003, when they were setting up mailing list, everyone was allowed to write in his/her own language and interpreters helped in translating the message into various languages. He thought this practice should be adopted instead of just using English as a universal language. In another instance, a Polish activist sent around a website address for other members to read an article about the struggles of Poland. A Russian activist commented that the web link belongs to a political party and political parties are not allowed in social forum. The Polish sender responded that he did not send the link to promote it, but to give information about articles highlighting the social struggle in Poland, which, of course, could be interesting for many activists.

4 Implications for Design In terms of extending the technical requirements for ICT support, some technical requirements are quite evident. The mailing list is an important source of information, however, the members of the mailing list constitute a closed group and despite the availability of websites the information is often not forwarded to them. Mathieson, [9] pointed out factors that influence volunteers to update a website using a content management system in order to help voluntary organizations in finding new members. To find volunteers for longer periods of time is difficult and an automatic updating mechanism of the website based on the mailing list can help to establish a better information flow so that new activists could be won for ESF processes. As soon as a new email message floats on the mailing list, this information is replicated as a thread on the website so that everybody can view the information from the website. The archive of the mailing list contains extensive information about the ESF process and related activities. This historic information can be used for identifying experts in different political domains covered by activities of the ESF. An email based expertise recommender system could help in identifying actors to indulge in cooperation across national and workshop boundaries [10]. This way, the visibility of even those activists can be strengthened that do not attend EPA meetings on a regular basis. In order to improve information access towards the email archive, text mining and visualization algorithms [c.f. 11] can be employed. Such functionalities would then make it easier to extract the required information and also messages can be

Communicating in a Transnational Network of Social Activists

87

clustered visually based on time sequence, thread structure or content. Consequently, the mailing list could develop into an important resource for knowledge sharing. Language is an important issue in ESF communication and the practice of translating content with the help of volunteer activists does no longer work in an efficient way. Email messages other than those in English language may not be understood by all activists so a machine based back and forth translation [c.f. 12] of email contents could help to overcome this problem to some extent. Despite being helpful, there are considerable problems with emails concerning information management [13]. Using mailing lists as a central collaborative tool mainly bears the problem of overlooking important contributions. To cope with this problem a rich mailing mechanism for collaborative messaging can be employed, grouping relevant messages. Similarly, in order to better support the decision making process, a voting system should be integrated into the mailing list [c.f. 14]. For certain types of issues, such functionality would introduce more transparency as compared to email based decision making. Furthermore, in order to provide a better background for the communication within the mailing list, a profile of the users and their involvement in earlier discussions can contextualize contributions and highlight the involvement level of the actor.

5 Conclusion Social activists are an important section of society due to their involvement in advocacy and campaign work on behalf of the deprived individuals in society. In today’s world where the legitimation of traditional means of political representation is questioned, there is an intense need for these social groups. In order to be more effective, these groups need to be coherent in their work to act as an effective pressure group. The communication process is vital for their success to coordinate and disseminate the relevant information among themselves and the public. Despite the need for an effective communication process, restricted financial and human resources lead to a situation in which they cannot afford sophisticated communication solutions. This paper discusses the mailing list usage of a network where activists and social organizations of heterogeneous size and cultural background converge. Our investigation highlights that the email list is the most preferred tool for activist communication and coordination of their activities, a result which is in line with the findings of Kavada [2]. It was observed that accessing old information becomes difficult and hampers collaborative work as important responses may get over sight. Furthermore, sometimes misinterpretations arise due to ambiguous text of email messages. In order to better understand the communication pattern, we analyzed the messages of the mailing list. Based on the communication problems found in our field study, we proposed generic guidelines for developing new functionalities in order to improve mailing lists. There has been extensive work on the use of emails in organizational settings and for personal use [c.f. 15-17]. Our study confirms that emails are still appropriate for a variety of innovative tasks [c.f. 18]. As a next step we plan to develop prototypes and evaluate them in practice with the help of ESF activists. The evaluation in practice will give us first hand feedback on the effectiveness of the design concepts.

88

S. Saeed, M. Rohde, and V. Wulf

References 1. Cogburn, D.L.: Diversity Matters, Even at a Distance: Evaluating the Impact of ComputerMediated Communication on Civil Society Participation in the World Summit on the Information Society. Information Technologies and International Development 1(3-4), 15– 40 (2004) 2. Kavada, A.: The European Social Forum and the Internet: A Case Study of Communication Networks and Collective Action. Ph.D Thesis, University of Westminster, UK (2007) 3. Saeed, S., Rohde, M., Wulf, V.: An Empirical Study of IT Use in Pakistani Civil Society Organizations. In: Lytras, M.D., Ordonez De Pablos, P., Ziderman, A., Roulstone, A., Maurer, H., Imber, J.B. (eds.) WSKS 2010. CCIS, vol. 111, pp. 521–527. Springer, Heidelberg (2010) 4. Saeed, S., Rohde, M., Wulf, V.: Technologies within Transnational social activist communities: An Ethnographic Study of the European Social Forum. In: 4th International Conference on Communities and Technologies, pp. 85–94. ACM Press, New York (2009) 5. Saeed, S., Rohde, M.: Computer Enabled Social Movements? Usage of a collaborative web platform within the European Social Forum. In: 9th International Conference on the Design of Cooperative Systems, pp. 245–264. Springer, Heidelberg (2010) 6. Saeed, S., Pipek, V., Rohde, M., Wulf, V.: Managing nomadic knowledge: a case study of the European Social Forum. In: 28th International Conference on Human Factors in Computing Systems, pp. 537–546. ACM Press, New York (2010) 7. Strauss, A.L., Corbin, J.M.: Basics of qualitative research: techniques and procedures for developing grounded theory. Sage Publications, Thousand Oaks (1998) 8. Mackay, W.: Diversity in the Use of Electronic Mail: A Preliminary Inquiry Transactions on Office Information Systems 6(4), 380–397 (1988) 9. Mathieson, K.: Factors influencing intentions to maintain web content in voluntary organizations. In: 2006 SIGMIS CPR Conference, Pomona, California, pp. 169–171 (2006) 10. Reichling, T., Veith, M., Wulf, V.: Expert Recommender: Designing for a Network Organization. Computer Supported Cooperative Work: The Journal of Collaborative Computing (JCSCW) 16(4-5), 431–465 (2007) 11. Rohall, S., Gruen, D., Moody, P., Kellerman, S.: Email visualizations to aid communications. In: IEEE Symposium on Information Visualization, pp. 12–15. IEEE Press, Los Alamitos (2001) 12. Yamashita, N., Ishida, T.: Effects of Machine Translation on Collaborative Work. In: International Conference on Computer Supported Cooperative Work, pp. 515–523. ACM Press, New York (2006) 13. Whittaker, S., Sidner, C.: Email overload: Exploring personal information management of email. In: 1996 Conference on Human Factors in Computing Systems, pp. 276–283. ACM Press, New York (1996) 14. Davis, M.: eVote adds elections to mailing lists. Linux J. 107(1) (2003) 15. Schmitz, J., Fulk, J.: Organizational colleagues, media richness, and electronic mail. Communication Research 18, 487–523 (1991) 16. Markus, M.L.: Electronic Mail As the Medium of Managerial Choice. Organization Science 5(4), 502–527 (1994) 17. Takkinen, J., Shahmehri, N.: Delegation of tasks and dissemination of information in organizations: Restructuring internet e-mail for doing things. In: AIS 1998 American Information Society Americas Conference (1998) 18. Mills, S.: Caring through technology: Using e-mail for Christian pastoral care. Interacting with Computers 23(2), 106–116 (2011)

Does “Virtually Being There” Help? Comparing Collaborative Work between 3D and 2D Conditions Hannes Olivier and Niels Pinkwart Clausthal University of Technology, Department of Informatics {hannes.olivier,niels.pinkwart}@tu-clausthal.de

Abstract. 3D Collaborative Virtual Environments (CVEs) have been in the focus of CSCW research for some time. This paper presents a study comparing teamwork done in a CVE with teamwork done in a 2D remote condition and a F2F control condition. The tasks done were designed for groups without prior knowledge; they did not favor any of the environments. In some dependent variables, the 3D environment outperformed the other conditions while in others it kept on par. Keywords: CSCW, Virtual Environments.

1 Introduction During the last 20 years, we observed a change of markets where it became increasingly common for companies to globalize and communicate with consumers and business partners all over the world. Traveling costs are high and, therefore, alternatives are used for remote cooperation. Also, work is being done while people are not physically present at the same place [1, 2]. These driving forces spawned increased CSCW research into finding alternatives for supporting remote teamwork [1, 2, 3]. Popular resulting technologies like email, video conferencing and instant messaging offer cheap solutions for replacing face to face meetings [3, 4]. Unfortunately, these solutions do often have problems when they are used in a remote work context. For instance, the reduced spatial awareness and missing secondary communication aspects (e.g., gestures) may hinder the building of trust often needed for successful collaboration [5, 6]. To offer a solution for this problem, different three dimensional Collaborative Virtual Environments (CVEs) have been (and are being) developed. Examples include “Croquet” [7] and “Open Wonderland”1. Collaborative 3D environments are becoming increasingly popular and today play a role in many aspects of life, including leisure and education (e.g., “World of Warcraft”2: over 10 million users; “Second Life”3: 12 million accounts). Also the research area of CSCW has been investigating CVEs for professional applications for some time [8]. While older 1

Open Wonderland: http://openwonderland.org/ Blizzard Entertainment: http://www.wow-europe.com/de/index.xml 3 Linden Lab: http://secondlife.com/ 2

A.S. Vivacqua, C. Gutwin, and M.R.S. Borges (Eds.): CRIWG 2011, LNCS 6969, pp. 89–101, 2011. © Springer-Verlag Berlin Heidelberg 2011

90

H. Olivier and N. Pinkwart

studies emphasized technical realization challenges of CVEs, current research projects typically put an emphasis on human computer interaction aspects. Previous research has, for instance, looked at different aspects of avatars like how customization options increase identification with the avatar [9]. This private selfawareness allows for reflecting ones attitudes, standards [10] and emotional states [11]. This is helpful for some group work activities. Other studies have analyzed current CVEs to find social behavior and relationships [12]. CVE environments have also been used in educational research for some time [4, 13]. CVEs have been used successfully in advertising [14, 15], and simulated scenarios based on CVEs were used successfully for treating psychological problems like phobias and social anxiety disorders [16, 17, 18, 19, 20]. CVEs have potential advantages compared to other communication conditions. Compared to plain text (e.g., in chats), they include a humanoid avatar which allows for visual identification. The avatars also offer an awareness function indicating where everybody is working and maybe even what he is working on. This information is often common in real life offices, but missing in remote conditions. The inclusion of this information in a digital remote condition can improve work results [21]. Compared to audio communication, avatars in CVEs are able to do gestures, therefore adding another layer of information to the communication. Unfortunately, most CVE environments do not yet support a wide range of these natural communication expressions [22]. Most systems do allow for some canned avatar gestures, but still these have to be triggered manually and explicitly. This is still a major problem since studies indicate that about 65% of human communication is nonverbal [23] and often unconscious. The need for this communication was already studied in different areas [24, 25, 26, 27]. E.g., Neviarouskaya and colleagues used software to automatically recognize nonverbal cues directly from the text [28, 29]. The results of these studies included that an automatic recognition and visualization of emotional states can have a significant impact on perceiving social presence. It is often considered important for people to “feel like being there” – at the place they are working or communicating with each other. Immersion in a 3D environment, intended to lead to this effect, has been studied before [30, 31]. However, devices such as head-mounted displays can generate other problems like unnatural nonverbal communication [32, 33]. Indeed, research shows that non-verbal avatar expressiveness may not need full tracking [23, 32, 34, 35, 36]. Finally, advantages 3D environments may have compared to video conferencing include spatial awareness (moving around in a CVE is easier and more meaningful than in a video conference) and the option of including larger groups of people. Despite these potential advantages over other forms of remote collaboration, there are still few studies investigating if CVEs do really improve cooperative work as compared to other remote conditions. First results include that 3D environments improve the retainability of information in comparison to text chat communication [37] – but what about work efficiency and user satisfaction? This paper presents the results of a study comparing four different collaborative conditions. Two conditions are variants of a CVE, these are compared to a 2D remote condition and a face-to-face “benchmark” control condition. In the study, groups had

Does “Virtually Being There” Help? Comparing Collaborative Work

91

to collaborate on four different tasks in order to produce group results for each of these tasks. The tasks were selected to be not favoring any of the conditions and to be inducing collaboration.

2 Research Hypotheses The main research question for the study presented in this paper was to investigate if 3D environments can improve collaborative work in comparison to 2D remote scenarios. Our main hypothesis here is that 3D environments can support cooperation better than 2D environments can do. Specifically, this general hypothesis can be broken down in several subhypotheses, related to different facets of system usability (effectiveness, efficiency and subjective satisfaction). • • • • •

H1: Groups using 3D CVEs are producing better results than groups using 2D collaboration systems (effectiveness). This expectation is based on the assumption that improved awareness information increases productivity. H2: Groups using 3D CVEs are producing results faster than groups using 2D collaboration systems, because the improved communication options reduce discussion times (efficiency). H3: Cooperative work in 3D CVEs is perceived as more engaging than cooperative work in 2D environments, because they mirror reality better. H4: People using 3D CVEs perceive their work tasks as easier than people using 2D tools. If people feel unsatisfied using a tool, their work motivation and performance might drop. H5: Adding nonverbal communication channels to a CVE (such as head movements) increases the benefits of a 3D CVE, because the additional communication aspects (head gestures like nodding in agreement) reduce the time needed for communication and coordination.

3 Study Description To answer the research questions, a laboratory study was designed. In this study, different groups had to solve the same tasks in different environments. The group performance was compared between the conditions. In this section, we first describe the tasks that the participants of our study had to complete. Subsequently, we detail the conditions we compared in the study (using a between-subjects design), describe the methods of data collection, the participant sample and the technical setup. 3.1 Tasks To find out about the possibilities of a 3D environment for supporting group work through increased communication, tasks had to be devised which did not directly favor a 3D environment over a 2D environment (such as 3D modeling tasks would have), and which require cooperation or coordination. Overall, four different tasks were designed. For all tasks, the members of the groups had to agree on one solution.

92

H. Olivier and N. Pinkwart

The first task presented picture riddles to the groups. The participants were shown pictures and had to guess what object this picture represents. The pictures only showed a small portion of the whole object. Here, the participants were supposed to agree on a solution (which was recorded later in individual interviews).

Fig. 1. Example of a picture riddle (part of an AA battery)

The second task was a series of multiple choice (MC) questions. These were general questions about topics such as science, history and movies. Once one user had answered a question, the next question was shown to all participants. Therefore, participants had to agree prior to clicking. An example question was which planet is closest to Earth (with four solution alternatives offered). The third group of problems consisted of text riddles. The participants were given four different riddles. Again, the participants were supposed to find and agree on a solution and record it individually later. One of the riddles was: “Two men meet on a plane flying from Berlin to Munich. They both fly between these cities quite often. For one of them it is his 13th flight. For the other one it is his 20th flight. One is living in Munich and one in Berlin. Who is having his 13th and who is having his 20th flight?” The fourth and last task set included the writing of a poem. The users were instructed to write a poem which needed to rhyme and needed to have a minimum number of lines. Each user got a set of two different words to be used in the poem. It was therefore needed to communicate these words and to agree on how to write the poem. The poem task was considered sufficiently solved if the required words were used and if the rhyme and minimum lines were present. 3.2 Conditions and Technical Setup For the study, four different conditions were prepared. These included a 3D condition (3D), a 3D condition with a head-tracking software (3D+HT), a 2D remote condition (2D) and, for reference, a face-to-face condition (F2F).

Does “Virtually Being There” Help? Comparing Collaborative Work

93

For the 3D and the 3D+HT conditions, Open Simulator and a Second Life viewer were used. The study tasks were presented to the users on virtual white boards (generated using prims, Linden Scripting language and images) located in the virtual world. Here, four virtual white boards were presented. Figure 2 shows a view on this 3D world showing the first three tasks.

Fig. 2. A view on the CVE environment with the participants and the tasks

The second condition (3D+HT) was a similar one to the first, but differed in one aspect: The avatar’s head movements were synchronized with the user’s head moves using a head tracking software (a lightweight version which made use of the video camera built into the laptop computers used in the study). The users were not informed that this software was used. Figure 3 shows the video taken by the camera (which was, of course, not visible to the study participants) and the corresponding head movement of the avatar.

Fig. 3. Head positions of avatar and user

In the 2D remote condition, Skype was used for communication between the participants who had access to a group chat and an audio conference call. The digital white boards used in the 3D conditions were replaced with web pages with the same content and usage (see Fig. 4 for an example of a picture riddle). If one user clicked an answer, the next question showed up for all users (just like in the 3D conditions).

94

H. Olivier and N. Pinkwart

Fig. 4. Webpage of the picture riddle

The last condition was a face-to-face control condition. In Figure 5, a group of study participants is shown working together in the same room. The problems were presented in a browser window (like in the 2D condition), and the participants had an interactive white board and a keyboard at their disposal to interact with the browser.

Fig. 5. F2F condition

Does “Virtually Being There” Help? Comparing Collaborative Work

95

3.3 Data Collection The study was divided into three parts. First, the participants had to fill out a questionnaire which included questions about computer use habits and previous experience with technologies like 3D games and digital white boards. During the main part of the study, the participant’s response times for the tasks (H2) and correctness of the answers (H1) were recorded. Also, the participants were videotaped to analyze their head movements (H3). The coding scheme for the head movements used within our analysis was proposed in [12] and included the following categories: side-way turn, jerk, waggle, nod, shake, thinking posture and “looking away from the screen”. Of particular importance was the “looking away from the screen” category, since this may indicate a low focus on the task (all information needed for the tasks was only presented on screen). After the main study part, the participants were asked to complete another questionnaire about their opinion about the systems used and the problems presented (H4). 3.4 Participants The use of 3D CVEs (without extensive training) requires a certain level of computer affinity. Therefore, for the study, the participants were selected from students and interns at a University. All participants were between 21 and 32 years old. This selection of participants increased the chance that the groups had a similar level of background knowledge. This was needed since especially the multiple choice questions were about general knowledge. Therefore, highly heterogeneous age groups might have confounded the study results. The participants were randomly assigned to groups of three persons. The groups were then assigned randomly to study conditions. Participants were paid for participating in the study. The participants did not know each other and did not meet before the study. In each condition, four groups of three people worked on the tasks together. A short time was allotted for each person to get used to the system (longer for the 3D conditions, shorter for the other conditions). During the preparation in the 3D conditions, the users were allowed to get familiar with the 3D system and to individualize their avatars. Also, a short example of a task was shown to allow users to get used to the handling. For the F2F and the 2D conditions, just some short task examples were shown. For the tasks, the groups had a total time of 50 minutes. The tasks had to be finished in order.

4 Results The study was analyzed in different aspects. To find out if the different conditions produced different results, the solutions of the groups were analyzed and compared. For the riddles tasks, the answers given by the individual team members were compared. If the group members had written down the same solution, the answer was accepted as the group’s answer. For the poem tasks, a solution was accepted if the criteria were met. All groups had a correct solution for the poem.

96

H. Olivier and N. Pinkwart

To analyze H1, an ANOVA test was conducted to test if there were significant differences in terms of solution quality between the four conditions. The test did not show a significant difference between the results of the tasks, except for the text riddle tasks. Here, however, a follow-up pairwise t-test did not show any significant results between any two conditions. Yet, the 3D settings had the highest average in terms of the number of correct solutions. Table 1 shows the results of the questions and the significance value resulting from the ANOVA test. Concerning hypothesis H2, the time needed to solve the problems also did not show any difference between the two 3D conditions (for technical reasons, the time recording for the poem task in the F2F condition was not possible). Table 1. Mean and standard deviation of the number of correct solutions Task (max. possible correct solutions) # correct picture riddles (3) # correct MC (20) # correct text riddle (4)

3D+HT Mean(std)

3D Mean(std)

2D Mean(std)

F2F Mean(std)

p

2,2(0,9)

1,7(1,5)

2,0(1,5)

2,0(0,8)

>0,9

14,5(2,6) 3,7(0,5)

14,0(3,2) 3,7(0,5)

13,2(0,9) 2,7(0,5)

12,7(0,5) 3,2(0,5)

>0,7 <0,05

To investigate H3, the engagement of the people at the computer was analyzed using the video data. The head movements and gestures of the study participants were coded according to the scheme proposed in [38]. From the coding categories, the most important information was how often people looked away from the monitor (looking around in the room or focusing on tools outside the computer). This movement usually indicated that participants were distracted from their task, since communication and task information were all on screen. For the F2F condition, a different coding scheme was needed to achieve comparable results. Participants did not only look at the white board but also at each other. For a group working together in a room, this is a common behavior and not a sign of missing focus on the task. Therefore, in the F2F condition, every time a participant was looking away from the whiteboard and from the other group members, this behavior was counted as “off-task”. An ANOVA test between conditions was conducted, resulting in a significant difference between conditions. Afterwards, a pairwise t-test was conducted using the method of HOLM to take into account alphaerror accumulation. This analysis showed a significant difference between the 3D+HT and the 2D condition (p<0.01). The users using the 3D+HT environment showed much greater focus on the system than the users who accessed the tasks through a 2D interface.

Does “Virtually Being There” Help? Comparing Collaborative Work

97

Table 2. Number of head movements away from the monitor/the other participants

#movements

3D+HT Mean(std) 5,9(5,0)

3D Mean(std) 15,4(14,4)

2D Mean(std) 21,3(12,6)

F2F Mean(std) 12,7(7,8)

p <0,05

When analyzing the answers given concerning the perceived difficulty of the problems (H4), an ANOVA test showed a significant result (p<0.01) for the picture riddles, with a significant difference between the 3D environment without headtracking and both the 3D with head-tracking and the 2D remote conditions. The participants of the 3D without head tracking considered the task as more difficult than the users in the other conditions (H5). A similar result holds for the poem task. Here, the ANOVA also showed a significant difference overall, but a pairwise t-test did not give a significant difference between two conditions at the .05 level. Participants in the 3D groups without head-tracking also stated in the post survey that they felt that they needed a lot of time to answer the problems. However, this was not really reflected in the actual answering times where there was no statistically significant difference between all groups. Table 3. Perceived difficulty of tasks. (1= very difficult, 5= very easy).

Picture riddle MC Text riddle Poem

3D+HT Mean(std) 3,6(1,3)

3D Mean(std) 2,3(1,3)

2D Mean(std) 3,9(0,9)

F2F Mean(std) 3,2(1,0)

p <0,01

3,2(0,7) 3,6(1,3) 3,3(1,1)

2,6(0,8) 3,0(1,2) 2,0(1,0)

2,8(1,1) 3,0(0,9) 3,5(1,5)

3,0(0,8) 3,2(1,3) 3,3(1,3)

>0,4 >0,5 <0,05

For most study hypotheses, no significant differences were found between the conditions. But still, some interesting trends could be seen. For example, the users of the 2D remote condition found the usage easier than the F2F group which used exactly the same browser software but a digital board with a pen in comparison to a computer screen with a mouse.

5 Discussion 3D environments have been hyped for some time. Research is required to test if these environments can actually be a good alternative for collaborative work. The first steps in our research, presented in this paper, were to investigate how a 3D environment compares to a 2D one (and to a face-to-face situation). Since there was no significant difference in the quality of the group results, H1 has to be rejected overall. However, there was also no indication that the 3D and 3D+HT conditions performed worse than 2D or (interestingly!) F2F. On the contrary, in case of the text riddles, the 3D environments produced a higher solution quality than the

98

H. Olivier and N. Pinkwart

other two settings. Therefore, both 3D settings did not negatively influence the performance of group’s work. Also H2 was not statistically supported. Again, this is not a too bad result considering that the people in the 3D conditions actually had the most difficult tool handling and the participants in our study did not have experience with this 3D environment beforehand. Under these circumstances, one might easily have expected that users in the 3D conditions would have taken longer to solve the tasks. But, according to our data, this was not the case. One might thus hypothesize that if the users had had more experience with 3D CVEs, this might even have resulted in faster solution times for the tasks. H3 was partially confirmed. The 3D setting did not lead to a significantly better user’s focus, but the 3D+HT did improve against the 2D condition. This better focus might be accounted to the aspect that users might have been distracted by the 3D environment itself. Compared to 2D, 3D environments present additional information: a 3D world includes a sky, buildings, and other objects. This information can indeed be a distraction that could explain the increased “looks towards the screen”. However, in this study, the 3D environments were purposely kept very simple and did not offer many sources for such distraction. The only main difference between 2D and 3D were the user avatars – as such, it makes sense to attribute the increased attention of the users to the visibility of their cooperation partners. This result that people watched the screen more in the 3D condition can be used to include ambient information in the environment, allowing to convey important awareness information to users even while they are “distracted” [39]. The subjective views of the participants were interesting. People using the 3D condition without the head tracking perceived some (but not all) of the tasks as more difficult and their response time as slower, supporting H4. Interestingly, this effect was not observable for the 3D+HT condition which was on par with the 2D and the F2F conditions. When it comes to H5, our data shows the general picture that the users in the 3D+HT condition showed better results than their peers in the 3D condition. Not in all measures this difference reached the level of statistical significance (probably due to a relatively low sample size), though. The perceived difficulty measure, for example, was much lower for the 3D+HT than for the 3D. This gives enough motivation to include other awareness tools in the future to see if this margin between “standard avatars” and “avatars with realistic behavior” (for instance, including also body postures in addition to head movements) can be widened. Comparing the 2D remote and the 3D remote condition, one advantage already showed up during the test itself. The first 2D group looking at the picture riddles first discussed if they were actually seeing the same part of the picture. The users in the 3D environment did not even consider the option that they might be looking at a different picture (even if that would be possible in the 3D world). So the 3D users had the feeling that they were getting the same information.

6 Conclusion The study presented in this paper was conducted to find out if a 3D environment is capable of helping people work together more effectively and efficiently than other

Does “Virtually Being There” Help? Comparing Collaborative Work

99

cooperation tools (audio + chat + 2D). The used 3D environment did not show any usability problems and did not lead to a decrease in the quality of the results of the completed tasks. We found indications that 3D environments with awareness techniques like head-tracking can improve collaboration, especially as compared against 2D tools. In our study, a F2F control condition was added as a benchmark to see how technology based cooperation compares to the “gold standard” of rich interaction in the real world. It is a nice surprise to see that the computer mediated solutions are actually very close to F2F concerning work results and user satisfaction. Future work will include the extension of the 3D+HT environment with different awareness features. Some of the features can be inspired by the gaming community where awareness tools are often designed from player for players. These tools are often designed with different specialized aspects of group work in mind. For collaborative work in a 3D environment, features like miniature maps might help with coordination, for instance. In any case, further studies are needed to see if these environments are a real alternative to other remote CSCW technologies.

References 1. Mohrman, S.A.: The Contexts of Geographically Dispersed Teams and Networks. Trends in Organizational Behavior 6, 63–88 (1999) 2. Vom Brocke, J.,Riemer, K., Richter, D.: Zur Rolle von Kooperationssystemen in verteilten Forschungsnetzen-Ergebnisse einer Social Network Analysis im Network of Excellence GARNET. In: vom Brocke, J. (ed.) Proc. Multikonferenz Wirtschaftsinformatik (MKWI), München (2008) 3. Riemer, K., Wulf, K.: Marktstudie Kooperationssysteme: Von E-Mail über Groupware zur Echtzeitkooperation. Cuvillier Verlag (2005) 4. Redfern, S., Naughton, N.: Collaborative Virtual Environments to Support Communication and Community in Internet-Based Distance Education. Journal of Information Technology Education (2002) 5. Batcheller, A.L.: Testing the Technology: Playing Games with Video Conferencing. In: Proceedings of CHI 2007, pp. 849–852 (2007) 6. Kramer, R.M.: Trust and Distrust in Organizations: Emerging Perspectives, Enduring Questions. Annual Reviews Psychology 50, 569–598 (1999) 7. Smith, D.A., Kay, A.C., Raab, A., Reed, D.P.: Croquet - A Collaboration System Architecture. In: Proceedings of the Conference on Creating, Connecting and Collaborating Through Computing (C5), vol. 79(1), pp. 2–9 (2003) 8. Benford, S., Bowers, J., Fahlen, L.E., Greenhalg, C.: Managing Mutual Awareness in Collaborative Virtual Enviroments. In: Proceedings VRST 1994, ACM Press, Singapore (1994) 9. Vasalou, A., Joinson, A.N., Pitt, J.: Construction my Online Self: Avatars that Increase Self-focused Attention. In: Proceedings of CHI 2007, vol. 7(2), pp. 445–448 (2007) 10. Fenigstein, A., Scheier, M.F., Buss, A.H.: Public and private selfconsciousness: Assessment and theory. Journal of Consulting and Clinical Psychology 43, 522–527 (1975) 11. Scheier, M.F.: Self-awareness, selfconsciousness, and angry aggression. Journal of Personality 44, 627–644 (1976) 12. Ducheneaut, N., Yee, N., Nickell, E., Moore, R.J.: Alone Together? Exploring the Social Dynamics of Massively Multiplayer Games. In: Conference Proceedings on Human Factors in Computing Systems CHI, pp. 407–416 (2006)

100

H. Olivier and N. Pinkwart

13. Livingston, D., Kemp, J.: Proceedings of the Second Life Education Workshop at the SLCC (2006) 14. Barnes, S.: Virtual worlds as a medium for advertising. SIGMIS Database 38(4), 45–55 (2007) 15. Hemp, P.: Avatar-based marketing. Harvard Business Review 84(6), 48–56 (2006) 16. Botella, C., Quero, S., Baños, R.M., Perpiñá, C., Garcia Palacios, A., Riva, G.: Virtual Reality and Psychotherapy 17. Botella, C., Osma, J., Garcia-Palacios, A., Quero, S., Baños, R.M.: Treatment of flying phobia using virtual reality: Data from a 1-year follow-up using a multiple baseline design. Clinical Psychology and Psychotherapy 11, 311–323 (2004) 18. Frey, A., Blunk, H., Banse, R.: Paarinteraktionsforschung in einer virtuellen Umgebung. Zeitschrift für Sozialpsychologie 37(3), 151–159 (2006) 19. Herbelin, B., Riquier, F., Vexo, F.: Virtual Reality in Cognitive Behavioral Therapy: a Study on Social Anxiety Disorder. In: 8th International Conference on Virtual Systems and Multimedia, VSMM (2002) 20. Moore, K., Wiederhold, B., Wiederhold, M., Riva, G.: Panic and agoraphobia in a virtual world. Cyberpsychology & Behavior 5(3), 197–202 (2002) 21. Gutwin, C., Greenberg, S.: A descriptive framework of workspace awareness for real-time groupware. Computer Supported Cooperative Work (CSCW) 11(3), 411–446 (2002) 22. Bowman, D.: Interaction Techniques for common tasks in immersive virtual environments (design, evaluation and application). PhD thesis, Georgia Institute of Technology (1999) 23. Argyle, M.: Bodily Communication. Methuen & Co, London (1975) 24. Allmendinger, K., Troitsch, H., Hesse, F., Spada, H.: Nonverbal signs in virtual environments. Designing for Change, 431–440 (2003) 25. Pfendler, C., Widdel, H., Schlick, C.: Evaluation of a head-mounted display and a handheld display with a target detection task. Zeitschrift für Arbeitswissenschaft 59(1) (2005) 26. Rüeggenberg, S.: So nah und doch so fern: So-ziale Präsenz und Vertrauen in der computervermittelten Kommunikation. PhD thesis, Universität Köln (2007) 27. Tegtmeier, A.: Augmented Reality als Anwendungstechnologie in der Automobilindustrie. PhD thesis, Fakultät Maschinenbau der Otto-von-Guericke-Universität Magdeburg (2007) 28. Neviarouskaya, A., Prendinger, H., Ishizuka, M.: User study of affectIm, an emotionally intelligent instant messaging system. In: Prendinger, H., Lester, J.C., Ishizuka, M. (eds.) IVA 2008. LNCS (LNAI), vol. 5208, pp. 29–36. Springer, Heidelberg (2008) 29. Neviarouskaya, A., Prendinger, H., Ishizuka, M.: Emoheart: Automation of expressive communication of emotions in second life. Online Communities and Social Computing, 584–592 (2009) 30. Bricken, M., Byrne, C.M.: Virtual reality: Applications and exploration. Summer Students in Virtual Reality, 199–218 (1993) 31. Schaeppi, B., Kirchgeorg, M.: Handbuch Produktentwicklung. Carl Hanser Verlag Muenchen (2005) 32. Bailenson, J., Beall, A., Blascovich, J.: Gaze and task performance in shared virtual environments. The Journal of Visualization and Computer Animation (2002) 33. Sejima, Y., Watanabe, T., Yamamoto, M.: Analysis by Synthesis of Embodied Communication via Virtual Actor with a Nodding Response Model. In: Proc. of the Second International Symposium on Universal Communication (2008) 34. Bailenson, J., Blascovich, J.: Avatars. In: Encyclopedia of Human-Computer-Interaction. Berkshire Publishing Group (2004)

Does “Virtually Being There” Help? Comparing Collaborative Work

101

35. Garau, M., Slater, M., Bee, S., Sasse, M.: The impact of eye gaze on communication using humanoid avatars. In: Proc. of the SIGCHI Conference on Human Factors in Computing System, vol. 313 (2001) 36. Garau, M., Slater, M., Vinayagamoorthy, V., Brogni, A., Steed, A., Sasse, M.A.: The Impact of Avatar Realism and Eye Gaze Control on perceived Quality of Communication in a Shared Immersive Virtual Environment. In: Proc. CHI, pp. 309–316. ACM Press, New York (2003) 37. Schmeil, A., Eppler, M., Gubler, M.: An Experimental Comparison of 3D Virtual Environments and Text Chat as Collabration Tools. Electronic Journal of Knowledge Management 7(5), 637–646 (2009) 38. Cerrato, L., Skhiri, M.: A method for the analysis and measurement of communicative head movements in human dialogues. In: AVSP 2003, International Conference on AudioVisual Speech Processing (2003) 39. Stach, T., Gutwin, C., Pinelle, D., Irani, P.: Improving Recognition and Characterization in Groupware with Rich Embodiments. In: Proceedings of CHI 2007, pp. 11–20 (2007)

A Software Architecture for Collaborative Training in Virtual Worlds: F-16 Airplane Engine Maintenance Benjamim Fonseca1 , Hugo Paredes1 , Lt. Jorge Rafael2 , Leonel Morgado1, and Paulo Martins1 1

GECAD/UTAD – University of Trás-os-Montes e Alto Douro, Quinta de Prados, Apartado 1013, Vila Real, Portugal {benjaf,hparedes,leonelm,pmartins}@utad.pt 2 Força Aérea Portuguesa – Base Aérea No 5, Serra de Porto de Urso, Monte Real – Leiria, Portugal [email protected]

Abstract. The maintenance of military aircraft is complex and exhaustive, requiring an accurate training program. This process is not fault tolerant and requires certification renewal periodically. Furthermore, the process involves many professionals and resources, requiring phases of maintenance and verification of the tasks. Cooperation between professionals in the overall process is essential and requires strong team coordination. It is a highly costly process, since aircrafts are scarce and their readiness is essential for missions, and it requires a scheduling effort between all team members and aircrafts. The availability of tools that allow intensive training without aircraft presence is an asset to the maintenance squadrons. Virtual worlds have simulation and collaboration capabilities to implement this process. This paper presents a software architecture developed for training engine maintenance squadrons for certification, using virtual worlds platforms. This architecture is being tested in cooperation with the Portuguese Air Force and an engine maintenance squadron of F-16 aircrafts. Keywords: Cooperation processes, task coordination, virtual worlds, aircraft engine maintenance.

1

Introduction

The maintenance of military aircrafts is a complex, rigorous, delicate and exhaustive process requiring a very accurate training program and a renewal of certification in regular periods of time. The process involves a large number of physical resources and several people, requiring phases of maintenance and verification of the performed tasks. Cooperation between team members in both phases is essential to the success of the overall process. Moreover there is a special concern regarding the coordination of every team task. Concerning the material resources needed, the process involves high costs, since aircrafts are scarce and A.S. Vivacqua, C. Gutwin, and M.R.S. Borges (Eds.): CRIWG 2011, LNCS 6969, pp. 102–109, 2011. c Springer-Verlag Berlin Heidelberg 2011 

A Software Architecture for Collaborative Training in Virtual Worlds

103

their readiness is essential for participation in air force missions. This implies a scheduling effort that requires the simultaneous availability of maintenance crews and aircrafts. In this context, the availability of a software tool which allows a more intensive and frequent training of the team without the physical presence of a real aircraft is an asset to the maintenance squadrons of the Air Force. Virtual worlds have characteristics, including simulation and collaboration capabilities and the 3D environment, which are adequate to implement the process in a virtual environment. This paper presents a software architecture developed for training engine maintenance squadrons in virtual worlds, in order to perform the required preparation for the certifications required regularly in a virtual environment. This architecture is being tested in a real case that involves collaboration with the Portuguese Air Force and an engine maintenance squadron of F-16 aircrafts. The current implementation allows mechanics teams to train the operations of attaching and detaching an engine into the F-16 aircraft, as specified in its technical orders. For every step in the maintenance process, the user is allowed to take the initiative to grab a tool and operate it, but the system ensures that he does it in the right sequence and acting coordinated with other team members. However, the system was designed to allow the future introduction of error margins, lack of coordination, and erroneous procedures, in order to observe the consequences of incorrect operation. The architecture separates the user interface, built in Open Simulator, from the control system, implemented externally to ensure modularity, evolution and platform independence. Section 2 presents some background concepts of virtual worlds and its use for educational, training and simulation purposes. Section 3 describes the methodology used in the requirement analysis and section 4 presents the overall system architecture. Finally, some final remarks are presented in section 5, pointing out some conclusions and future directions.

2

Background

Virtual worlds environments are digital representations of real or imaginary scenarios that intend to simulate reality or compliment it and enable multiple users to be present and communicate with each other [8]. Early virtual environments worlds were based on textual descriptions and interactions, and appeared in 1979 as Multi-User Dungeons (MUD) [5]. Subsequently, the web introduced the concept of the concept evolved into illustrated virtual worlds (known as “graphical MUDs”) and 2D/3D immersive virtual environments worlds. The last decade witnessed the emergence of the latter variety, graphic-intensive 3D multiuser virtual worlds that enable people to conduct several distinct activities, ranging from entertainment and socialization, to professional activities like meetings, marketing campaigns, collaborative learning and education/training [1,4,8,3,6]. This has been particularly noticeable since 2007/2008 [3]. Nakasone [9] presented Astrosim, a collaborative environment built in Second Life, where users can visualize astronomy simulations. Creutzfeldt [2] presents

104

B. Fonseca et al.

the use of virtual worlds for the collaborative training of medical students in cardiopulmonary resuscitation. Other uses for medical education exist, such as [13,11]. Wyld [14] presents other simulated training environments, discussing its importance for several leading-edge organizations and the adequacy of such approach for the digital natives generation. Military training is a critical issue for the success of military operations, either for tactical and fighting activities, as for technical operations such as aircraft piloting or maintenance. Simulation plays an important role here, and its application for technical operations is well-know, with several special purpose simulators that enable a single user to train specific technical or dangerous tasks. There are also some games that are used by multiple users for training fighting and tactical activities [12,10], but the area of multi-user tactical training simulations is in its infancy.

3

Approach

In the Portuguese Air Force (FAP, Portuguese-language acronym), the basic training of the Air Materiel Mechanics is performed at the Air Force Centre for Military and Technical Training. After this training, soldiers are assigned to the units where they receive specific training, as is the case of the Air Base 5, near Monte Real/Leiria, Portugal, where F-16 aircrafts of the FAP are based. In this unit, the training of Air Material Mechanics integrates theoretical stages and also practical phases, which must necessarily be carried out on real components, in order to receive certification for the maintenance of that aircraft engine. Thus, the practical component of the training requires that planes and/or engines involved in it are available for that purpose, which makes this training particularly expensive. For this reason, the adoption of a 3D virtual learning environment for training contributes to increase the efficiency of this training phase with real components, because that enables trainees to perform simulated maintenance without the involvement of physical resources. The aircraft maintenance process involves several phases, and, in order to evaluate the usage of 3D virtual learning environment for training, one phase of the process that reflects the needs of the FAP was chosen. Moreover, from a technical perspective, a phase that reflects the requirements for cooperation between those involved in maintenance, as well as the manipulation of large and expensive objects was selected. Regarding thus, the phase of maintenance chosen, in collaboration with the FAP was the installation of a Pratt & Whitney F100.PW.220/220E engine in a F-16 aircraft. The chosen methodology for the problem analysis was based on the aeronautic training process following, necessarily, a different set of execution tasks, which may be interdependent or not. In aircraft maintenance mechanics, these processes are specified by the manufacturers, through documents called Technical Orders (TO), which describe the execution tasks of the various phases in text and diagrams. Thus, the TO associated with the engine [7] show all actions to complete a particular process in the engine. To facilitate the analysis process, as

A Software Architecture for Collaborative Training in Virtual Worlds

105

a cooperative process, that information was complemented with video recordings and images of the actual processes and transformed into a cooperation script. The developed cooperation script was divided in three main phases: (1) preinstallation, which involves the verification processes: engine conformity; security conditions; toolbox; and availability of the necessary part to engine installation. In this phase, the current TO should be consulted; (2) installation of engine in the aircraft, which includes its transfer for the transportation vehicle to the aircraft following the order defined in the TO; (3) post-installation, where the engine installation is supervised, the toolbox is checked to avoid foreign object damage and the engine is tested. The pre and post installation phases require only the participation of one maintenance mechanic and there is only basic requirements for cooperation in order to, respectively, prepare and finalize the engine installation task. On the other hand, the engine installation phase needs the cooperation of four mechanics in order to perform the tasks defined in the TO. At this point, the main problem is the tasks’ division by the mechanics, since this is not defined in the TO. Therefore it was necessary to observe the teams in real engine installation processes in order to define clearly the tasks of each team member. Thus, the script was divided into four sub-scripts, corresponding to the tasks of each mechanic. Furthermore, common trunk was also included, in which the interdependencies are identified and correlated to the sub-scripts.

4

Architecture

The software architecture developed for the training of engine maintenance squadrons has as main goals: (1) multi-layer: ensuring the independence of the coordination and interaction mechanisms made available by the 3D environment, in order to ensure the separation between the interface and the decision layer of the architecture; (2) evolutive: allowing changes from the technical evolution of the engine maintenance processes, and concerning the changes that are introduced by the vendors in the engine TO; (3) multi-platform: defining a generic model that can be implemented in several virtual worlds. Through the objectives set out for the architecture, in the following subsections its specification is presented and an implementation based on the OpenSim virtual worlds technology is proposed, which is being tested in the maintenance of F-16 aircraft by the FAP. 4.1

Specification

The specification of the architecture was based on the cooperation script developed in a phase of analysis and previously presented. The cooperation script is a text document that outlines the process of the engine installation on the aircraft, and is divided, as above mentioned, in four sub-scripts and a transverse component that specifies the interrelationships between the tasks of each actor in the process. The document identifies 36 tasks that require full alignment between the cell and the engine of the aircraft, as well as their readiness for the

106

B. Fonseca et al.

installation phase. The first 19 execution tasks, summarized in Table 1, refer to the motor coupling to the cell, while the remaining tasks correspond to connecting operations that are performed on the right (6) and left (8) side of the aircraft, and the finalization of the process with connection of the master fuel to the cockpit, initialization of the engine EDU and installation of the fuselage. Table 1. Main execution tasks for engine installation task task TO number description page [7] 1 Installation of the engine mount to raise the engine 2-93 2 Engine raise 2-93 3 Couple engine to the aircraft 2-93 4 Perfect alignment of the upper engine mount with the fuselage rail 2-95 5 Fasten and break of the trailer to the fuselage 2-95 6 Adjustment of the trailer to transfer engine weight 2-95 7 Support the engine on the fuselage rail 2-97 8 Enter the engine in perfect alignment with the fuselage 2-100 9 Align with the trust pin connections 2-100 10 Enter the trust pins using the connection doors 2-100 11 Finish the back 2-100 12 Check perfect alignment of the trust pin with the clamp half 2-101 13 Tighten up the clamp half with a ring (nut) to finish baking 2-101 14 Finish installing the trust pin with an inspection 2-103 15 Check the SEAL, from the air entrance 2-101 16 Remove the trailer 2-111 17 Remove the back engine adapter 2-111 18 Lighten/download support fuselage 2-113 19 Completely remove the trailer

The adaptation of the cooperation script to the specification of the architecture to support the training system went through its translation to UML language. Thus, based on the script, the actors of the system and the main use cases were identified and the main operations were specified using use cases diagrams. The refinement of this specification was performed defining state and activities diagrams for the whole process. However, during the specification process, two subsystems were identified: the interaction and the decision subsystems. It was also found that the script was referring to the interaction subsystem, so there was a need for the specification of the mechanisms of decision and communication between the subsystems. In terms of specification of the decision subsystem, a workflow has been specified based on the TO associated with the engine installation. Regarding the mechanisms of communication and interaction a generic interaction system has been defined, shown in Figure 1. The specification of this generic system defines that when an avatar touches an object in the virtual world an event that is communicated to the decision system is fired. Based on the received event, the

A Software Architecture for Collaborative Training in Virtual Worlds

107

Fig. 1. Generic interaction system

decision system replies to the object sending a command to be executed, which is reflected in the state of the avatar. The architecture is then divided into two logical components: the virtual world and the decision system. The implementation of this system, as well as discussion of technological options for its development, are presented in the next subsection. 4.2

Implementation

The software architecture was implemented as a client-server architecture. The client side is delegated to the virtual world client, and the server side includes the virtual world server and the decision server. The choice for the development of the environment of the virtual world was made based on the requirements of the FAP. The environment should be closed to a certain number of users which are allowed to perform training of engine maintenance, so the virtual world server should be private and the creation of avatars must be controlled. Moreover, the virtual world should allow users to model their own objects and must be programmable in order to implement the generic interaction system previously presented. Based on this requirement the virtual world server chosen was the OpenSimulator, "an open source multiplatform, multi-user 3D application server that can be used to create a virtual worlds" (http://opensimulator.org). In the virtual world was modeled an hangar environment with similar characteristics to the FAP hangar in Air Base 5 (Figure 2). The environment modeling also included the F-16 aircrafts, their engines and all components and materials required for the execution of the engine installation. Each object had a special script associated with the touch event, developed in Linden Scripting Language (LSL), to send information about the environment to the decision server. This communication is performed using HTTP requests and encoding in XML language, allowing a standard communication between the two system modules. The decision server is implemented in ASP.Net platform and is based on the session facade design pattern, defining a single point of entry for the decision module. This module acts based on the implementation of a balanced decision tree that keeps the system state on each step of the engine installation process. Moreover, the system also keeps track on the current state of each object of the

108

B. Fonseca et al.

Fig. 2. Virtual representation of FAP hangar in Air Base 5

Fig. 3. Real engine installation situation at FAP Air Base 5

system in order to infer at each system state what are the available tasks to be performed by the mechanicals in the training process.

5

Final Remarks

This paper presented a software architecture that uses virtual worlds for training F-16 engine maintenance squadrons, which are subject to regular certification. This simulator enables the maintenance crew training to be independent of aircraft availability, facilitating its occurrence on a regular basis to compliment the certification and training under real situation, which must still occur. The study of the technical orders of the PRATT & WHITNEY F100.PW.220/ 220E engine was a crucial step in understanding the requirements of the system in terms of tools and parts manipulation, as well as on the correct sequence of activities to be carried out. The direct observation of the daily work of the F-16 maintenance squadron was also important, as it enabled a better understanding of the team coordination and of a few clues that are described in the TO. The system adopted a multi-level architecture in order to cope with the independence of interaction and control mechanisms and empowering further updates. It was also important to adopt a hierarchical state machine because the whole process encompasses both system and individual object states. The prototype implementation deals currently with the attaching of the F-16 engine to the aircraft without the possibility of errors or failures. The further evolution of the system will contemplate the allowance of errors, the detaching process and the separation in blocks and parts. Another important feature to be introduced is the autonomous operation of avatars, enabling training in the absence of one or more team members. Acknowledgements. We would like to thank the collaboration of Portuguese Air Force, Air Force Base 5 - Monte Real, Leiria, Portugal, for all the support they provided for the development of this project. We would also like to thanks

A Software Architecture for Collaborative Training in Virtual Worlds

109

the undergraduate and graduate students of the University of Trás-os-Montes e Alto Douro, which were involved in this process, for their support in the implementation of the system.

References 1. Adobor, H., Daneshfar, A.: Management simulations: determining their effectiveness. The Journal of Management Development 25(2), 151–168 (2006) 2. Creutzfeldt, J., Hedman, L., Medin, C., Heinrichs, W.L., Felländer-Tsai, L.: Exploring virtual worlds for scenario-based repeated team training of cardiopulmonary resuscitation in medical students. Journal of Medical Internet Research 12(3), e38 (2010); PMID: 20813717 3. Dalgarno, B., Lee, M.J.W., Carlson, L., Gregory, S., Tynan, B.: An australian and new zealand scoping study on the use of 3d immersive virtual worlds in higher education. Australasian Journal of Educational Technology 27(1), 1–15 (2011) 4. Esteves, M., Fonseca, B., Morgado, L., Martins, P.: Improving teaching and learning of computer programming through the use of the second life virtual world. British Journal of Educational Technology (2010) 5. Fanderclai, T.L.: Muds in education: New environments, new pedagogies. Computer-Mediated Communication Magazine 2(1), 8 (1995) 6. Hew, K.F., Cheung, W.S.: Use of three-dimensional (3-d) immersive virtual worlds in k-12 and higher education settings: A review of the research. British Journal of Educational Technology 41(1), 33–55 (2010) 7. Lockheed-Martin-Corp.: TO 1F-16AM-2-70JG-10-21 - Organizational Maintenance - Engine Removal and Installation – Model F100-PW-220/220E – USAF/EPAF Series – F-16/B Mid-Life Update aircraft, Technical Manual Job Guide. Lockheed Martin Corporation, Bethesda, MD, EUA (2009) 8. Morgado, L., Varajao, J., Coelho, D., Rodrigues, C., Sancin, C., Castello, V.: The attributes and advantages of virtual worlds for real world training. The Journal of Virtual Worlds and Education 1(1) (2010) 9. Nakasone, A., Prendinger, H., Holland, S., Hut, P., Makino, J., Miura, K.: Astrosim: Collaborative visualization of an astrophysics simulation in second life. IEEE Comput. Graph. Appl. 29, 69–81 (2009) 10. Orvis, K.A., Moore, J.C., Belanich, J., Murphy, J.S., Horn, D.B.: Are soldiers gamers? videogame usage among soldiers and implications for the effective use of serious videogames for military training. Military Psychology 22(2), 143 (2010) 11. Phillips, J., Berge, Z.L.: Second life for dental education. J. Dent. Educ. 73(11), 1260–1264 (2009) 12. Sotomayor, T.M.: Teaching tactical combat casualty care using the TC3 sim gamebased simulation: a study to measure training effectiveness. Stud. Health Technol. Inform. 154, 176–179 (2010); PMID: 20543293 13. Wiecha, J., Heyden, R., Sternthal, E., Merialdi, M.: Learning in a virtual world: Experience with using second life for medical education. Journal of Medical Internet Research 12(1) (January 2010) 14. Wyld, D.C.: A virtual explosion or snafu is lways better than a real one: Exploring the use of virtual worlds for simulation and training..and developing the leaders of tomorrow. In: Iskander, M., Kapila, V., Karim, M.A. (eds.) EIAT/IETA, pp. 73–78. Springer, Heidelberg (2008)

A Transfer Approach for Facilitation Knowledge in Computer-Supported Collaboration Stefan Werner Knoll1, Jana Schumann2, Thomas Matzdorf2, Ayneta Adege2, Martin Linnemann2, and Graham Horton2 1

Delft University of Technology, Faculty of Technology Policy and Management, Systems Engineering Department, Jaalaan 5, 2628BX Delft, The Netherlands [email protected] 2 University of Magdeburg, Faculty of Computer Science, Department of Simulation and Graphics, Universitaetsplatz 2, 39106 Magdeburg, Germany {jana.schumann,thomas.matzdorf,ayneta.adege, martin.linnemann}@st.ovgu.de, [email protected]

Abstract. Collaboration is an important process for companies to combine the potential and expertise of their employees. Groupware can improve the productivity of collaboration by coordinating activities and improving group communication. Considering the possible complexity of a collaboration process, the faithful appropriation of a groupware technology is fundamental to design predictable and efficient collaboration. This paper presents ongoing research on how to improve technological support for collaboration by formalizing the workflow of a collaboration process into a machine-readable process description. We will present a knowledge transfer approach for the adaptation of a logical process design by an inexperienced user. This approach transfers facilitation knowledge for the selection and configuration of a collaboration process and provides rules for instructional writing to support an inexperienced user in defining clear and explicit instructions. A software application was used to evaluate the knowledge transfer approach in a quasiexperiment with inexperienced participants. Keywords: Groupware, Collaboration, Facilitation, Instructional Design, Knowledge Transfer Approach.

1 Introduction By definition, collaboration describes a group process where participants work together to achieve a shared goal [34]. Over the years, the research focus on collaboration has changed from groups whose members work in the same place to geographically distributed virtual groups. This results from the fact that virtual groups using temporary technological support for collaboration comprise an important structural component of many multinational organizations [29]. The collaboration process and its outcomes are affected by different internal and external factors like the A.S. Vivacqua, C. Gutwin, and M.R.S. Borges (Eds.): CRIWG 2011, LNCS 6969, pp. 110–125, 2011. © Springer-Verlag Berlin Heidelberg 2011

A Transfer Approach for Facilitation Knowledge in Computer-Supported Collaboration

111

characteristics of the individuals, the task, the context, and the technology used [8], [28]. Different theories exist that describe and predict the influence of these factors on group behaviors and performances in relation to group communication [31], group participation [7], [12], [16] and group cohesiveness [13], [15]. From the literature, our conclusion is that most of the influencing factors cannot be generalized for collaboration in general. Depending on the given process characteristics, shared rules, norms and structures can be necessary to handle negative group behaviors and support group performance. Collaboration support can consist of tools, processes and services that support groups during the design and execution of collaboration. Technological support for collaboration is given by groupware technologies, which offer a variety of local and web-based applications to structure collaborative activities and improve group communication [10], [28]. Today, a huge amount of web-based applications exist that provide different functionalities and mechanisms [26]. Research indicates that the faithful appropriation of a groupware technology is fundamental to design predictable and efficient collaboration [9], [11]. However, the adaptation of a groupware technology to a designed collaborative process can lead to a high conceptual load for inexperienced users [4]. The faithful appropriation of a groupware technology in virtual groups is still a challenge in collaboration support. Our research analyzes the use of the Collaboration Engineering approach [4] to improve technological support for collaboration by formalizing the workflow of a collaboration process into a machine-readable process description. A generic groupware technology could use the underlying process logic of the workflow to provide functionalities and knowledge that support inexperienced users during the design and execution of a collaboration process. In earlier work, we developed a modeling language for collaboration, which illustrates different pieces of process information like process activities, process data and process events to define the workflow of a collaboration process [18]. A prototype of a groupware technology was designed that uses this process information to guide a group automatically through a process and to provide interfaces and facilitation instructions that allow the group to execute the defined collaborative activities [19]. By using the modeling language, different logical process designs were developed which could be adapted to different tasks by changing parameters and facilitation instructions. However, this adaptation of a logical design can be difficult for users with less expertise in facilitation, who cannot determine the effect of their change on the effectively of collaboration process. Different studies have analyzed the influence of facilitation on collaboration using technological support [24], [25], [36]. They indicate that expertise of a facilitator is tacit knowledge, which is difficult to transfer to a group of inexperienced users [20]. To capture and share knowledge about collaboration, different approaches can be found such as handbooks for group facilitation [32] or the use of a pattern approach in a technological environment, technological support for agenda building [30] or the computer aided collaboration engineering tool [22]. In this paper, we present a knowledge transfer approach for the adaptation of a logical process design by an inexperienced user. This approach is based on a pattern

112

S.W. Knoll et al.

approach and transfers facilitation knowledge for the selection and configuration of a collaboration process and provides rules for instructional writing to support an inexperienced user in defining clear and explicit instructions. We combined the knowledge transfer approach with our approach of a modeling language for collaboration and developed a software application to support the user in adapting a logical process design. In the following sections, we first provide a short introduction to our research and related work. Then we present our approach as well as its implementation into a software application. We further present the setup and results of our evaluation experiment, before we conclude with a summary and outlook on future work directions.

2 Background Briggs et al. [4] assume that the expertise needed for design and execution of collaboration can be reduced by packing and transferring knowledge about collaboration. They introduce Collaboration Engineering as a facilitation, design and training approach for collaboration work practices that can be executed without ongoing support from collaboration professionals such as facilitators. To reach this goal, Collaboration Engineering classifies collaboration into six key patterns of collaboration: Generate, Reduce, Clarify, Organize, Evaluate and Build Consensus [5]. Each pattern stands for different reusable collaborative activities of a group that can be used over a period of time to move from a defined starting state to an intended end state [21]. The concept of the thinkLet was introduced as a design pattern to collect, create, document and test these collaborative activity of a group [5], [35]. Each thinkLet provides information for its selection and how to create a required pattern of collaboration by using a technology in a defined configuration. According to the given design approach for collaboration processes [23], a collaboration process can be decomposed into a sequence of design pattern thinkLets. Each thinkLet contains knowledge about the used setting and its configuration for a given task as well as a script for each activity in the process that is needed to engender the pattern of collaboration. A designed collaboration process is documented as a paper-based handbook. Tacit knowledge and skills for the use of the handbook will be transferred in a training approach [23]. Research indicates that groups who are trained in using thinkLets can predictably and repeatably engender the pattern of collaboration that a given thinkLet is intended for, even without any facilitation expertise [35]. We believe that Collaboration Engineering represents an interesting approach to support collaboration using technological support. The concept of thinkLets as a design pattern can be used to transfer knowledge about the configuration and use of a specific groupware technology. Currently, a collaboration process design will be documented as a paper-based handbook. To support the faithful appropriation of a specific groupware technology, the handbook needs to be closely connected to the used technology, which reduces the transferability of a collaboration process design for other groupware technologies.

A Transfer Approach for Facilitation Knowledge in Computer-Supported Collaboration

113

2.1 A Modeling Language for Collaboration In earlier work, we analyzed the applicability of the Collaboration Engineering approach to logical process descriptions similar to the concept workflow of Business Process Engineering [14]. The resulting logical model for collaboration illustrates different pieces of process information like process activities, process data and process events to define the workflow of a collaboration process [18]. The modelling language adopts the design pattern thinkLet as a process template that creates one known collaboration pattern. ThinkLets can be combined to different collaboration processes, which can be adapted to a group goal by the configuration of their parameters and activities. The thinkLet script defines a sequence of abstract actions a group of participant must do to achieve an intended collaboration pattern. However, these actions only provide abstract guidelines for facilitation, details facilitation skills must be transferred by a training approach. Research indicates that the quality of facilitation is vital for collaboration success [27], [36]. As a result, we believe that a rule of a thinkLet script should include information about facilitation as a formal instruction entity. Based on the ShannonWeaver Model for communication [33], we introduced a design approach for a reusable formal instruction element called thinXel, which represents an instance of a thinkLet rule. The concept thinXel is originally defined as an atomic facilitator instruction, leading to a response of the participants that has a well-defined function in the context of the group goal [17]. Experimental results have shown that by using thinXels during collaboration, misunderstanding of facilitation instructions by the participants can be reduced [17]. Furthermore, the attention of the participants can kept on the collaboration process. Currently our modeling language for collaboration can be expressed in a graphical or a semantical process notation. The graphical representation combines well-proven modelling constructs with new abstract representations for the concepts of a thinkLet and thinXel to improve the understanding of a collaboration process design [18]. Rules for the composition of these primitive modelling constructs were defined by adapting given workflow patterns [1]. An example of the graphical representation is shown in Figure 1, which shows a reusable process template called Understand Process. The goal of this process template is to provide the participant information about a process, e.g. the specific task of the group process. The activity to read this information is represented by the thinXel Read Information, which receive the data by the data parameter Process Information. A thinXel describes a binary logical design element that represents an atomic reusable activity of a participant that can be executed or aborted by the participant. In this example, the participant can decide if he or she needs more information in order to to understand the process. In this case, the thinXel will be aborted and the sender Need Information will be activated. The resulting signal of the sender will be forwarded by the element Start Process to initiate another process template, e.g. a process to discuss possible questions about the process.

114

S.W. Knoll et al.

Fig. 1. Graphical representation of the collaboration modeling language

The same process template is shown in Figure 2 in a semantic notation using Extensible Markup Language (XML). Here, the thinXel Read Information is described by the XML tag activity and contains besides a short description a XML tag parameter, which defines a connection between the thinXel and the data parameter Process Information. The definition of this data parameter is defined in a superior tag. The semantical representation of a thinXel further includes a configuration block, which comprises formal information for the configuration combined with positive and negative examples for possible facilitation instructions. We will describe in Section 3.2 how we use this configuration block to provide knowledge for inexperienced users in order to adapt a collaboration process. Our first application of the collaboration modelling language was a prototype of a generic groupware technology that links a group via the Internet and implements the activities of a collaboration process via a website [19]. We use the information about the configuration of a thinXel to provide a predefined web page that allows the participant to execute or abort the intended activity. Currently, the prototype provides no support for the configuration of the logical process model by inexperienced user. However, we believe that knowledge about facilitation can be documented and provided by the semantic process notation. For this reason, we analyzed the applicability of different approaches for instructional design to capture and transfer tacit knowledge of collaboration experts.

A Transfer Approach for Facilitation Knowledge in Computer-Supported Collaboration

115

<processplan id="understandprocess" name="Understand Process"> <description> In this phase the participants will read the process information <parameter id="processinformation" name="Process Information" type="string"> <description>...defines the process information for the first phase Please define in short sentences the task of the process <positive-example> In the next process we want to solve the task ... This task results from the situation ... It is necessary to solve this task because ... The task is ... ... <description> ... in this step the participants will read the process information. <parameter link = ‘processinformation’/> Please define a short instruction for the participants: <positive-example> Please read the process information. Click the button ‘OK’ to continue. To get more information about the process click the button ‘More Information’ Read Information ...

Fig. 2. Semantic representation of the collaboration modeling language

116

S.W. Knoll et al.

3 How to Transfer Facilitation Knowledge Using a Semantic Process Notation In this section we will introduce our approach to transfer knowledge and skills for the configuration and execution of a collaborative process. According to Clawson et al. [6], different dimensions can be defined to describe the role of the facilitator in a computer-supported meeting. Our research concentrates on the transfer of knowledge that is needed to appropriately select a process that fits to a collaboration task and the intended outcome, to provide instructions that encourage the group to participate, to define clear and explicit instructions and information for the group and to explain the group how to use an selected technology to engender the intended process outcome. 3.1 Transferring Facilitation Knowledge for the Selection of a Collaboration Process Similar to Briggs et al. [4], we agree that knowledge about collaboration can be packed and transferred by using a pattern approach like the design pattern thinkLet. However, the concept of a thinkLet only provides formal guidelines for the execution of a collaboration process documented in a paper-based handbook [23]. According to our modeling language for collaboration, we think that this knowledge should also be described by the semantical representation. Thereby we distinguish between a logical and a physical design of a collaboration process. We define a logical process design as a process template that can be used to engender an abstract goal for a defined set of tasks and group characteristics. Including activities will be represented in an abstract description. A collaboration engineer can use a logical design to define processes independent from a specific task, which can be shared between different organizations via a process database. A physical process design is defined as a collaboration process for a specific task and group characteristics. In this process design, detailed descriptions of information about the task and needed instruction for the collaboration activities are defined. Therefore, an organization configures a logical process design for the given task by adapting the parameter and instructions of the process template. Resulting from this distinction between process designs, the semantic representation needs to provide knowledge for the selection and adaptation of a collaboration process template for a certain context, group constellation and task. We adopted the pattern approach to provide information for the selection of collaboration process. Therefore, the semantical notation of a process template uses XML tags to capture and provide information. e.g. the name of a collaborative process by the tag name. To describe the situation a process design is intended to use, we used a tag called context, that contains the elements: purpose which captures the core of the process; input to describe possible needed input, e.g. a task or a list of contributions; output to describe the intended outcome of a process, e.g. ideas who solve a given task or a list of items sorted by categories. The tag group defines the group characteristic by the elements: size for the intended group size and roles for the needed skills of the group participants.

A Transfer Approach for Facilitation Knowledge in Computer-Supported Collaboration

117

3.2 Transferring Facilitation Knowledge for the Configuration of a Collaboration Process To support the adaptation of a logical process template to a physical design, parameter and facilitation instructions need to be configured for given task and group characteristics. The facilitator will need to define clear and explicit instructions and information for the group. The purpose of this instructional writing is to give instructions to the participants, which lead to the activities that have a well-defined function in the context of the group goal. These instructions should only contain those pieces of information that must be conveyed to the participants to perform the intended activities. We found guidelines for instructional writing in the research field of Controlled Natural Languages. Controlled Languages are used for the production of technical documentation or user-documentation [2], which uses a defined vocabulary and grammatical constructions that are also found in a natural language such as English. By analyzing the controlled language Simplified English [3] in regard to instructional writing, we identified twelve rules for instructional writing. 01. Give the necessary background information before the instruction. 02. Use a numbered list, if you want to present background information in a specific order. Otherwise use a bulleted list when the order is not important. 03. Use a sequence of activities, if you want to describe a process in the background information. A sequence of activities (A ' B ' C) is common when all participants perceive that activity C follows activity B and that activity B follows activity A. 04. Use words that any participant of a group understands. 05. Write in a friendly manner. 06. Address the participants of a group by using "you" or "your". 07. Describe only one atomic activity per instruction. Atomic activities are for example: read, write, select, think, draw or put. 08. Make an instruction as specific as possible. 09. Keep an instruction as short as possible. 10. Specify what the participant has to do when the intended task of an instruction is completed. If a reader asks, "Now what?", the instruction is not complete. 11. Use the active voice to define an instruction. 12. Write an instruction as a request using the polite word "please" before the verb. These rules were documented as guidelines for instruction-writing using the following structure: Rule 7: Describe only one atomic activity per instruction. Atomic activities are for example: read, write, select, think, draw or put. Description: If you put more than one activity into an instruction, the instruction will overwhelm the participant. In this case the participant can misinterpret an instruction. Therefore, the practitioner must present one activity per instruction at a time. That will lead the participant to complete one activity at a time.

118

S.W. Knoll et al.

WRITE: 1. Please select an issue frrom the cluster. 2. Please write down an id dea that you associate with the selected issue. DON'T WRITE: Please select an issue frrom the cluster and then write down an idea that yyou associate with the selected d issue. During the adaptation of a logical process template to a physical design, an inexperienced user can usse these guidelines to configure process parameters and facilitation instructions of the t semantical notation. To support the user, the semanntic notation of a parameter an nd activity captures and provides information in a XM ML schema for its configuration n. We use the XML tag description to provide informattion about the parameter and activity a in relation to the process design. The XML tag configure is used to proviide information for the configuration of a parameterr or activity (see Figure 2). The T XML tag config:instruction is used by the proccess designer to instruct the useer how to configure the parameter or activity. Further, the designer can provide rulees (XML tag config:rule) with positive and negattive examples (XML tag positivve-example and XML tag negative-example) to support the inexperienced user.

Fig. 3. Interface of a softwaare prototype for the configuration of a collaboration proccess template

A Transfer Approach for Facilitation Knowledge in Computer-Supported Collaboration

119

We used the resulting concepts to develop a software prototype (shown in Figure 3) that supports the user during the adaptation of a collaboration process template for a certain context, group constellation and task. This prototype uses the Extensible Markup Language to import a logical process design. By using the XML tags, the application provides a navigation tool (Figure 3 / Area A), which allows the user to change the focus between the different phases of a collaboration process. Parameter and instruction of a selected process phase can be adapted in the configuration tool (Figure 3 / Area B). This tool provides for each parameter and instruction a short description about the element and its relation to the collaboration process. By using the textboxes, the user can adapt the parameter and instructions of a process design. During this configuration, the prototype supports the user by two functionalities. A tooltip can be used to provide predefined positive and negative examples for the configuration (Figure 3 / Area C). Furthermore, the user can activate an information window that shows a summarized list of the defined guidelines for instructional writing (Figure 3 / Area D). An adapted process design can be exported into a semantic notation that can be used by a groupware technology to execute the collaboration process. In the next section we will evaluate the presented pattern approach for facilitation knowledge transfer with expert interviews and a case study with inexperienced facilitators.

4 Evaluation of the Facilitation Knowledge Transfer Approach We designed two experiments to test our facilitation knowledge transfer approach. Expert interviews were used to verify the defined rules for instructional writing. Furthermore a quasi-experiment was designed to test our assumption, that the given information of the logical process design can be used to support an inexperienced user during the adaptation of a logical to a physical process design. 4.1 Expert Interviews for Instructional Writing With the expert interviews, we wanted to verify the defined rules for instructional writing by experienced facilitators. The goal of this part of the experiment was to gain personal experience of each individual expert to merge their knowledge and therefore confirm our approach described in Section 3.2. We interviewed seven experts, four of them were male and three were female. The interview technique was chosen, because the experts were supposed to freely share their knowledge and opinion about the rules without constraints. Their experience with planning and executing group processes amounts between four to ten years. The amount of accomplished group processes between 20 and 200 processes, with a group size from three up to 150 participants. The group processes task differed between small meetings, innovation processes in companies, coaching of specific techniques, briefings with customers, conferences, and brainstorming sessions. The experts had expertise with homogeneous and mixed groups including students, employees, managers, engineers, and designers.

120

S.W. Knoll et al.

In a first phase, we asked general questions about their personal experience in designing a collaboration process and how to formulate process information and instructions. Almost all experts gave similar answers and reasons for the main steps of their process design, e.g. "Always explain the goal before you start with process instructions". They only differed in questions of detail. All of them used a structured and predetermined top-down approach for a collaboration process design. One expert offered a completely different process design with more degrees of freedom for the participants and no agenda. However, both possibilities were supposed to be successful regarding the goal of the group process. We used the knowledge of the experienced facilitators in order to design our experiment. In a second phase, we presented our rules for instructional and descriptive writing and asked for feedback. Every expert had one or two rules which he or she described as not necessary for instructional design, for example "Address the reader using 'you' or 'your'". These differences occur because every expert has his or her own style during a collaborative process. We tried to get out the matching rules of the majority of all experts. In conclusion the most experts agreed that our rules are useful and necessary for the instructional design, which can be used during the adaptation of a logical to a physical process design. The list of rules matches the opinion of our experts. 4.2 Quasi-experiment with Inexperienced Users to Verify the Knowledge Transfer Approach In a quasi-experiment, we tested our assumption that the approach transfers tacit knowledge that supports inexperienced users during the adaptation of a logical to a physical process design from the point of view of an inexperienced user. We designed an experiment that implements a configuration process of a process template using our software application. For this experiment, a professional facilitator developed three logical process designs using the graphical and semantical notation of our modeling language for collaboration. Each of the resulting process templates combine thinkLets of different collaboration patterns, e.g. thinkLets for the generation of concepts, the organization of concepts, and consensus building. Two of the logical process designs define a process for ideation and one is intended to structure a meeting process. Each process design provides information and example how to adapt a logical design for a specific task. Scenarios. For the configuration of the logical process designs we used three scenarios. In the first scenario a process design for ideation should be adapted for the task to generate event ideas for a university. The second scenario uses also a process design for ideation but uses the task to generate software ideas for a mobile device. The last scenario uses the logical design for a meeting process of four students with the task to prepare an event for a university. Participants. Thirty-six students from a university participated individually in this case study, 15 women and 21 men with different cultural background (Europe, Asia, North America and Africa). The participants' age ranged from 20 to 34 years. They had different experience with collaborative processes. Thirty-one had taken part in a group process before. Twenty of them had further experience with ideation techniques. Eleven participants had experience in facilitating a group process.

A Transfer Approach for Facillitation Knowledge in Computer-Supported Collaboration

121

Experimental Design. Thee experiment was split into two phases. Upon arrival, the participants were trained in using the set of rules for instructional writing. T The bjective of each rule. We demonstrate how to designn an facilitator provided the ob instruction or information using these rules and let the participants generate soome instruction on their own. A facilitator gave feedback to these instructions. In a second phase, the participants used the software application for the adaptattion of the logical process designs in different specific scenarios. The participants receiived was an introduction to the functionality of the software application. Each participant w given one out of three logical process designs. They were requested to configure the o one of the given scenarios. During this adaptation, the logical design in regard to software application only provided p the rules for instructional writing and the geneeral information and example defined d by the logical design. No verbal communicattion was allowed between the paarticipants during this phase. Questionnaires were useed to collect the expertise of the participants with grooup processes as well as theiir experience with the configuration process using the software application. Herre, closed questions were important in order to get quantitative analysis to support s our hypothesis. Furthermore we compared the resulting physical designs with w a process design that was adapted by an experiennced facilitator in order to get a qualitative q analysis.

Fig. 4. Ressults of the evaluation of the instructional rules

Results. An analysis of thee questionnaires in relation to the concept of instructioonal rules (see Figure 4) shows that most participants understood the rules for instructtion writing. However, it seemss that it was not easy for everybody to follow these ruules during the configuration pro ocess. Some participants did not know what they had too do all the time. As a result, no ot everyone was able to create a functional group process. Most of the participants preferred p the given structure of the logical design. T They

122

S.W. Knoll et al.

indicate that the rules for in nstructional writing and the examples provided helped thhem during the configuration process. Participants who have problems during this adaptation, claimed that thee generic presentation of process parameters was not eeasy to understand in a certain co ontext. In conclusion we can say that the instructional ruules can be used to support paarticipants during the configuration, but that the way we presented the parameters was w not as successful as expected. An easier way to pressent the process information stilll has to be found. In relation to the processs understanding of the participants, the analysis shows tthat most participants understo ood the goal of the collaborative process. The softw ware application helped them to get a good overview about the process. Most participaants he adaptation of the collaboration process. They creaated have no problems with th functional processes which h they would also use in a real life scenario (see Figuree 5). Most participants preferred d the step by step guidance, but 16 participants would aalso like to have more degrees of freedom during the configuration process. T Two with participants disliked the steep by step guidance. One of them was more advanced w the techniques used and grroup processes in general. Because of that he would hhave been able to create a group process with less guidance and more of his own creativvity. understood the process and the involved activities. T That The other participant misu might be the reason why he did not like the guidance. In conclusion we can say tthat most participants were ablee to understand the group process and the technique. But there are still a few particip pants who were not able to create a decent group proccess despite of all guidance. It is necessary that the process design is able to respondd to people who with more advaanced abilities.

Fig. 5. Resultts of the evaluation of the process comprehension

Furthermore, we compaared the resulting physical designs with a process dessign that was adapted by an exp perienced facilitator. The analysis shows a high similaarity for most part of the adapted physical designs. However we found also differences in

A Transfer Approach for Facilitation Knowledge in Computer-Supported Collaboration

123

the process designs. In contrast to participants who invested a large effort in following the instructions, some participants just copied the positive examples. As a result, we were not able to create a situation where all or most participants produce a group process of the same level of quality. However, there seems to be a relation between the instruction design and the cultural background, the general background knowledge and the motivation of a participant. Participants with medium or higher experience with collaborative processes and the used techniques were able to create better group processes and needed less time to accomplish the task. These participants liked the concept of negative and positive examples. In context of the rules for instructional writing, the resulting process instructions fulfill some rules more often than others. It might be helpful to underline those rules in a training to make clear how important they are.

5 Discussion and Conclusions This paper introduced a knowledge transfer approach for the adaptation of a logical process design by an inexperienced user. The approach transfers facilitation knowledge for the selection and configuration of a collaboration process and provides rules for instructional writing to support an inexperienced user in defining clear and explicit instructions. The result of the expert interviews described in Section 4.1 supports our assumption that the rules for instructional writing transfer tacit knowledge of experienced facilitators for the adaptation of a collaboration process from a facilitation expert's point of view. A software application was used to evaluate the knowledge transfer approach in a quasi-experiment with inexperienced participants. This experiment verified that the knowledge transfer approach is applicable to transfer tacit knowledge of experienced facilitators to inexperienced users from an inexperienced user's point of view. Furthermore it verified the use of the transfer approach for the adaptation of a logical to a physical process design. The results suggest support for our assumptions, but we still found differences in the quality of the resulting process designs. So we can say that it provides necessary information to support inexperienced users, but that this information is not sufficient. A number of limitations exist in this experiment. We used three different group processes to provide a basis for the experiment (two processes focus on ideation; one defines a meeting process), which limited the results to those group processes. Limitation is also given by the use of a small number of students in a laboratory environment. A larger sample size should reduce the effect of possible outliers in the measured data on the result. Furthermore the lab experiment should be tested in a real-world environment in order to approve the results in this work. The introduced knowledge transfer approach provides interesting concepts that can be used by a machine-readable process description for collaboration. However, research is needed to extend and verify our approach. We considered a large number of instruction rules, but our approach cannot be seen as a complete set of instruction rules. Furthermore, a better process overview should be considered to overcome the difficulty that some people did not understand the group process. The step-by-step guidance is preferred by inexperienced users. But as soon as people become more

124

S.W. Knoll et al.

experienced they want more degrees of freedom to bring in their own creativity and style. Then they do not want to follow a strict group process construct. A balance has to be found to bridge the needs from very inexperienced facilitators to more experienced facilitators. The first step of bridging the needs could be to enable the user to fade the rules in and out. In the future, perhaps less information should be shown the more experienced the user is, for example, a three-step instruction could be merged to a single-step instruction.

References 1. van der Aalst, W.M.P., ter Hofstede, A.H.M., Kiepuszewski, B., Barros, A.P.: Workflow patterns. Distributed and Parallel Databases 14, 5–51 (2003) 2. Adriaens, G., Schreors, D.: From COGRAM to ALCOGRAM: Toward a controlled english grammar checker. In: Proceedings of the 14th Conference on Computational Linguistics (1992) 3. Aecma simplified english. Technical Report PSC-85-16598, The European Association of Aerospace industries, Bruxelles (1995) 4. Briggs, R.O., de Vreede, G.-J., Nunamaker Jr., J.F.: Collaboration engineering with thinklets to pursue sustained success with group support systems. Journal of Management Information Systems 19(4), 31–64 (2003) 5. Briggs, R.O., Kolfschoten, G.L., de Vreede, G.-J., Dean, D.L.: Defining key concepts for collaboration engineering. In: Proceedings of the Americas Conference on Information Systems (AMCIS), pp. 121–128 (2006) 6. Clawson, V.K., Bostrom, R.P., Anson, R.: The role of the facilitator in computersupported meetings. Small Group Research 24(4), 547–565 (1993) 7. Csikszentmihalyi, M.: Creativity: Flow and the Psychology of Discovery and Invention. Harper Collins Publishers, New York (1997) 8. Dennis, A.R., George, J.F., Jessup, L.M., Nunamaker Jr., J.F., Vogel, D.R.: Information technology to support electronic meetings. MIS Quarterly 12(4), 591–624 (1988) 9. Dennis, A.R., Wixom, B.H., Vandenberg, R.J.: Understanding fit and appropriation effects in group support systems via meta-analysis. Management Information Systems 25(2), 167– 193 (2001) 10. DeSanctis, G., Gallupe, R.B.: A foundation for the study of group decision support systems. Management Science 33(5), 589–609 (1987) 11. DeSanctis, G., Poole, M.S.: Capturing the complexity in advanced technology use: adaptive structuration theory. Organization Science 5(2), 121–147 (1994) 12. Diehl, M., Stroebe, W.: Productivity loss in idea-generating groups: tracking down the blocking effect. Journal of Personality and Social Psychology 61(3), 392–403 (1991) 13. Edmondson, A.: Psychological safety and learning behavior in work teams. Administrative Science Quarterly 44(2), 350–383 (1999) 14. Hollingshead, A.B.: The Workflow Reference Model, Workflow Management Coalition (1995) 15. Janis, I.: Groupthink. Houghton-Mifflin, Boston (1982) 16. Karau, S.J., Williams, K.D.: Social loafing: A meta-analytic review and theoretical integration. Journal of Personality and Social Psychology 65(4), 681–706 (1993) 17. Knoll, S.W., Chelvier, R., Horton, G.: Formalised online creativity using thinXels. In: Proceedings of the 10th European Conference on Creativity and Innovation (2007)

A Transfer Approach for Facilitation Knowledge in Computer-Supported Collaboration

125

18. Knoll, S.W., Hoerning, M., Horton, G.: A design approach for a universal group support system using thinkLets and thinXels. In: Proceedings of the Group Decision and Negotiation Meeting (2008) 19. Knoll, S.W., Hoerning, M., Horton, G.: Applying a thinkLet- and thinXel-based group process modeling language: A prototype of a universal group support system. In: Proceedings of the 42nd Hawaii International Conference on System Sciences (2009) 20. Kolfschoten, G.L., den Hengst-Bruggeling, M., de Vreede, G.-J.: Issues in the design of facilitated collaboration processes. Group Decision and Negotiation 16(4), 347–361 (2007) 21. Kolfschoten, G.L., Santanen, E.L.: Reconceptualizing generate thinklets: The role of the modifier. In: Proceedings of the 40th Hawaii International Conference on System Sciences (2007) 22. Kolfschoten, G.L., de Vreede, G.-J., Briggs, R.O.: Computer aided pattern-based collaboration process design: A computer aided collaboration engineering tool. In: Haake, J.M., Ochoa, S.F., Cechich, A. (eds.) CRIWG 2007. LNCS, vol. 4715, pp. 165–172. Springer, Heidelberg (2007) 23. Kolfschoten, G.L., de Vreede, G.-J.: A design approach for collaboration processes: A multimethod design science study in collaboration engineering. Journal of Management Information Systems 26(1), 225–256 (2009) 24. Kolfschoten, G.L., Lee, C.: Self-guiding group support systems: Can groups use GSS without support? In: Proceedings of the 43rd Hawaii International Conference on System Sciences (2010) 25. Macaulay, L.A., Alabdulkarim, A.: Facilitation of e-meetings: State-of-the art review. In: Proceedings of the IEEE International Conference on E-Technology, E-Commerce and EService, pp. 728–735 (2005) 26. Mittlemann, D.D., Briggs, R.O., Murphy, J., Davis, A.: Collaboration technology, computer-based collaboration-support products. In: Briggs, R.O., Antunes, P., de Vreede, G.-J., Read, A.S. (eds.) Groupware: Design, Implementation, and Use, pp. 305–317. Springer, Heidelberg (2008) 27. Niederman, F., Beise, C.M., Beranek, P.M.: Facilitation issues in distributed group support systems. In: Proceedings of the 1993 Conference on Computer Personnel Research, SIGCPR 1993, pp. 299–312 (1993) 28. Nunamaker Jr., J.F., Dennis, A.R., Valacich, J.S., Vogel, D., George, J.F.: Electronic meeting systems to support group work. Communications of the ACM 34(7), 40–61 (1991) 29. Nunamaker Jr., J.F., Reinig, B.A., Briggs, R.O.: Principles for effective virtual teamwork. Communications of the ACM 52(4), 113–117 (2009) 30. Pedro, A., Ho, P.,, T.: Carrico, Luis.: A gdss agenda builder for inexperienced facilitators. In: Proceedings of the 10th EuroGDSS Workshop (1999) 31. Poole, M.S., Hollingshead, A.B.: Theories of Small Groups. Sage Publications, Thousand Oaks (2005) 32. Schumann, S.: The IAF Handbook of Group Facilitation: Best Practices from the Leading Organization in Facilitation, Jossey-Bass, San Francisco (2005) 33. Shannon, C.E.A.: Mathematical Theory of Communication. Bell System Technical Journal 27, 379–423, 623–656 (1948) 34. Terveen, L.G.: Overview of human-computer collaboration. Knowledge-Based Systems 8(2-3), 67–81 (1995) 35. de Vreede, G.-J., Briggs, R.O.: Collaboration engineering: Designing repeatable processes for high-value collaborative tasks. In: Proceedings of the 38th Hawaii International Conference on System Sciences (2005) 36. Wong, Z., Aiken, M.: Automated facilitation of electronic meetings. Information & Management 41(2), 125–134 (2003)

Beyond GSS: Fitting Collaboration Technology to a Given Work Practice Tanja Buttler1, Jordan Janeiro1, Stephan Lukosch1, and Robert O. Briggs2 1

Delft University of Technology, Faculty of Technology Policy and Management, Section Systems Engineering, P.O. box 5015, 2600 GA Delft, The Netherlands {t.buttler,j.janeiro,s.g.lukosch}@tudelft.nl 2 MIS Department, San Diego State University, California, USA [email protected]

Abstract. Collaboration has become a critical success factor for many organizations. Collaboration is however not without challenges. Free riding, dominance, group think or hidden agendas are but a few phenomena in group work that make it a non straight effort. In addition, tools and technology that supports collaboration exists in a variety of shapes from complex group support systems (GSS) to simple boxes with cards and pencils. GSS often only offer a limited set of tools with a limited set of configurable features. Organizations, however, face an unlimited variety of problems with an unlimited variety of structures. In this article, we present a component-based groupware approach that goes beyond current GSS and allows collaboration engineers to fit the collaboration technology to a given work practice. We illustrate the feasibility of our approach by reporting on first experiences on supporting a requirements engineering work practice. Keywords: Collaboration Engineering, Component-Based Groupware, Collaboration Support Systems (CSS), Group Support Systems (GSS).

1 Introduction In the knowledge economy, many organizations now face challenges of such complexity that no one individual has the skills, information, and resources to find solutions alone. Collaboration has therefore become a critical success factor for many organizations. We define collaboration as joint effort toward a group goal. With its benefits, however, collaboration brings its own set of challenges. Group members struggle, for example, to create common understanding [1], align personal goals with those of other actors [2], think creatively to define and solve problems [3] while working to overcome barriers such as production blocking [4], evaluation apprehension [5], and groupthink [6]. Teams often find it hard to devise for themselves work practices that facilitate interaction in such a way that effective collaboration becomes possible [7]. A.S. Vivacqua, C. Gutwin, and M.R.S. Borges (Eds.): CRIWG 2011, LNCS 6969, pp. 126–141, 2011. © Springer-Verlag Berlin Heidelberg 2011

Beyond GSS: Fitting Collaboration Technology to a Given Work Practice

127

Solutions to collaboration challenges can be counter-intuitive, so groups often lack the expertise to overcome the challenges of collaboration by themselves [8] and some groups seek out collaboration support to improve the efficiency and effectiveness of their work [9]. Collaboration support consists of tools, processes and services that assist groups in their joint effort. Many teams rely on professional facilitators to design and conduct high-value or high-risk tasks [10, 11]. A facilitator creates a dynamic process that involves managing relationships between people, tasks, and technology, as well as structuring tasks and contributing to the effective accomplishment of the outcome of the collaboration [12]. On the technology side, early research showed that, under certain circumstances, industry, military, and academic groups who use group support systems (GSS) were able to realize substantial gains in productivity [9, 13]. Tasks supported by GSS include idea generation, strategic planning, and decision making [13]. A GSS is a suite of tools for focusing and structuring group deliberation, while reducing the cognitive costs of communication and information access among teams making a joint cognitive effort towards a goal [14]. Despite their demonstrated benefits, however, GSS have been slow to transition to the workplace. Even when they are available, GSS tools are often used only sporadically. Part of the problem is that a GSS can only offer a limited set of tools with a limited set of configurable features. Organizations, however, face an unlimited variety of problems with an unlimited variety of structures. It can be difficult to fit to a given collaborative process to a given GSS platform [15]. A general purpose GSS, for example, might provide internal auditors with tools for identifying and organizing risks, but might not support attaching financial data to each identified risk. A GSS might support humanitarian disaster relief planning, but might not support the association of real-time geospatial data with identified resources. Another part of the problem is the complexity of collaboration itself. Briggs et al. [16], for example, propose a seven-layer model of collaboration, each layer of which addresses collaboration at a different level of abstraction. For each layer there are myriad phenomena, theories, design concerns, modelling conventions, and design patterns pertaining to outcomes of interest to groups. Effective, predictable collaboration requires understandings at all seven layers, but collaboration tools like GSS provide only one of the layers. The potential benefits of GSS, therefore, are often realized only in groups led by a collaboration expert like a professional facilitator who can guide a group through a collaborative process. It can therefore be difficult for organizations to provide their teams with affordable and accessible collaboration support to help them accomplish their goals efficiently and effectively. Researchers in the emerging field of collaboration engineering are working to address these barriers. Collaboration engineering (CE) is an approach to designing and deploying collaborative work practices for high-value tasks, and transferring them to practitioners to execute for themselves without ongoing intervention from collaboration experts [17]. In CE, a practitioner is a person who may be a domain expert in her own field of work, but who may lack collaboration expertise. CE researchers are seeking ways to package collaboration expertise with collaboration technology in a form that practitioners could reuse without training on either the tools or the collaboration techniques [8]. To address this challenge it is useful to support collaboration engineers in designing a collaborative work practice, and then use that

128

T. Buttler et al.

design to develop a collaborative software application tailored specifically for that task, with the right tools, communication channels, data, and most importantly, collaboration guidance for each activity. A general approach to create software applications that can be fitted to a collaborative process is to use component-based groupware. Component-based groupware is an approach where software engineers analyze existing groupware, extract common features and services present in this groupware (e.g. chat services or voting mechanisms) and encapsulate these services and features in components. These components can then be assembled into new groupware applications. Therefore, we propose to use a component-based approach to GSS in order to create a basis for a system that allows us to create collaborative applications that fit a process. In the following, we take a closer look at component-based groupware. We then analyze the requirements for a GSS that allows for adapting a collaborative software application to a process. After comparing our requirements with the current state-ofthe-art we introduce our approach for an open and extensible GSS. Before concluding the paper, we report on experiences when extending and appropriating a collaborative requirements engineering process.

2 Component-Based Groupware Appropriating GSSs to better represent a process is a complex task, mainly because such systems have to be flexible enough to be personalized according the process. One way to achieve the flexibility is to implement these systems following the component-based software development concepts so that they can be more suitable to different processes’ parts. Currently, the development of collaborative systems is still difficult, because it still requires well-prepared programmers that are able to handle various technological challenges, like graphics rendering, distributed algorithms and session management. This situation hinders the potential of programmers, forcing them to deal with such technological issues instead of applying their efforts to conceive creative solutions to support collaboration [18]. Over the last years, the computer support collaborative work community identified that collaboration support systems offer a set of basic services and follow recurring design guidelines [19]. A common set of these services can be represented by: e-mail, discussion lists, forum, instant messaging and agenda [20]. Springer et al. [21] extended such common set of tools and also included additional ones focusing in mobile group collaboration, as: geo-location, media sharing, collaborative drawing, group management and multimedia tagging. The community of software engineers supporting groupware systems realized that the definition of those services as software components, introduced by [22], would just generate benefits for groupware development, because of the concepts of reuse and composition. As many groupware services can be easily identified, software engineers can define those services just once as components (reuse) and assemble them (composition) to create new groupware applications, instead of developing them from scratch. Such approach can be more productive because software engineers can

Beyond GSS: Fitting Collaboration Technology to a Given Work Practice

129

concentrate their efforts to design new sorts of applications with existing components and not designing and implementing new components. Such benefits of the component-based approach lead to a new generation of groupware systems: DACIA [23], a component-based platform to support mobile groupware applications; CoCoWare [24], a component-based platform to develop groupware applications using open products (chat) and proprietary products (Microsoft NetMeeting); and TeamComponents [25], a general-purpose componentbased approach to develop either single-user or groupware applications, through its environment (DreamTeam). All of these approaches have a common characteristic; they are highly extensible platforms that can naturally evolve through the development of new components, addressing the lack of extensibility and openness in current groupware systems. Besides technological aspects, following a component-based approach to develop groupware systems has also an economic impact; assembling components to build an application for a specific collaborative process saves development time, in comparison to a manual approach that requires the development of the application from scratch. Therefore, it is a basic requirement to follow a component-based approach to develop groupware applications.

3 Requirements Analysis In the following we elaborate on the requirements a system has to fulfill in order to allow collaboration engineers to (1) package collaborative expertise with collaboration technology and to (2) configure collaborative software applications that actually fit a specific process. We use the following scenario to illustrate these requirements. The scenario describes the beginning of a collaborative process that should be supported by a collaborative software application. Groups of 20-50 stakeholders must come together to negotiate system requirements for a large-scale web-based application. 1. In their first activity, groups will use a shared-outlining component to review, comment on, and revise a taxonomy of system requirements to assure that all key concerns will be addressed in the requirements negotiation. 2. In the next activity they will use a brainstorming component to generate a collection of possible requirements. 3. In a third activity, they will use an idea-organizing component to clarify the requirements, to reduce them to a set they deem worthy of further attention, and to organize them under the categories of their requirements taxonomy. The group is guided through the process by a practitioner with little experience in facilitation. In order to support this scenario, we need to support collaboration engineers in designing a collaborative process, and in designing and developing a collaborative

130

T. Buttler et al.

software application tailored specifically for that process. In the scenario we have several activities supported by different components. These components have to be assembled into a working collaborative software application that fully supports a given collaborative process. Since this is by no means a simple task our system should support it: (R1) The system should support collaboration engineers (who have no expertise in programming) in the design and configuration of collaborative software applications (supporting a collaborative process) by allowing re-using of existing components. Furthermore, in order to configure collaborative software applications that actually fit a specific process, we have to support collaboration engineers in fine-tuning the collaborative software application: (R2) Component interfaces should be configurable and adaptable to support the requirements of many different activities (e.g. layout, formats, prompts for users, help texts) and the system needs to support collaboration engineers with configuring the components. The different components in the scenario use a shared data set. For example, the ideas generated in the second activity are reduced and organized in the third activity. Therefore, the components need to be able to share and exchange data: (R3) The components should be able to share and exchange data. No matter how many capabilities a system provides, it is likely that there will be work practices that require domain-specific capabilities the system does not yet support, e.g. specialized editors for different modeling languages such as UML or BPMN. A similar issue occurs when we consider advancements in GSS and facilitation research. A collaboration engineer might want to integrate support for such advancements into the process, e.g. by priming users on brainstorming topics in the days preceding the actual session. Current GSS systems, however, focus on supporting workshops. A phase preceding these workshops is not supported at all. Since we cannot predict all the support that is needed, the set of components has to be extensible, so that new components can be introduced when needed: (R4) The set of components should be extensible by software developers. However, when extending the set of components we have to consider that it requires an order-of-magnitude more code to create collaborative capabilities than it does to create single-user capabilities because, in a collaborative tool, many users may execute multiple, possibly conflicting actions on the same object simultaneously, and the system must be able to resolve all those actions in a way that all users can comprehend. It can therefore take several person-years of effort to create a single GSS-like tool. Group needs, however, may evolve in days or weeks. To support groups over time, then, it must be possible to shorten development cycles for collaborative capabilities so new capabilities could be created in days or weeks. (R5) The system should provide basic services to enable collaboration. Tightly related to the extension of the system is its openness. Researchers could use the system as a platform for experiments (e.g. when comparing voting components);

Beyond GSS: Fitting Collaboration Technology to a Given Work Practice

131

if the rest of the collaborative software application and its documentation and provided guidance stay the same, it is easier to do comparative studies teasing out the effect of minor changes in the guidance or in the components. Furthermore, we cannot foresee the needs that arise in specific domains. To develop collaborative software applications geared towards the needs of groups in a specific domain, we need to allow the integration of domain-specific components (e.g. diagram editors) The more domain-specific a capability must be, the more likely it is that the development of the capability would be funded only by people working in that domain. This leads to the following requirement: (R6) The system should be open for extensions by third parties.

4 Related Work As already noted by [8] general purpose systems are hard to fit to a specific collaborative process. Furthermore, we cannot expect them to support the special needs of a collaboration engineer with regard to configuring the collaborative software applications and fine-tuning the components. Therefore, we focus in this section on GSS. GroupSystems [26] has published two GSS. The older system is no longer available. It shipped with several collaborative components (e.g. a brainstorming tool, a mood-meter, a whiteboard) and offered the capability to launch external applications in a non-collaborative mode. Their current system, ThinkTank, offers a smaller, but essential set of components. The client application is launched in a browser and can therefore be used without installation. The tools in both systems are highly configurable (and therefore fulfill requirement R2) and can be assembled into collaborative software applications (R1). Both systems are commercial and cannot be extended by third parties, thereby violating R6. GSSOne [27] is a research prototype supporting group processes. It is extensible by software developers (R4) and published as open source software, thus fulfilling R6. However, it does not provide a graphical user interface for assembling components into a work process. Instead, collaboration engineers are expected to directly edit the XML files describing a work process. Thus, GSSOne violates R1. Configurability of the components (R2) is limited as well; e.g. a collaboration engineer can change labels, but not the layout or the colors. Finally, TeamSupport [28] is a commercial GSS. It provides limited support for assembling collaborative software applications (R1) and fine-tuning existing components (R2); e.g. a collaboration engineer cannot use a brainstorming component twice and it is not possible to change the layout of the brainstorming. Furthermore, third party software developers cannot extend the system. Therefore, TeamSupport violates R6. All in all, none of these GSS fulfills all of our requirements.

5 Approach Our approach consists of a server which offers a functionality to manage and maintain shared data, an API supporting the development of components that are part of the

132

T. Buttler et al.

collaborative software applications, a PSS (process support system) running an assembled collaborative software application, and an editor (CACE) supporting collaboration engineers in assembling a collaborative software application. Together these parts form a collaboration support system (CSS). In the following we give a broad overview over the CSS approach. The CSS itself does not contain any tools (e.g. for voting or brainstorming) that are required in a GSS session. Instead, these tools are plugged into the platform as components. A component usually consists of a user interface for displaying data shared in the group, some input mechanism, and business logic. Basically there are two types of components, which can be differentiated by their functionality: controls and tools. Controls steer the workflow in the finished collaborative application (e.g. in the form of an agenda) and provide guidance on how to conduct the collaborative process, whereas tools create, manipulate, and display the shared data. Tools should be designed in a way that they provide a meaningful unit that can be displayed to the group. The tools and controls are made available to the collaboration engineer in the CACE editor [8]. Here, the collaboration engineer can assemble a collaborative software application – a PSS application – in order to support a given collaborative process. The CACE consists of a set of sub-editors supporting specific tasks of the collaboration engineer. The logical design editors support the modeling of a collaborative work practice, i.e. elicit the group goals, identify the activities and select techniques to support these activities. In addition to modeling the whole work practice the collaboration engineer has to create a physical design for each activity. Each activity is mapped to roles using an activity-role editor; examples for roles are leader or stakeholder. For each role-activity pair a screen is created with a screen view editor: the screen contains the tools and controls supporting the activity [8]. When assembling a screen the collaboration engineer has to select and configure tools and controls for the activity. The tools have to be configured so that they e.g. access the relevant contributions (e.g. risks or business units), link to external data sources, or provide prompts for the users. Tool editors and screen view editors support a collaboration engineer in these tasks. By providing the mentioned editors a CSS application can therefore support collaboration engineers in the design and configuration of collaborative software applications (R1) and the configuration of tools (R2). In the following we describe our approach to sharing data between the components (R3), and an API supporting the development of components (R4 and R5). 5.1 Shared Data In the requirements analysis we saw that components need to be able to share and exchange data. We utilize the universal data model (UDM) [29] as the basis for components to exchange data. This model already allows collaboration engineers to define a data model tailored towards a specific collaboration problem. It follows the principles of Entity- Relationship modeling with contributions describing concepts and relationships among these concepts. The collaboration engineer uses population rules to define contribution types (e.g. risk, business units, control) and the

Beyond GSS: Fitting Collaboration Technology to a Given Work Practice

133

relationships (e.g. mitigates, threat to) that are allowed between contributions for every tool. Population rules are written in the format of SubordinateContributionType- RelationshipType- SuperiorContributionType Every tool must have at least one population rule. Apart from the population rules every tool has one and only one data set assigned to it by the collaboration engineer. A data set is a logical container for a collection of contributions from group members. All contributions by group members to a tool are automatically assigned membership in the tool’s data set. Tools in an Operational Risk Assessment application might, for example, be assigned a data set named “Risk_Data_Set” . The population rules for such a tool could be: Business-Unit MemberOf Risk_Data_Set Risk ThreatTo Business-unit Control Mitigates Risk Thus, a collaboration engineer can define the semantic meaning of contributions and their relationships for every tool. In addition to relationships every contribution can have attributes. These attributes have a semantic type and a value to provide further descriptions of an associated contribution. Attributes of a contribution can be assigned by a component: for example, a brainstorming tool might add a label to a contribution, while a voting tool displays this label and adds an average rating as an additional attribute. For the voting tool to access the label it needs to know the type of the attribute as well as the contribution type. These attribute types are defined by the components, not by the collaboration engineers. Furthermore, a component defines the data type (e.g. string, date, binaryObject) of the attribute. A centralized server provides access to the existing contributions. When a component is loaded with the above population rules it would ask the server for all contributions of type Business-Unit that have a MemberOf relationship to the Risk_Data_Set. Each business unit returned by the server would trigger a request for contributions of type Risk that have a ThreatTo relationship with itself. Each Risk returned by the server would then trigger a request for all contributions of type Control that have a Mitigates relationship to itself. Similarly, when a tool has been configured to work with contributions of type risk it can monitor the server for updates to these contributions and thus update its own display accordingly. All in all, through the centralized server data can be shared between components. There is one challenge that has not been addressed yet. The tools is loaded with the population rules, therefore it knows the contribution types and the relationships between these contributions. However, it is not informed the attributes and their types (semantic and data) that are associated with a contribution. The set of attribute types changes dynamically, depending on the components that are present in the system. 5.2 Sharing Data between Components The use of components brings valuable benefits for developers to build groupware applications, as previously mentioned in this paper. However, it also includes additional complexities of specifying a component interface.

134

T. Buttler et al.

The interfaces represent the way components communicate with each other. Through the interfaces, components can have access to the properties of a component and a set of operations, parameters and return values. These are common features present in many component standards, like: COM (Component Object Model) and CORBA (Common Object Request Broker Architecture) and WSDL (Web Service Description Language). Because of their completeness, these standards are also complex; they include not just the definition of the interface but also the whole specification of the components’ communication protocol. As our approach focuses on a very constrained domain, that does not require a collaboration application to be distributed over the network, neither to invoke methods implemented by the components, we chose to create our own standard for describing attributes’ entities handled by components. In our standard, according to the previous section, the attributes need to describe three main properties: the name of the attribute, the value of the attribute and the data type of the attribute. We chose to describe them using the XML Schema [30]. This decision is based on the large adoption of XML and XML Schema as standards to describe XML-based generic structures. <xs:element name="attribute"> <xs:complexType> <xs:sequence> <xs:attribute name="key" type="xs:string" use="required"/> <xs:attribute name="dataType" type="xs:string" use="required"/> Table 1 contains XML Schema code to describe the attributes a component handles. For example, the Outliner component handles users’ contributions. Each contribution may have different attributes, each identified by an id, and defined like a hash table, where the attribute has its semantic type (key), data type and its value (value). Besides, the attribute also has a reference back to the contribution that contains it. Such a way of defining and exposing the interfaces of components supports developers to better document the establishment of components’ communication, leading to an easier way to build component-based groupware applications, from a technological perspective. 5.3 Supporting the Development of Components for a CSS The challenges of collaboration support have already been analyzed in groupware frameworks [31, 32] and are documented in some of the patterns of computermediated interaction [19]. Drawing on this research, we have created an API which provides support for managing shared sessions, managing common data, ensuring data consistency, ensuring consistency with the specified data model, and

Beyond GSS: Fitting Collaboration Technology to a Given Work Practice

135

(synchronous) group awareness. Thus, the CSS provides basic services for collaboration (R5) and thereby speeds up the development time for a single component. In the following we elaborate the functionality provided by the API. Users working together in a CSS session often create, update, cut, copy, paste, move, delete, undelete, and reorder contributions. Furthermore they (un-)link contributions and thereby create or remove relationships between these contributions. Components have to support these user activities. Therefore a CSS API provides component developers with the functionality to make these changes to the shared data. When users work together they can create inconsistencies in the data model by modifying the same contribution at the same time (e.g. two users modify the same text in the outliner at the same time). In order to prevent such inconsistencies the CSS API offers a pessimistic locking mechanism that allows components to lock a contribution or a specific attribute of a contribution. The server enforces these locks. The server ensures consistency with the specified data model through validating contribution types (e.g.. checking whether an instance of a brainstorming tool is allowed to add a contribution of type Risk) and a relationship validation (e.g. checking whether an instance of a brainstorming tool is allowed to add a relationship ThreatTo between a Risk and a Business-unit) to ensure that new contributions and relationships are consistent with the specifications of the data model a collaboration engineer has created through population rules. When components are loaded in the runtime engine they are provided with the population rules the collaboration engineer has specified for them. Apart from displaying and modifying shared data components also have to inform users when the shared data is changed by other team members. Therefore the server informs interested components about state changes to the shared data or the part of that data relevant for the component. The CSS API provides component developers with a mechanism to register as listeners to these updates. (See [29] for further information) A component is responsible for displaying its user interface. Therefore, components are also responsible for displaying information about the activities of team members. Thus, the CSS supports component developers by providing the basic information about activities of the users: for every change made by team member a timestamp as well as the ID of the team member are recorded. This information is made available to every component listening to changes of this type. Using this basic information a component can for example display who changed a contribution. CSS sessions can run over a couple of days or weeks. Therefore a CSS has to provide support for stopping and resuming such sessions by making these sessions persistent [29]. The persistence of a session entails two things: contributions and their relationships have to be persistent, and the state of the session itself has to be persistent as well. The former is handled by the CSS and hidden from components behind the CSS API, the latter is handled by the PSS runtime engine together with the CSS. Components still have to fetch existing data when they are loaded; this is supported by the CSS API. Furthermore, a collaboration engineer has to be able to configure a component using the CACE. Therefore, the editors have to be able to display the configuration options of the components. This means that the components have to publish their configuration options. These configuration options are then displayed by the CACE

136

T. Buttler et al.

and a component accesses the configuration. The API supports component developers with the handling of the components configuration. The configuration for a particular component is provided when that component is launched. A XML wrapper for components allows a component developer to publish the configuration options to the CACE. Thus, the requirement R2 is addressed on the level of component development. Once a component has been developed, it can be uploaded to the system and is immediately made available to the collaboration engineers. Thus, the set of components available to a collaboration engineer is extensible (R4).

6 Implementation We have implemented our approach in a CSS called ActionCenters. In ActionCenters the CACE and the PSS applications are implemented as client applications running as JavaScript applications in a browser. They access a centralized server for user management, and the management and maintenance of the shared data. This server communicates with the web-clients through dynamic communication channels utilizing CometD [33]. A more detailed description of the server can be found in [29]. Components consist of an XML wrapper and an implementation in JavaScript, allowing an administrator to simply upload a new component to make it available in the running system. ActionCenters offers two JavaScript objects (actionCenterAPI and ActionCenterListener) that allows components to manage common data and listen to updates made to that data. The validation of contribution types and relationships takes place on the server side. ActionCenters is published under the BSD license, and is therefore open to anyone who wants to add new components. Thus, ActionCenters fulfills the requirement R6.

7 Experiences In this section we describe how to assemble a PSS application following the scenario presented in the requirements analysis. We assume that somebody has already uploaded a set of basic tools and controls to ActionCenters: a brainstorming tool, an idea-organizing tool, a shared-outlining tool, controls for handling the agenda and the roster of users. First, the collaboration engineer models the work practice. She is supported by the logical design editors in this task. She starts by analyzing the task and the characteristics of the group. Then she decomposes the task into activities. Examples of these activities are revising the taxonomy system requirements or generating possible requirements. In a next step she identifies correlating patterns of collaboration (e.g. generate, clarify and reduce) that should manifest themselves during each activity and selects techniques (e.g. free brainstorming) in order to invoke these patterns of collaborations. When she takes a closer look the second activity - generating requirements - she sees that she can reuse the brainstorming tool present in ActionCenters. Compared to

Beyond GSS: Fitting Collaboration Technology to a Given Work Practice

137

the initial scenario, a new requirement has emerged, as team members need to attach specifications, or illustrations to the requirements. Thus, the second activity is changed as follows: In the second activity they will use a brainstorming component to generate a collection of possible requirements. Parts of the requirements concern a certain software standard that one of the stakeholders uses. As he wants to share the document, an attachment component in combination with the shared-outlining, is necessary to upload the standard, enriching then the brainstorming session. ActionCenter, however, does not offer a component for attaching files. Thus, she decides to employ a software developer to develop a component that allows group members to attach files to a contribution. The software developer identifies the basic requirements for such an attachment component: uploading and downloading files, opening files, renaming files and deleting files. The collaboration engineer tells him that it is sufficient to display a list of files; a folder structure is not needed. Next, the software developer implements a single-user application in JavaScript with mockup functionality for uploading files, downloading files, etc. The user interface consists of three parts: a header panel, the main panel displaying the files, and an input panel for uploading and renaming the files. Taking into account feedback from the collaboration engineer he modifies the user interface and adds configuration options for the attachment component: the header panel needs a configurable label and configurable colors. It should also be possible to completely hide the header panel or the input panel. Having designed a satisfactory user interface the software developer defines the configuration option and implements the missing functionality as well as the support for collaborative work. In a first step, he defines an XML of wrapper for the component which describes all the configuration options of the attachment component. Then, he implements the reading out of these configuration options utilizing the API of ActionCenters. In a next step, he group-enables the tool: he registers listeners to the object of the parent contribution in order to display updates to the file list and he implements the functionality for adding new files, renaming files, and deleting files in such a way that the server is notified of these changes. ActionCenters takes care of informing other clients about these changes. In a last step, he uploads the finished component to ActionCenters so that the collaboration engineer can use the attachment component in her design of the work practice. In parallel the collaboration engineer has started with physical design of the work practice. She has identified two roles (leader and team member) and created activities for both roles with the activity role editor. For each role-activity pair she designs a screen with the screen-view editor. When she designs a screen the collaboration engineer has to ensure (1) that the group members use the right tools and data, (2) that sufficient guidance is packaged with the activity on the screen, and (3) that the group members are focused on the activity and not distracted by unnecessary cues. Point (1) and (3) can be handled by selecting and configuring tools and controls for the activity. Here, she first determines the layout of the whole screen by dividing it into boxes; then she adds tools to these boxes. For now she leaves a blank space for the attachment component. For each tool she defines population rules and also

138

T. Buttler et al.

configures the tool. In this step she packages her knowledge about usability and of the tools and their capabilities into the PSS application. Then, she focuses on packaging the right guidance into the tools (point 2). In general, prompts and high level cues help to focus group members on the activity at hand, more elaborate guidance texts or videos allow novices to figure out what to do without the help of a professional facilitator. This guidance provides an opportunity to package a facilitator's expertise with regard to developing and asking the right questions, presenting information to the group, and promoting understanding of the technology and the outputs of the technology with a PSS application. Thus, she adapts e.g. the cues and prompts to guide the team members through an activity. She also adapts the PSS application to the corporate design of her client. Finally, she takes the attachment component and integrates it into the PSS application. Because the attachments have to be linked to requirements she defines a population rule 'Attachment ChildOf Requirement', thus indicating to ActionCenters the relationship between requirements and files. Then she configures the attachment component. Figure 1 shows the screen displayed to a team member during the brainstorming for requirements. Team members can see and read the ideas of other team members (1), add new contributions (2) and link a contribution to an attachment (3). Thereby the second activity is fully supported.

Fig. 1. Brainstorming for Requirements (with Attachment Component)

All in all, the collaboration engineer has created a collaborative software application that (1) packages collaborative expertise with collaboration technology and (2) fits a specific process.

8 Conclusions and Future Work Collaboration has become a critical success factor for many organizations, as products and services are becoming increasingly complex and no individual has the skills to

Beyond GSS: Fitting Collaboration Technology to a Given Work Practice

139

design, develop and deliver these alone. GSS often only offer a limited set of tools with a limited set of configurable features. Organizations, however, face an unlimited variety of problems with an unlimited variety of structures which can make it difficult to fit a given collaborative process to a given GSS platform. Another problem is the complexity of collaboration itself. Effective, predictable collaboration requires an understanding not only of the technology but also of the process. Collaboration engineers are researching ways to package collaboration expertise with collaboration technology in a form that practitioners could reuse without training on either the tools or the collaboration techniques. In this article, we presented the collaboration support system ActionCenters to address the above challenges. ActionCenters supports the design of collaborative applications by means of component-based approach and a CACE editor that allows collaboration engineers to assemble the components. The components are highly configurable and have access to shared data. The set of components can easily be extended via the ActionCenters API and the offered basic collaboration services. Summarizing, ActionCenters allows collaboration engineers to design a collaborative work practice, and then use that design to develop a collaborative software application tailored specifically for that task. Thereby, ActionCenters goes beyond current GSS and presents a step forward in supporting collaborative processes. In future work, we will observe how the different users, i.e. collaboration component developers, collaboration engineers, practitioners and team members in a collaborative process, interact with our system. We intend to apply usability tests concerning the CACE tool to identify collaboration engineers’ limitations in creating a collaboration process. This way we can improve the CACE tool with mechanisms that support the collaboration engineer in his task. We want to use the results for developers to improve the API of our system, for collaboration engineers to offer more components and pre-configured tools for reuse, for practitioners to offer as much guidance as necessary and for team members to further improve the usability of our system. Acknowledgments. This work has been partially supported by the FP7 EU Largescale Integrating Project SMART VORTEX (Scalable Semantic Product Data Stream Management for Collaboration and Decision Making in Engineering) cofinanced by the European Union. For more details, visit http://www.smartvortex.eu/

References [1] Weick, K.E., Sutcliffe, K.M., Obstfeld, D.: Organizing and the process of sensemaking. Organization Science 16(4), 409–421 (2005) [2] Ren, Y., Kiesler, S., Fussell, S.R.: Multiple group coordination in complex and dynamic task environments: Interruptions, coping mechanisms, and technology recommendations. Journal of Management Information Systems 25(1), 105–130 (2008) [3] Rudolph, J.W., Morrison, J.B.: The dynamics of action-oriented problem solving: linking interpretation and choice. The Academy of Management Review, AMR 34(4), 733–756 (2009); authors incomplete [4] Diehl, M., Stroebe, W.: Productivity loss in brainstorming groups: Toward the solution of a riddle. Journal of Personality and Social Psychology 53(3), 497–509 (1987)

140

T. Buttler et al.

[5] Bordia, P., Irmer, B.E.: Differences in sharing knowledge interpersonally and via databases: The role of evaluation apprehension and perceived benefits. European Journal of Work and Organizational Psychology 15(3), 262–280 (2006); incomplete author list [6] Packer, D.J.: Avoiding groupthink. Psychological Science 20(5), 546 (2009) [7] Lu, S.C.-Y., Elmaraghy, W., Schuh, G., Wilhelm, R.: A scientific foundation of collaborative engineering. CIRP Annals - Manufacturing Technology 56(2), 605–634 (2007) [8] Briggs, R., Kolfschoten, G., de Vreede, G., Albrecht, C., Lukosch, S.: Facilitator in a box: Computer assisted collaboration engineering and process support systems for rapid development of collaborative applications for high-value tasks. In: Hawaii International Conference on System Sciences, Kona, HI (2010) [9] Fjermestad, J., Hiltz, S.R.: A descriptive evaluation of group support systems case and field studies. Journal of Management Information Systems 17(3), 115–159 (2000) [10] Niederman, F., Beise, C.M., Beranek, P.M.: Issues and concerns about ComputerSupported meetings: The facilitator’s perspective. MIS Quarterly 20(1), 1–22 (1996) [11] Griffith, T.L., Fuller, M.A., Northcraft, G.B.: Facilitator influence in group support systems: Intended and unintended effects. Information Systems Research 9(1), 20–36 (1998) [12] Briggs, R.O., De Vreede, G.J., Nunamaker Jr., J.F.: Collaboration engineering with ThinkLets to pursue sustained success with group support systems. Journal of Management Information Systems 19(4), 31–64 (2003) [13] Dennis, A.R., Nunamaker, J.F., Vogel, D.R.: A comparison of laboratory and field research in the study of electronic meeting systems. Journal of Management Information Systems 7(3), 107–135 (1990) [14] Robert, M., Davison, R.M., Briggs, R.O.: GSS for presentation support. Communications of the ACM 43, 9197 (2000) [15] Haake, J.M., Hussein, T., Joop, B., Lukosch, S., Veiel, D., Ziegler, J.: Modeling and exploiting context for adaptive collaboration. International Journal for Cooperative Information Systems (IJCIS) 19(1-2), 71–120 (2010) [16] Briggs, R., Kolfschoten, G., de Vreede, G., Albrecht, C., Dean, D., Lukosch, S.: A seven layer model of collaboration: Separation of concerns for designers of collaboration systems. Paper Presented at the 30th International Conference on Information Systems (2009) [17] de Vreede, G.J., Briggs, R.O., Massey, A.P.: Collaboration engineering: Foundations and opportunities: Editorial to the special issue on the journal of the association of information systems. Journal of the Association for Information Systems 10(3), 7 (2009) [18] Greenberg, S.: Toolkits and interface creativity. Multimedia Tools and Applications 32, 139–159 (2007); doi:10.1007/s11042-006-0062-y [19] Schümmer, T., Lukosch, S.: Patterns for Computer-Mediated Interaction. John Wiley & Sons, Ltd, Chichester (2007) [20] Gerosa, M., Pimentel, M., Fuks, H., de Lucena, C.: Development of Groupware Based on the 3C Collaboration Model and Component Technology. In: Dimitriadis, Y.A., Zigurs, I., Gómez-Sánchez, E. (eds.) CRIWG 2006. LNCS, vol. 4154, pp. 302–309. Springer, Heidelberg (2006) [21] Springer, T., Schuster, D., Braun, I., Janeiro, J., Endler, M., Alfredo, A., Loureiro, F.: A flexible architecture for mobile collaboration services. In: Douglis, F. (ed.) Middleware (Companion), pp. 118–120. ACM, New York (2008) [22] Szyperski, C.: Component Software: Beyond Object-Oriented Programming, 2nd edn. Addison-Wesley Professional, Reading (2002)

Beyond GSS: Fitting Collaboration Technology to a Given Work Practice

141

[23] Litiu, R., Parakash, A.: Developing adaptive groupware applications using a mobile component framework. In: Proceedings of the 2000 ACM Conference on Computer Supported Cooperative Work, CSCW 2000, pp. 107–116. ACM, New York (2000) [24] Slagter, R., Biemans, M., ter Hofte, H.: Evolution in use of groupware: facilitating tailoring to the extreme. In: Proceedings of Seventh International Workshop on Groupware, 2001, pp. 68–73 (2001) [25] Roth, J.: Dreamteam: A platform for synchronous collaborative applications. AI & Society 14, 98–119 (2000); doi:10.1007/BF01206130 [26] Group Systems. Groupsystems (2011), http://www.groupsystems.com/index.php/about-us [27] Knoll, S.W., Hörning, M., Horton, G.: Applying a thinklet- and thinxel-based group process modeling language: A prototype of a universal group support system. In: Sprague Jr., R.H. (ed.) Proceedings of the 42nd Hawaii International Conference on System Sciences, pp. 1–10. IEEE Computer Society Press, Los Alamitos (2009) [28] Kolfschoten, G.L., Lee, C.: Self-guiding group support systems: Can groups use gss without support? In: Sprague jr., R.H. (ed.) Proceedings of the Hawaii International Conference on System Science, pp. 1–6. IEEE Computer Society Press, Los Alamitos (2010) [29] Mametjanov, A., Kjeldgaard, D., Pettepier, T., Albrecht, C., Lukosch, S., Briggs, R.: ARCADE: Action-Centered rapid collaborative application development and execution. In: Hawaii International Conference on System Sciences, USA, 2011, pp. 1–10. IEEE Computer Society Press, Los Alamitos (2011) [30] W3C. Xml schema (2011), http://backpack.blackboard.com/ [31] Lukosch, S.: Flexible and transparent data sharing for synchronous groupware. International Journal of Computer Applications in Technology, Special Issue on Current Approaches for Groupware Design, Implementation and Evaluation 19(3/4), 215–230 (2004) [32] Schuckmann, C., Kirchner, L., Schümmer, J., Haake, J.M.: Designing object-oriented synchronous groupware with COAST. In: Proceedings of the ACM 1996 Conference on Computer Supported Cooperative Work, Boston, Massachusetts, USA, pp. 30–38 (July 1996) [33] The dojo foundation. Cometd (2011), http://cometd.org/

Collaborative Features in Content Sharing Web 2.0 Social Networks: A Domain Engineering Based on the 3C Collaboration Model Lucas Santos de Oliveira and Marco Aurélio Gerosa Computer Science Department, Institute of Mathematics and Statistics, University of São Paulo (USP), Zip 05508-090 {lucasso,gerosa}@ime.usp.br

Abstract. Researchers and developers still replicate ideas with low reuse when developing Web 2.0 applications. A domain engineering identify and document communalities and variabilities of an application family fostering reuse. In this work, we used a domain engineering approach for content sharing features of social networks. We used as a method the FODA (Feature Oriented Domain Analysis) with patterns for computer-mediated interaction to describe the collaborative features and the 3C collaboration model to classify them. To implement the commonalities, we defined and developed a component kit based on an infrastructure named Groupware Workbench. We conducted an experiment and a case study to evaluate the artifacts generated by the domain engineering. Keywords: Collaborative Systems, Domain Engineering, 3C Collaboration Model, Interaction Patterns, Social Networks, Web 2.0, Groupware.

1 Introduction Web companies that survived the dotcom crisis were using the internet as a platform, offering collaborative sites based on communities [1]. This concept was called Web 2.0. Differently from the previous model, in which companies produce content for users’ access, the Web 2.0 involves the user in this process. Users produce, organize, share, mix, criticize, and update the content. According to Prescott [2], the increasingly amount of web content is a result of the penetration of broadband, web cam, cell phone, and personal cameras. Users usually share the produced content in social networks. Although these sites have several recurrent collaborative features, there are very few solutions that allow the reuse of the code that implement these features. Greenberg [3] positioned the collaborative systems development in the Replication phase of the BRETAM model [4], which describes how a technology evolves over time. During the Replication phase, researchers explore ideas of one another implementing, changing, and innovating. The process of building tools is not well A.S. Vivacqua, C. Gutwin, and M.R.S. Borges (Eds.): CRIWG 2011, LNCS 6969, pp. 142–157, 2011. © Springer-Verlag Berlin Heidelberg 2011

Collaborative Features in Content Sharing Web 2.0 Social Networks

143

established yet and there are lots of uncertainties and rework. Greenberg [3] argue that this stagnation in the Replication phase takes place because of the lack of toolkits that support reuse and encapsulation of technical complexities. This scenario illustrates the opportunity for a Domain Engineering (DE) to develop reusable software, reducing the need for redevelopment and keeping focus on systems assembly. In this work, we present a domain engineering for collaborative features of content sharing social networks. We use the FODA [5] method extended with the 3C collaboration model [6] to classify, and interaction patterns to describe the collaborative features. The interaction patterns are based on a language for computermediated interaction proposed by Schummer and Luckosh [7]. To develop a component kit for the assembling of content sharing social networks, we used the Groupware Workbench [8] platform. We also conducted a case study and an experiment to evaluate the results. The remainder of this paper is organized as follows. We present an overview about domain engineering in Section 2 and the related work in Section 3. Section 4 presents the proposed approach for domain engineering for collaborative features in content sharing in Web 2.0 social networks. The experiment and the case study are presented in Section 5. Section 6 concludes the paper.

2 Domain Engineering Applications from the same domain have recurrent features that can be identified and analyzed to promote reuse. Aharoni and Berger [9] define domain as a set of applications that uses common concepts to describe requirements, problems, and capacities. The domain is bordered according to the similarities between applications [10]. Clements [11] defines Domain Engineering as a set of systems sharing a common and managed set of features that satisfy the specific needs of a particular market segment. There are many benefits provided by the reuse provided by a domain engineering, for example, the reduction of development costs and improvement of quality [12]. Alaña and Rodriguez [13] present a domain engineering process divided into domain analysis, domain design, and domain implementation. This division appears in others works as Blois and Becker [14] and Harsu [10]. The domain analysis is a process of identifying, collecting, organizing, and representing the relevant information of a domain, based on the study of existing systems and their development histories, knowledge captured from domain experts, underlying theory, and emerging technology [5]. The domain design uses results of the domain analysis to identify and generalize solutions for common requirements, by means of a software architecture specification [15]. According to Blois and Becker [14] this is an activity in which the project model is built based on the analysis model, the knowledge obtained studying the domain, and the reference architecture. The domain implementation includes the development of reusable components [15] [10]. This

144

L. Santos de Oliveira and M.A. Gerosa

activity aims to build reusable software components based on the domain and on the reference architecture proposed in the domain design activity. 2.1 FODA (Feature Oriented Domain Analysis) Many domain-engineering methods have been proposed. Alaña and Rodriguez [13] classify these methods in three different groups. Methods based on domain analysis aims to analyze and to model the domain for reusing similar parts. Some examples are ODM [16], FODA [5], FORM [17], FeatureRSEB [18], DARE [19], and Odyssey-DE [20]. Product Lines methods have been extended or connected to others to cover all the production process. Some examples are FAST [10] and PuLSE [21]. Domain Engineering and OOA/D combine domain engineering with object-oriented analysis and design. Some examples are OOram [22], JODA [23], and RiDE [24]. FODA [5] was developed at SEI (Software Engineering Institute). It is arguably the most well-known domain engineering method. It is based on the identification, analysis, and documentation of the system features, resulting in generic domain products widely applicable in a domain. The FODA method approach is relevant from the component-based development point of view, because the process of getting relevant features helps the identification of possible software components [15]. We used the FODA method because it is based on feature domain analysis and it is focused on the domain, rather than in the implementation and architecture details, as we do not have access to the internal implementation of the analyzed systems. 2.2 Extension of FODA for Collaborative Systems Analysis In this work, the FODA method was extended with the 3C Collaboration Model and patterns for computer-mediated interaction to better support collaborative systems analysis. The first extension aimed to classify the collaborative features and the second one aimed to describe them. Ellis et al. [6] used the 3C dimensions (communication, coordination, and cooperation) to classify the computational support for collaboration. This model is widely used in CSCW literature [25] [26] [27]. Communication involves exchange of messages and commitment negotiations. By means of the coordination, people, activities, and resources are managed to deal with conflicts and prevent loss of communication and cooperation efforts. Cooperation is the joint operation in a shared environment, generating, and manipulating cooperation objects [28]. In this work, we adopted the 3C collaboration model to classify and organize the collaborative features. Once classified, these features were mapped to software components, which are used to build collaborative applications based on communication, coordination, and cooperation requirements. We used the following criteria to classify features according to the 3C collaboration model: • Communication: when the feature is used by people to send messages among them; • Coordination: when the feature is used by people to manage themselves, or to become aware of the activities and its effects on the collaboration; • Cooperation: when the feature is used by people to manage the shared space or to interact with shared artifacts.

Collaborative Features in Content Sharing Web 2.0 Social Networks

145

Based on pattern language [29] and on software design patterns [30], Schummer and Luckosh [7] proposed patterns for computer-mediated interaction that describe recurrent support for group interaction based on the following structure: name, sensitizing picture, intent, context, problem, scenario, symptoms, solution, dynamics, rationale, check, danger spots, known uses, and related patterns. In this proposal, interaction patterns were used to describe the collaborative features.

3 Related Work SPLCW2.0 is a domain engineering work for synchronous application [31]. According to Gaspar et al. [31] during the implementation of web applications for the Tidia-Ae project, many intersection points were found. Some of those points were easy to identify, for example, a generic communication service for synchronous messages exchange. Others points, for example, a rich window framework (RWIF) was identified after the building of an application set. The set of identified components was developed using the Tidia-Ae architecture and it enabled building several systems. Gadelha et al. [32] present an approach to solve some problems identified in the development of Groupware Product Lines (GPL), which does not cover the domain analysis activity, does not encompass traceability, domain differences, and communalities. The main objective is to develop GPL with the benefits of Software Product Lines. The GPL domain analysis and requirements elicitation are based on the RUP 3C-Groupware [32]. No other work was found conducting a domain engineering in a groupware domain. However, there are related platforms that provide collaborative features for social network building, but these platforms are not based on components as described in CBE (Component Based Engineering) literature and its architecture and focus were not similar to this work. Noosfero (www.noosfero.org) is a web platform for social and solidarity economy networks with blog, e- Porfolios, CMS, RSS, thematic discussion, events agenda and collective intelligence for solidarity economy in the same system. It has three kinds of profiles: person, communities, and enterprises. Elgg (www.elgg.org) is open source social networking software that provides to individuals and organizations some components to build online social environments. Some features are blogging, user profile, recent activities, chat, social bookmark, photo, and video gallery.

4 Domain Analysis The first activity of the FODA method is the context analysis, which defines the scope of a domain that is likely to yield exploitable domain products. In this work, the context is defined as “content sharing Web 2.0 social networks.” A social network is defined as a group of people connected, in which users can build a public profile, possess a connected user list and navigate through it [33].

146

L. Santos de Oliveira and M.A. Gerosa

According to McCann [34], 2/3 of internet users use social networks. Their main uses are related to content sharing, which have been growing since the first studies in 2006. Between 2008 and 2009, 76% of users made photo upload and 33% video upload. In addition, the study shows that 96% of users visit their virtual friends profiles and 66% update their profiles [34]. 4.1 Social Network Collaborative Features Fig. 1 illustrates the identification of collaborative features at Facebook (www.facebook.com) following the collaborative features classification criteria, based on the 3C collaboration model. Rectangles are communication elements, ellipses, coordination, and arrows, cooperation. “Commenting” is a communication feature, “report abuse,” a coordination feature, and image “marking,” “sharing,” and “evaluation,” cooperation features.

Fig. 1. Mapped features based on the 3C collaboration model

We conducted this analysis in several social networks to identify the most present collaborative features (Fig. 2). We chose the social networks based on the Alexa (www.alexa.com) classification rank, which have a list of the most popular social networks, based on traffic analysis. As presented in Fig. 2, twenty-one collaborative features were identified. Only one communication feature was identified, four of

Collaborative Features in Content Sharing Web 2.0 Social Networks FEATURES

SOCIAL NETWORKS FACEBOOK GROUPSITE ORKUT FOTOLOG DEVIANT ART FOTOKI PHOTOBUCKET PICASA FLICKR YOU TUBE HI5 XANGA NETLOG WINDOWS LIVE FRIENDSTER

SERVICE

147

COOMMUNICATION COMMENT RECENT ACTIVITIES SEARCH PEOPLE COORDINATION GROUPS REPORT ABUSE SHARED CONTENT STATISTICS RATING EXPORT DESCRIBE RECOMMEND UPLOAD MARK COOPERATION CATEGORIES CONTENT SEARCH PROMOTE PLAYLIST OR ALBUNS FAVORITES NOTE TAGS PERMISSION

X X X X X X X X X X X X X X X X X X X X

X X X X X X X X X X

X X X X X X X X X X X X X

X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X

X X X X X X X X X X X X X X X X X X X X X

X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X

X X X X X X X X X X X X X X X X X X X X X X X X

X X X X

X X

Fig. 2. Content sharing collaborative features classification

coordination, in which the most recurrent was recent activity, and sixteen of cooperation, in which most recurrent were object sharing, description, and upload. The next phase of FODA is the Domain Model development, which consists of three major activities: feature analysis, entity-relationship modeling, and functional analysis. The purpose of feature analysis is to capture, in a model, the end-user’s (and customer’s) understanding of the application general capabilities in a domain [5]. In Fig. 4, the collaborative features are represented as mandatory or optional. Their derivations are alternative and exclusive [32]. The entity-relationship model captures and defines the domain knowledge that is essential for implementing applications [5]. Fig. 3 presents the collaborative features class diagram and the relations among them.

Fig. 3. Collaborative features class diagram

148 L. Santos de Oliveira and M.A. Gerosa

Collaborative Features in Content Sharing Web 2.0 Social Networks

149

Fig. 4. Collaborative features tree

In this work, we represent functional differences and communalities using patterns for computer-mediated interaction [7]. The description of the “comment” pattern is summarized below. For space reasons, the other descriptions are available on the website http://www.groupwareworkbench.org.br/engenhariadedominio. Commenting Intention: enables a user to do an observation about a shared content. Context: users are using a collaborative tool and wish to leave their opinion about a shared content.

150

L. Santos de Oliveira and M.A. Gerosa

Problem: users wish to leave their opinion about a shared content for other people, but the collaborative tool does not have a mechanism that enables them to leave such contribution. Scenario: John is navigating in a social network, found an interesting image of a church of his home city, and decided to comment some historical building facts, but he does not found a place to leave his contribution. Symptoms: You should consider applying this pattern when You wish users contributing, textually, about the content sharedYou wish discussions about the shared content. Solution: To integrate a comment mechanism that enable users to leave their contributions and to begin a discussion about the shared content. Dynamics: A user writes a text on a specific field for comments. After that, they should click on send message button, and their contribution appears on the discussion thread. Other users agree or disagree about an opinion by means of reply. Rationale: the commenting pattern provides users an easy and fast textual commenting mechanism. Check: When applying this pattern, you should answer these questions: Does the application should enable comments reply? Where will it be placed? Will it have textual resources only? Danger Spots: You should take care of the text that will be commented and how it will be processed. People could insert malicious source code on the comment, affecting system stability and safety. Known Users: Facebook, Orkut, Fotolog, and DeviantArt. Related patterns: Forum: describes how users could discuss textually about a specific topic. Discussion Thread: Help people to find related messages when a user replies an existent comment. Annotation: Enables user to create notes or comments about a shared content. 4.2 Domain Design and Implementation The last phase of the FODA method is architecture modeling, which provides a software solution to the issues identified in the domain modeling activity. An architecture model (also known as reference architecture) is developed in this phase. In this work, we used the Groupware Workbench platform [8] as reference architecture and component development tool. It provides a component kit and infrastructure to support the development of Web 2.0 collaborative applications. Component technology has been largely used to support the construction of groupware applications. Groupware Workbench uses components called collablets. Java class composes each collablet, namely: entities, a business interface implementation, and controllers. In the presentation layer, it uses Java server pages (JSP) and some graphical interface widgets encoded as tagfiles. Each application has a main collablet, which represents

Collaborative Features in Content Sharing Web 2.0 Social Networks

151

an entry point and manages all other components by means of subordination and dependency. Advantages of Groupware Workbench are: support to components development, an infrastructure to build and deploy the applications based on the domain, and a reference architecture to build the components and applications. In addition, it enables application composition by means of a graphical interface, which recognizes the installed components and enables to compose applications without any Java code alteration. In this work, we adopted the mapping one-to-one between the identified feature in the domain analysis and the corresponding software component. As an implementation example, the implementation of the commenting feature as the collablet commentMgr is presented in Fig. 5.

Fig. 5. CommentMgr component

The commentMgr component implements two interface widgets: one for assigning a comment from a user about content, and another to return a list of assigned comments. The widgets are inserted into the collablet JSP. At the bottom of Fig. 6, an example of a commentMgr widget is shown. Along with the commentMgr component, the collablets tag, binomialMgr, descriptionMgr, rating, and photoMgr are composing this interface. The collaborative feature variabilities are treated in this work by means of interface widgets or XML configuration. For instance, for the emoticon-enabled commentaries, component variability is needed to implement an interface widget that provides its characteristic, without the necessity for component infrastructure changes.

152

L. Santos de Oliveiraa and M.A. Gerosa

Fig. 6. 6 Arquigrafia Brasil comment component

5 Evaluation An experiment and a case study s were conducted to evaluate the domain. The first one evaluated the artifacts accorrding to ease of use, utility, and understanding. The secoond one evaluated the applicatio on of its artifacts in a real context. 5.1 Experiment ngineering, an experimental study divided into two phaases To evaluate the domain en was done: one to evaluate the feature model coverage and the patterns descriptiion, was and other to evaluate the artifacts, ease of use, and utility. The experiment w Web performed with 10 availaable under graduation and graduation students of W development course, with some s software development experience. They participaated in the experiment near the end e of the course. During the experiment, participants p filled out a questionnaire containing questiions about educational and sociaal network experiences. After that, they had to evaluate and identify the collaborative feeatures at PhotoBucket, Flickr, and Netlog social networrks, as they contained a large nu umber of collaborative features (Fig. 2), within 30 minuutes. At the end of these activitties, a list containing seven collaborative features withh its respective patterns descrip ptions was presented. They had to read and identify the features in social networks;; in addition, they had to evaluate the ease of use, detailiing, and ease of identification off the patterns. After that, they were div vided into two groups and they had to add two collaborattive features (commentaries an nd tags) in two applications: a FAQ (frequently asked questions system) develop ped with the Groupware Workbench and another F FAQ

Collaborative Features in Content Sharing Web 2.0 Social Networks

153

developed in a traditional web development way. The groups were inverted after the first hour and ten minutes or when they finished the activity. At the end of the activities, they answered a questionnaire containing questions related to the artifacts and to the process. According to the GQM [39] framework the experiment goal was: Analyze the domain engineering For the purpose of evaluation With respect to coverage, ease of use, and utility From the viewpoint of collaborative systems developers In the context of students of Computing Science course Questions Q1: Are there collaborative features that were not identified in the domain engineering? Q2: Do developers understand the artifacts generated in the domain engineering? Q3: Can developers build a new system using the generated artifacts? Q4: Do developers consider useful the generated artifacts? Metrics Metric M1 – (Q1): the set of features identified by developers that were not identified in the domain engineering Metric M2 – (Q2): the percentage of interaction patterns evaluated as easy to understand Metric M3 – (Q2): the percentage of interaction patterns evaluated as easy to identify in others social networks Metric M4 – (Q3): the number of developers who performed the proposed activity within a time of two hours and twenty minutes with at least two components Metric M5 – (Q3): the percentage of developers that positively evaluated the artifacts as easy to use Metric M6 – (Q4): the percentage of developers that evaluated the artifacts as useful Analyzing the collected data, we got: For Question 1, the developers did not found new collaborative features in the evaluated social networks. For Question 2, 92% percent of collaborative features are easy to understand, and 87% are easy to identify in others social networks, but some developers pointed the following interaction patterns as hard to understand: description, statistics, upload, mark, and category. For Question 3, all developers performed the experiment, but less than 80% evaluated as easy to use the generated artifacts. For Question 4, almost all developers evaluated the artifacts as useful, only one evaluated as neutral. Based on the experiment results, we conclude that the developers had identified the same collaborative features of this work, they can understand the feature description, and classified them as useful, but the usability needs to be improved. 5.2 Case Study: Social Network Arquigrafia Brasil The Arquigrafia Brasil (www.arquigrafia.org.br) is a social network that aims to offer a huge public collection of Brazilian architecture digital images, not existing yet,

154

L. Santos de Oliveira and M.A. Gerosa

assigned and cataloged by users. In this case study, we verify if the components produced in the domain engineering are sufficient to build a social network. Some independent researchers conducted a focus group for usability study with possible users, students, photographers, and architects, in which some image sharing features for a possible architecture social network were identified. Some of these features can be mapped into features previously identified in this work, as shown in Fig. 7.

Features (tool or services)

23

6

10 6 14 19 21 27

28

31

directory criation in personal area, all registres ordered by date talling a story Videos to registry the arc hitecture evolution, talling a evolutionary story Theme photos visualization Information about the image(where, who, historic al context) Google Earth connection Photo search by theme, historic al period, etc . shared images acc ess control(privac e) sec urity on image storage: persist users notific ation, abuse, etc . comment area about projec t, image, group shared image, and soc ial network shared images. visualization by categories as regional arc hitecture.

Nec essity Sc ale:1(=less necessary) a 4(=very nec essary)

Justification

c orrespondet c ollaborative features

3C collaboration model dimension

4

Foc us Group

c ollection

cooperation

3

Foc us Group

shared content

cooperation

4

Foc us Group

shared content

cooperation

4

Foc us Group

desc ription

cooperation

2

Foc us Group

desc ription

cooperation

4

Foc us Group

c ontent searc h

cooperation

3

Foc us Group

permission

cooperation

4

Foc us Group

report abuse

coordination

4

Foc us Group

c omment and group

communic ation, cooperation

4

Foc us Group

c ategory

cooperation

Fig. 7. Focus group identified features and its correspondent collaborative features

Independent researchers also conducted brainstorm meetings for desired features identification. The desired features was classified according to the 3C collaboration Model and compared to the identified collaborative features of this work, resulting in 12 matched features. We conclude that the identified features in this domain engineering cover a large part of the features for building the Arquigrafia Brasil. However, some specific components were not identified in this domain engineering such as binomial ones (which enable image evaluation), because this component is specific for the Arquigrafia Brasil project.

Collaborative Features in Content Sharing Web 2.0 Social Networks

155

6 Conclusion The Web 2.0 increased the possibility of socialization and expression by means of computer-mediated tools. Users not only modify the web pages content, but help to organize, share, criticize, and update it. We proposed a domain engineering for building collaborative software components, reducing the reimplementation necessity and focusing on the system assembly. For this work, the chosen domain was Web 2.0 social networks, focusing on the content sharing collaborative features. To perform this domain engineering, we did an adaptation of the FODA method with the 3C collaboration model to classify and patterns for computer-mediated interaction to describe the collaborative features. The Groupware Workbench was used in the activities of domain design and domain implementation to develop the collaborative software components. Although, these components are not limited to the domain of social network, they can be used in other domains. To evaluate the artifacts generated in this domain engineering, we performed an experiment and a case study. The first one evaluated the artifacts ease of use, utility, and understanding; the second one evaluated the application of its artifacts in a real context: the social network Arquigrafia Brasil. Developers evaluated the artifacts as useful and easy to understand. For the case study, we concluded that the performed domain engineering covered the features previously identified in the focus group and brainstorms. This work also proposed an approach to perform a domain engineering for collaborative systems, adapting the FODA method with 3C collaboration model and patterns for computer-mediated interaction. In addition, it provided a component kit that enables to build new collaborative social networks in the Web 2.0, increasing the software reuse.

References 1. O’Reilly, T.: What is Web 2.0: Design patterns and business models for the next generation of software (2010), http://oreilly.com/web2/archive/what-isweb-20.html 2. Prescott, L.: Hiwise US consumer generated media report., Hitwise, fev. (2007) 3. Greenberg, S.: Toolkits and interface creativity. Springer Science + Business Media (2007) 4. Gaines, B.: Modeling and forecasting the information sciences. Information Sciences 57/58, 13–22 (1999) 5. Kang, K., Cohen, S., Hess, J., Novak, W., Peterson, A.: Feature-Oriented Domain Analysis (FODA) Feasibility Study. CMU/SEI (1990) 6. Ellis, C.A., Gibbs, S.J., Rein, G.L.: Groupware - Some Issues and Experiences. Communications of the ACM 42 (1991) 7. Schummer, T., Lukosch, S.: Patterns for Computer-Mediated Interaction. John Wiley & Sons Ltd., Chichester (2007) 8. Groupware Workbench: Groupware Workbench (2010), http://www.groupwareworkbench.org.br (accessed 2010) 9. Aharoni, A., Reinhartz-Berger, I.: A Domain Engineering Approach for Situational Method Engineering. University of Haifa (2008)

156

L. Santos de Oliveira and M.A. Gerosa

10. Harsu, M.: A survey on domain engineering. Institute of Software Systems Tampere University of Technology (2005) 11. Clements, P.: FAQs: An Introduction to Software Product Lines (accessed 2005) 12. Pohl, K., Böckle, G., Der, F.: Software Product Line Engineering, Foundations, Principles, and Techniques. Springer, Heidelberg (2005) 13. Alaña, E., Rodriguez, A.: Domain Engineering Methodologies Survey. GMV Inovvating Solutions (2007) 14. Blois, A., Becker, K.: A Component-Based Architecture to Support Collaborative Application Design. In: Proceedings of the 8th International Workshop on Groupware: Design, Implementation and Use, London, pp. 134–146 (2002) 15. Werner, C., Braga, R.: A Engenharia de Domínio e o Desenvolvimento Baseado em Componentes. Editora Ciência Moderna, Rio de Janeiro (2005) 16. Simos, M.: Organization domain modeling and oo analysis and design: Distinctions, integration, new directions. In: STJA 1997 Conf. Proc., pp. 126–132 (1997) 17. Kang, K., Kima, S., Lee, J., Kim, K., Shin, E., Huh, M.: FORM: A feature-oriented reuse method with domain-specific reference architectures. Annals of Software Engineering 5 (1998) 18. Griss, M., Favaro, J., d’Alessandro, M.: Integrating Feature Modeling with the RSEB (1998) 19. Frakes, W., Prieto-Diaz, R., Fox, C.: Dare: Domain analysis and reuse environment. Ann. Softw. Eng., 125–141 20. Braga, R., Werner, C., Mattoso, M.: Odyssey-Search: A multi-agent system for component information search and retrieval. Journal of Systems and Software 79, 204–215 (2006) 21. Bayer, J., Flege, O., Knauber, P., Laqua, R., Muthig, D., Schmid, K., Widen, T., DeBaud, J.-M.: Pulse: a methodology to develop software product lines. In: Proceedings of the 1999 Symposium on Software Reusability, pp. 122–131 (1999) 22. Hoeydalsvik, G.: OORAM: Object-Oriented Role Analysis and Modeling. Wiley-QED Publishing, Somerset (1994) 23. Holibaugh, R.: Joint Integrated Avionics Working Group (JIAWG) Object- Oriented Domain Analysis Method (JODA). Carnegie Mellon University (1993) 24. Almeida, E.: RiDE: The RiSE Process for Domain Engineering. Ph.D. Thesis in Computer Science, UFPE (2007) 25. Castellani, S., Ciancarini, P., Rossi, D.: The ShaPE of ShaDE: a Coordination System., Technical Report UBLCS (1996) 26. Sauter, C., Morger, O., Muhlherr, M., Thutchytson, A., Teusel, S.: CSCW for Strategic Management in Swiss Enterprises: an Empirical Study. In: 4th European Conference on Computer Supported Cooperative Work (ECSCW 1995), Stockholm, Sweden, pp. 117– 132 (1995) 27. Escovedo, T., Melo, R.N.: Applying a methodology for collaborative assessment in learning groups. 2010 IEEE Education Engineering (EDUCON), 1205–1210 (2010) 28. Gerosa, M.A., Pimentel, M.G., Fuks, H., de Lucena, C.J.P.: Development of Groupware Based on the 3C Collaboration Model and Component Technology. In: Dimitriadis, Y.A., Zigurs, I., Gómez-Sánchez, E. (eds.) CRIWG 2006. LNCS, vol. 4154, pp. 302–309. Springer, Heidelberg (2006) 29. Alexander, C., Ishikawa, S., Silvertein, M.: A pattern language. Oxford University Press, Oxford (1977) 30. Gamma, E., Helm, R., Viissides, J.: Design Patterns: Elements of Reusable ObjectOriented Software. Addison-Wesley, Reading (1995)

Collaborative Features in Content Sharing Web 2.0 Social Networks

157

31. Gaspar, T., Yaguinuma, C., Do, A.: Software product lines for Web 2.0 synchronous collaboration. In: WebMedia 2009 Proceedings of the XV Brazilian Symposium on Multimedia and the Web (2009) 32. Gadelha, B., Nunes, I., Fuks, H., Lucena, C.J.P.: An Approach for Developing Groupware Product Lines Based on the 3C Collaboration Model. In: 15th Collaboration Researchers’ International Workshop on Groupware, pp. 328–343 (2009) 33. Kazienko, P., Musial, K.: Social Capital in Online Social Networks, pp. 417–424 (2006) 34. Universal McAnn: Power to the people - social media tracker wave 4. Universal McAnn (2009) 35. Grudin, J.: Why groupware applications fail: Problems in design and evaluation. Information Technology & People 245 36. Hill, J., Gutwin, C.: He maui toolkit: Groupware widgets for group awareness. Computer Supported Cooperative Work (CSCW), 539–571 (2004) 37. Biemans, R.: Component groupware: a basis for tailorable solutions that can evolve with the supported task. In: Proceedings of the International ICSC Conference on Intelligent Systems and Applications (2000) 38. Wulf, V., Pipek, V., Won, M.: Component-based tailorability: Enabling highly flexible software applications. International Journal of Human-Computer Studies, 1–22 39. Solingen, R., Berghout, E.: The Goal/Question/Metric Method A Practical Guide for Quality Improvement of Software Development. McGraw-Hill, New York (1999)

Identifying the Need to Intervene: Analysis and Representation of Interaction Patterns in Group Programming Learning Thais Castro1,2,3, David Robertson2, Hugo Fuks3, and Alberto Castro1 1

Federal University of Amazonas, Computer Science Department, Manaus, Brazil {thais,alberto}@dcc.ufam.edu.br 2 University of Edinburgh, School of Informatics, Edinburgh, UK [email protected] 3 Pontifical Catholic University of Rio de Janeiro, Rio de Janeiro, Brazil [email protected] Abstract. This paper focuses on a supporting strategy for enhancing distributed and computer-mediated group programming learning. Based on a real-world research setting that started two decades ago, we have exploited a particular context characterized by: (i) a close analysis of artifacts produced by learners; (ii) a collaborative approach to learning, combined with (iii) a team-based approach to programming; and (iv) the use of a Progressive Learning Scheme for group programming learning. These elements are discussed as rationale for the analysis and representation of forum-based discussion logs generated within a case study carried out with first year undergraduate computing students. This analysis allowed us to develop a means of coordinating group programming on a distributed, agent-based platform using group programming stereotypes from conversation analysis. These stereotypes were defined using interaction patterns within a process calculus. Keywords: Collaborative learning, distributed learning environments, improving classroom teaching, teaching/learning strategies, group programming.

1 Introduction Programming learning is a cognitive activity that requires a high level of abstract reasoning [25]. This usually causes students to get stuck somewhere in the introductory course, turning programming learning into a painful experience. In order to mitigate this problem, we take the view that introductory programming courses should make use of collaborative learning methods in addition to usual learning strategies and pedagogical practices. The assumption that supports these methods states that students learn more when they are able to interact with their peers, for achieving a unified solution to a given problem [8]. In undergraduate introductory computing courses the use of internet-based groupware represents broadened opportunities to introduce good practices in the students’ learning process, such as the recording of every interaction among students within their groups while solving exercises and of each student’s code evolution (individually or within her group). Activity recording is an essential requirement for A.S. Vivacqua, C. Gutwin, and M.R.S. Borges (Eds.): CRIWG 2011, LNCS 6969, pp. 158–174, 2011. © Springer-Verlag Berlin Heidelberg 2011

Identifying the Need to Intervene:Analysis and Representation of Interaction Patterns

159

keeping track of their progression, making it possible for the teacher or any other classmate to give appropriate feedback during the exercises. Students who work in groups supported by collaborative Learning Management Systems (LMS) usually produce a large amount of conversation logs including code fragments, footprints of the decision making processes, work methodology and the use of their own development patterns, which might be filtered and categorized to be further analyzed by the teacher and other peers, who may then give students the appropriate feedback. Filtering should be done automatically, by tools which could point out desired or undesired patterns in conversation or code fragments that could lead, in the case of desired patterns, towards the intended goal. An undesired pattern could be identified by analyzing the groups’ conversation logs and then realizing that they are not getting any further in their search for a solution. Using LMS and the sort of filtering tools described above could help to improve students’ abilities to collaborate and to compensate the fact that they are not colocated and therefore lack all the advantages of a face-to-face conversation, such as body language. In order to partially address this issue, we replace students’ interaction described by the logs for a more structured representation, having a collection of conversation patterns as a starting point. These conversation patterns could then be used alongside with any other collaborative programming scenario. The aim of the research reported here is to improve the current supporting strategies for group programming learning described on Section 3. This paper focuses on the analysis of conversation logs for extracting and representing stereotypes on how students organize themselves in order to act under a collaborative scheme. These stereotypes could then be used by the aforementioned software tools for a large class of applications. Our work makes use of a multi-agent environment and its representation language for describing students’ interactions that took place within a LMS. The interaction patterns were represented in LCC (Lightweight Coordination Calculus) [19] which is a language developed to improve coordination in distributed multi-agent platforms. In order to situate the research presented here within its application scenario, we describe its context in the following section based on previous research experiences in programming learning and collaborative systems. Subsection 2.1 presents a few other researches on group programming learning, emphasizing what elements have been used in our work while Subsection 2.2 describes a progressive learning scheme for gradually introducing collaboration into programming learning courses. In Section 3 we describe the case study carried out to analyze the progressive scheme, which generated the conversation logs further analyzed. Continuing the case study description, Subsection 3.1 presents the evaluation method used to analyze the conversation logs, and in Subsection 3.2 they are instantiated and examined. Finally, in Section 4, we identify the need to intervene in students’ interactions.

2 Related Work At UFAM, a Brazilian University, there is an ongoing twenty year experience with introductory programming teaching using the functional programming paradigm. The emphasis is in problem solving, as described in [3]. Besides the functional approach,

160

T. Castro et al.

this research group conducted experiments using collaborative methods to represent problem solving knowledge [13], [16], [22]. It is a common belief [2] that there is a strong link between a software engineer’s performance and her academic background. Thus, in introductory undergraduate programming courses it is mandatory to use techniques based on problem solving, given that problem solving is an essential ability for software engineers. Moreover, given that problem solving is a collaborative activity, training for collaboration is an important part of undergraduate curricula. Thus, in order to collaborate, students should be aware of problem solving strategies. Having that in mind, a pilot study for probing which were the most difficult topics in the introductory course [3] was applied to two freshmen groups in 2004. In their weekly practical class, students got one or two exercises that had been previously solved during the theoretical class. They could consult the Internet or any other bibliography and discuss the exercise with other students or trainees. From roughly 80 students who attended the course, 10 constituted the observation group. The pilot study follow-up was based on a qualitative analysis of their annotations, before and after solving the exercises. After every practical class, the researchers read the students’, trainees’ and research assistants’ annotations (5 assistants observed the observation group while they were solving the exercise). Based on their understanding, researchers triangulated annotations in order to find out which students should be invited for an individual interview. The interview is based on the clinic method protocol, as proposed by Jean Piaget and explained in [8]. During the aforementioned pilot study analysis researchers repeatedly stumbled while following changes done to the code. In order to solve this tracking problem a tool called AAEP [1] was developed for keeping track of the students’ code evolution by the pairing of versions. Later on, for the purpose of classifying code evolution in one of these three categories, namely, syntactic, semantic and refactoring another tool called AcKnow [5] was developed. A new case study aimed at observing how students organized themselves within a group and how each group solved the exercise, revealing that way their major difficulties [4] was conducted in 2007. However, whenever students work in groups it is difficult to know who is responsible for each code fragment and who is collaborating with whom. Besides that, according to the literature in Cognitive Science [7], students learn more when they are organized in groups. Programming is definitively a cognitive activity [25] requiring a special setting, given by the combination AAEP-AcKnow. Based on the findings of this case study, we proposed a group programming progressive learning scheme [6], which gradually introduces collaboration into students’ practical exercises. That was applied to a new case study that took place in 2008, which is the one considered below in this paper. At this point, it is worthwhile to review the literature looking for the many attempts that have been made towards the adoption of collaborative practices in programming learning. Those considered relevant to this work are described in the following subsection. 2.1 Group Programming Learning Freudenberg, Romero & du Boulay [9] define as intermediate talking the pair’s discussion about ‘chunks of code’ during a pair programming session. Their findings point out that both driver and navigator work at the same level of abstraction. On the

Identifying the Need to Intervene:Analysis and Representation of Interaction Patterns

161

opposite way, some articles [14], [12] claim that one of the benefits of using pair programming in introductory courses is the lack of balance in abstraction level between the two actors. Either way, intermediate talk seems to be relevant for programming in pairs. Moreover, whether keeping track of intermediate talks in a pair programming set or more open conversation in a group setting, both approaches emphasize the importance of using computational tools to filter conversation. Stahl [23] describes how the ConcertChat tool was used for group problem solving in maths. It comprises a whiteboard and a chat tool, relating chunks of the chat log to drawings or texts on the whiteboard. This combo avoids vagueness in conversation, fostering collaboration in this way. Stahl uses the term group cognition to refer to the distributed level of cognition among group members. Moving on to pair work, Peres & Meira [17] affirm that whenever students work in pairs supported by a computational tool they build a thinking and action system that positively reflects in their cognition system as a whole. In their work, they evaluate the use of an educational tool by pairs of students using the conversation analysis method [11]. Their findings point out that although there are conversation breakdowns, they did not seem to interfere in the learning process, reassuring this way the importance of keeping track of contextualized conversations and whatever product versions result from them. Pastel [15] presents the use of group programming for program learning. It describes an experiment conducted over four laboratory sessions during a data structure course. Each session proposed a different programming method. In the first one, students had to program individually; in the second they work in pairs, as in a pair programming session; in the third session they discuss their pair programmed codes from the previous session with two colleagues originated from two other pairs for choosing the best code, possibly adding or subtracting bits of code. The final practice takes place within a group of four students that are free to choose whatever method suits them. It is worth mentioning that there was a case study conducted at UFAM in 2007 [4] that achieved similar results to Pastel’s. The commonality found among the aforementioned works is the use of some kind of mechanism for capturing the conversation exchange that takes place among the students for inferring clues that may guide teacher’s intervention in the next session. Based on the comparative literature review described above and after examining the findings of our own previous case studies we have identified the need for some sort of transition scheme, which could encourage students to work collaboratively. This scheme is described next. 2.2 A Programming Progressive Learning Scheme One obstacle that fleshed out from the 2007 case study was the difficulty that freshmen showed in having any initiative and ability to collaborate. Based on the Handbook of Cooperative Learning Methods described in [21] and in the literature about collaborative strategies [13], [16] and [22], we proposed a group programming progressive learning scheme followed by a case study from 2008 for evaluating the scheme [6]. This case study data is used as the basis for the analysis and representation of the interactions in the following sections.

162

T. Castro et al.

Fig. 1. The Programming Progressive Learning Scheme

Figure 1 illustrates the group programming progressive learning scheme adapted from [6] that covers a transition from individual to group programming, in a scenario that begins at phase 1, with preliminary laboratory sessions dealing with introductory problems and clarifications on the methodology. Phase 2 consists of individual solutions and recordings. In phase 3 group work starts by choosing the best individual solution. In phase 4 problem solving turns collaborative: the teacher defines the tasks and the group appoints the actors for each activity. In phase 5 the group’s responsibility encompasses task division. Finally, in phase 6 there is a development task where groups compete in a way that resembles real work situations.

3 A Case Study in Group Programming Learning This case study was conducted during the first semester of 2008 and applied to 60 Computer Science and 50 Computer Engineering first year undergraduate students. As the progressive scheme suggests, each programming topic involves it own representation need, demanding at least one exercise. Thus, it is important to extract information from every activity proposed during the introductory course, inferring the knowledge representation used in each programming topic. Given that the proposed activities imply coding, companion reports and conversation records, the improvement evidences we expected are presented below as supporting strategies for each artifact, apart from the last one, which is traversal to the former three. a. Code evolution: as students make their own attempts at solving the exercise, they keep all code versions in a log for post analysis. AAEP and AcKnow provide a quantitative analysis for each solution, making inferences on the code for identifying

Identifying the Need to Intervene:Analysis and Representation of Interaction Patterns

163

the use of desired or undesired programming techniques, and to make calculations using the timestamps between versions and confronting them with the classification of code changes in order to find out what types of changes students have realized within that time interval. b. Conversation follow-up: for each exercise, students have to agree about task division and the method they are going to use to tackle the problem. Before each code version release there is a discussion, which leads the group to a successful code or to a pitfall. By keeping track of these two conversations, the teacher may preempt a possible pitfall as the conversations take place by giving some advice. c. Report: after finishing the programming exercise, students are required to write an informal report containing, besides the code itself, all the information about the development process. They are encouraged to write about their difficulties and findings. This relevant information must be compared with the resulting information provided by AAEP and AcKnow (see item ‘a’ above) to check whether code improvement is taking place. d. Use of search tools and inference techniques to observe their transition from individual to group solution: this is necessary for evaluating how students cope with the progressive learning scheme. Considering the group programming progressive learning scheme presented earlier in this section, in phases 1 and 2, students start learning how to collaborate using a chat tool. The whole class took part in the discussion, but coding was left as an individual activity. Next, in phase 3, coding remained an individual activity, but by then they had to choose the best code from the group justifying why that code was the chosen one. Almost all groups generated long conversation logs and discussions have run deep in eliciting the requirements for best code candidates. The conversations demonstrated that students were quite comfortable in testing each other’s code by comparing them with the course’s understanding of efficiency and efficacy. In phase 4 they allocated the pre-divided parts of the exercise to all group members and then they discussed about the exercise itself in order to prepare their wiki-based group report (comprising the individual coding and the combined group coding together with the suggested problem solving method). Their forum-based conversation logs show at this point that although some groups could collaborate in a rudimentary way they lacked the ability to solve the problem as a group, passing the responsibility to join code fragments to a self-appointed group member. Almost half of the groups just made available their individual members’ coding. Their logs also showed that group members had no understanding about the exercise as a whole. Only two groups understood the task at hand and really solved the exercise together, suggesting changes in each other’s codes, whenever necessary. One group did not use the forum tool justifying that they had a face-to-face discussion. One other group did nothing. Phase 5 asks the groups to split the exercise into functional parts for distribution among group members. That entailed heated discussions showing that they moved to a next level in their collaboration practices. One possible reason for this improvement was that the groups that previously had difficulties or misunderstandings about how to conduct themselves in a collaborative way, got feedback pointing out where within the problem solving process they were not able to collaborate. Another possible reason was that students got progressively more involved on their activities as they kept solving the exercises posed within the progressive scheme.

164

T. Castro et al.

Phase 6 of the progressive scheme resembles a programming marathon, where they work in small groups of three or four members. In this phase, group formation was left for the students based on their preferences. Surprisingly, not that many new groups were formed. During the four hour collocated marathon record keeping was not mandatory, although they had to write a wiki-based report. Given that too many different digital artifacts were produced during this case study, we opted to focus on the second supporting strategy, the conversation followup, taking into account the overall analyses of the three other supporting strategies. It is worth mentioning that the first supporting strategy was extensively discussed in [5] and the others will be discussed in future work, based mainly on [10] and [18]. 3.1 The Evaluation Method: Representing Interaction Patterns Following the case study application, a conversation analysis took place largely based on the concept of speech acts by Searle [20] and used in this work for finding stereotypes. According to this theory any given student could start a message thread having an intention in mind, for instance, “Hey folks! I’ve done mine and I found out that it was simple”. Here the objective is just to inform, so his utterance could be treated as pertaining to the Informing category. On Table 1, translated from Portuguese, there is a description of each message thread corresponding to an utterance category found in the conversation log, followed by its instance. For the sake of analysis, each group conversation log was shortened based on a local concept of extended speech acts, namely interaction patterns, comprising the initial turn and its relevant complements. They present the teacher with an overall idea about group behavior. Whenever pre-defined categories of interaction patterns were identified the message body was further analyzed in order to check whether the categorized pattern had been correctly identified. We borrow the definition of interaction patterns from [26] which states that they are representations for interactions, described by the sections: name, sensitizing pictures, intent, context, problem, scenario, symptoms, solution, dynamics, rationale, check, danger spots, known uses and related patterns. In this paper we describe our interaction patterns by their name, sensitizing picture and intent, representing them in a representation language (LCC) in order to more easily identify their known uses instantiated by the stereotypes. Table 1. Interaction Patterns and their Instances Category Making an artifact available Informing Clarifying Confirming Asking Suggesting Calling attention Pointing a mistake Explaining

Instance “My functions…” “Guys, the problem isn’t so difficult…” “I couldn’t log in before.” “I’ve annotated it already…” “Does someone want to add something else on the report?” “…everyone should try to create a solution to each question on his own way…” “Hey, Guys! Let’s do the exercise!” “I think you made a mistake when you defined the output as the type int…” “…What I did was to use the 2nd question that…”

Identifying the Need to Intervene:Analysis and Representation of Interaction Patterns

165

Stereotypes are the combination of different interaction patterns. According to the teacher’s analysis, some of these stereotypes have already been identified and classified as good or bad as can be seen on Table 3 in Section 4. Good stereotypes are those that usually lead to a successful collaborative coding effort, while the bad ones are those that lack a collaborative effort, eventually leading just to a member code or even to an incorrect one. In order to more effectively identify and act upon stereotypes, the diagram represented in Figure 2 illustrates how interaction patterns from Table 1 are represented. However, stereotypes do not easily emerge from conversation logs. Two main reasons for that are the occurrence of conversation breakdowns not properly restored within an online discussion and the complexity of natural dialogue. Thus, some structured representation for the discussion would be beneficial to deal with it. One way to address the problem of defining, matching and dealing with stereotypes detected within the forum-based discussion logs is by using a formal representation language with a high dose of expressiveness. A logical-based language designed for dealing with communication protocols in a multi-agent environment was chosen for representing interaction patterns. The LCC (Lightweight Coordinate Calculus) [19] is a notation already used within different applications under a platform named Open Knowledge (www.openk.org) that will help to address the coordination problem. Although being a very expressive language, LCC keeps the simplicity needed to represent the interactions properly by using inference resources provided by the Open Knowledge platform. Typically, as shown in Figure 2, every process starts by a group member deciding to initiate a message thread, triggering that way an interaction pattern. The initiator automatically becomes the coordinator for that interaction pattern. Then a virtual agent called broadcaster broadcasts the message to everyone else subscribed to that conversation. If after having read the message one decides to answer it, she automatically becomes the evaluator by sending the message back to the coordinator via broadcaster.

Fig. 2. Formal Representation for Conversation

166

T. Castro et al.

As can be seen, the elements that appear in Figure 2 show up in the LCC code fragment below, instantiated for the interaction pattern Clarifying. 1 a(clarifier,C) ::= 2 a(broadcaster(X,L,Er),B) <-- new_clarification(X,L). 3 a(broadcaster(X,L,Er),B) ::= 4 (information(X) => a(reader,R) <-- L=[R|Rs] then 5 Er=[E|Es] <-- evaluation(X,E) <= a(reader,R) then 6 a(broadcaster(X,Rs,Es),B)) or 7 null <-- L=[] and E=[]. 8 a(reader,R) ::= 9 information(X) <= a(broadcaster(X,_,_),B) then 10 (evaluation(X,E)=>a(broadcaster(X,_,_),B)<--agree(X,E) or 11 evaluation(X,E)=>a(broadcaster(X,_,_),B)<-do_query(X,E)).

The interaction pattern Clarifying requires three roles: clarifier, who starts the interaction; broadcaster, who sends the message to everyone subscribed to the interaction and reader, who reads the message and can be turned into evaluator, replying to the clarification. In this case the interaction pattern complements are lines 10 and 11. This code fragment could be read as follows: 1. a(clarifier,C)::=. A statement giving the clarifier role an instance ‘C’. The ‘::=’ means the definition of this role starts after it. 2. a(broadcaster(X,L,Er),B) <-- new_clarification(X,L). A statement calling another role instantiated by ‘B’, who will, given some string ‘X’, a list of readers ‘L’ and evaluators ‘Er’, broadcast the message to every agent subscribed to the interaction if there is a new incoming message, represented by ‘new_clarification(X,L)’. 3. a(broadcaster(X,L,Er),B) ::=. Gives the broadcaster role the identifier ‘B’ and after that its definition is started. 4. (information(X) => a(reader,R) <-- L=[R|Rs] then. Sends the information ‘X’ to a reader if there are readers in the list ‘L’. 5. Er=[E|Es] <-- evaluation(X,E) <= a(reader,R) then. Builds a list of evaluators ‘Er’ if a reader ‘R’ sends an evaluation ‘E’ referring to the information ‘X’. 6. a(broadcaster(X,Rs,Es),B)) or. Calls the broadcaster again for the next readers ‘Rs’ and evaluators ‘Es’. 7. null <-- L=[] and E=[]. This statement turns to null value when there aren’t any more readers or evaluators in the lists ‘L’ and ‘E’. 8. a(reader,R) ::=. Similar to the clarifiers, this statement gives the reader role an instance ‘R’. 9. information(X) <= a(broadcaster(X,_,_),B) then. The information ‘X’ is received from the broadcaster ‘B’. 10. evaluation(X,E) => a(broadcaster(X,_,_),B) <-- agree(X,E) or. It is valid if the reader agrees to the information ‘X’, sending some short agreeing statement. 11. evaluation(X,E) => a(broadcaster(X,_,_),B) <-- do_query(X,E)). If the previous statement is not true, the reader doesn’t agree with the information ‘X’ and he sends a query ‘do_query’ containing his evaluation ‘E’, possibly a query.

Identifying the Need to Intervene:Analysis and Representation of Interaction Patterns

167

Other interaction patterns ask for different complements. There are cases, such as Informing that requires more than one kind of reply. However, there are cases such as Making an Artifact Available that not necessarily have any complement. The teacher analyzes the interaction patterns presented by each group and define whatever sequence she considers successful as a stereotype. A knowledge base is then created for each exercise comprising the group conversation log, interaction patterns and stereotypes. Whenever an unidentified stereotype shows up during the forumbased conversation, the teacher has to look at the case in depth and give feedback to the group before the task is completed. She may then include the new stereotype in the knowledge base. The analysis presented in the next subsection shows how identifying the interaction patterns in the forum-based logs make them more traceable for further interventions. 3.2 Identifying Interaction Patterns in the Forum-Based Discussion Phase 4 of the progressive scheme presented in Figure 1 stands as a bottleneck because for the first time during the course, students are urged to think about a whole problem and its solution collectively. During the problem solving process they have to accommodate each other’s views and negotiate whenever there is a conflict of understanding. The conversation fragments below refer to exercise 5, a classical allocation problem. It is worth noticing that the teacher proposes a specific method for solving it. Some groups adapted that method in order to solve the exercise according to their own characteristics. All conversation logs shown below were translated from Portuguese. Hence, some misspellings and inappropriate use of English were placed in the text to give the reader a more accurate view of the conversation. Group 1 neither discussed the problem understanding nor the problem solving, missing the division of work and the process of joining all the individual solutions together to build a unique group solution; each group member made available his own solution. This group’s behavior could be represented by a sequence of Making an Artifact Available interaction pattern. They produced individualized solutions and it can be seen from their codes that there was no overall agreement or understanding about the problem as a whole. One member of group 2, in a self-appointed way, led the group. Another one assumed the division of work. The forum-based discussion about the general understanding was rudimentary, gaining some strength whenever the matter was the coding. The last topic in the conversation log dealt with suggestions. The leader (StD2) examined all codes and pointed out what could be improved in a specific one, as shown in fragment below. StK2 HAS TO CORRECT THE FUNCTION AND TO REDO POLYA’S STEPS, StD2 AND StF1 HAVE TO CORRECT POLYA’S STEPS. StD21, I’ve already written above what is necessary in your case. StF2, the inputs are a list of tuples, even when the function you’re working with uses the previous function’s result. I’ve corrected there in Polya’s steps. E.g.: Inputs: [("dr. A", 4, 23), ("dr. B", 1, 13), ("dr. C", 3, 27)]. Outputs "dr. B" StK2, your function is wrong, it has to return the complete list of tuples, as the doctor’s tuple required in the input will have the 2nd term -1 and the last one will be the number of the patient added to the input.

168

T. Castro et al.

Examples: Inputs: "dr. A" 28 [("dr. A", 4, 23), ("dr. B", 1, 13), ("dr. C", 3, 27)] Outputs: [("dr. A", 3, 28), ("dr. B", 1, 13), ("dr. C", 3, 27)]

In the conversation fragment above dealing with the coding a proper conversation takes place. The group discussion begins with the interaction patterns Asking and Explaining followed by Making an Artifact Available or Suggesting. This is a much desired stereotype that led the group to an excellent result. Group 3 basically followed the same route: one student was self-appointed as group leader and was responsible for the division of work. The forum-based discussion regarding the coding started with a General Question about the understanding of the exercise that the leader emailed to the teacher. At some point, a student made available his code and report and it apparently made another student uncomfortable. She reacted by immediately posing a question, starting with a Clarifying, as shown in the fragment below. StV3

Hey folks! I’ve done mine and I found out that it was simple. (Clarifying) aux_lesses x xs = [ y | y <- xs , y < x ] index_less xs = [i | i <- [0..length xs-1], aux_menores (xs!!i) xs == []] But even if it was simple, I’d like you to look at the end of the function "index_less xs" ( aux_lesses (xs!!i) xs == []), ‘cause it was there where I had more difficulties. I was trying to do ... StF3 Well, mine was pretty short, I thought it was odd, but I think it is complete, as it was a simple question. What I did was to use the 2nd question that shows the lowest indices and use them to show the doctor with fewer patients. It follows: doctors_fewer_patients = disp!! index_less StV3 Man, explain that in details….

Group 4 had more than one member leading the group. One student proposed a topic about some peculiarity she has found in the exercise. Based on that, another one discussed the nature of the exercise and a third one suggested a slightly different problem solving method from the one proposed by the teacher. Everybody followed the third member’s suggestion triggering discussions about each other’s solution. The fragment below registers the moment that a student figures out the nature of the exercise. Then, another one proposes a way to do it gaining the leadership of the solving process. StJ4

… StR4

I think the problem is sequential… I believe the best way of dealing with the exercise is doing it sequentially, each function reusing the previous functions, creating extra ones, when it is the case. … As far as I can see everybody in the group agrees about the fact that the problem is sequential and consequently reuses every item in the following... So, because there is not much time left, ideally everyone should try to create a solution to each question on his own way, and then we separate the best ones, to combine them in order to write one group solution…

Identifying the Need to Intervene:Analysis and Representation of Interaction Patterns

169

Despite the fact that there were two initial antagonistic ideas for solving the exercise as a group, the leading members have found an agreeable way of doing it, addressing the discussion with many Suggesting after some Informing and Clarifying. It proved to be a good way of dealing with different opinions, but it took longer than necessary. The group achieved a good result, but with an extra help from the teacher, they would have probably reached an agreement earlier in time and would have solved the exercise faster. All members of Group 5 made their codes available straight away and this seemed to be the result of a face-to-face conversation. Apparently, from the fragment below, the forum tool was only used to call one member to join the chat session. StR5

We are elaborating the report with all the functions you did. StY5 and I need you to join the chat session we’ve created to discuss this exercise because here in the forum it takes too long.

Group 6 did not discuss the exercise as a whole, keeping the conversation restricted to two members and only about the last item of the exercise. Group 7 roughly followed groups 2 and 3 way of solving the exercise. One student led the discussion making his code available and asking for the division of work. Another student subdivided the work and asked everyone else to make their solutions available as soon as possible, together with their respective explanations. All members complied. A third member of the group read all the codes, finding a mistake and its probable cause. Something that deserves attention is that at the end of the forum-based discussion, one student remarked that he had not done his part yet but needed no help. Only at the very end of the discussion he made his solution available. This group came up with another successful stereotype, beginning the forum-based discussion with Asking, followed by Making an Artifact Available, Suggesting and Explaining, and finishing with Making an Artifact Available. The group achieved an overall great result, using all required data structures and following the suggested way to solve the exercise. Initially, Group 8 discussed about General Questions related to the exercise. One member complied with another member’s Suggestion and everyone else continued reusing each others’ functions, although some other questions about the exercise were posed. The group remained collaborating, except for one member, who did not take part in the forum-based conversation. From the fragment shown below, it is clear that he did his part without reusing or revising the functions that had been made available. StF8

I’ve done the 5th question. As I haven’t use the codes which have been done before my code is big, but, basically it has the same functions done until the 4th one.

Unusually, there were too many Asking interaction patterns during the forumbased discussion. However, the discussion also had many Making an Artifact Available and Explaining intercalated with the Asking(s), which proved to be another good stereotype. Group 9 presented a bad stereotype similar to Group 1, but with absolutely no discussion. Everyone made his own codes available and one member was responsible for the tests and group solution.

170

T. Castro et al.

Group 10 didn’t do the exercise. The way each group worked on their first group exercise fleshes out clues about the causes of possible difficulties in collaboration and also evidences of successful use of an informal collaboration method. In the aforementioned description of the way each group collaborated while solving exercise 5, most of the groups tried to collaborate and behave as a group, but they did not achieve group programming nirvana, i.e., they tried but they didn’t get there because they did not discuss each other’s approach for the exercise. The code fragments were mostly individualized solutions. However, the registering of the group exercises were very helpful because they made it clear for the teacher how to identify each group’s difficulties, helping her to intervene whenever it deemed necessary, s preparing them for the next exercise. Other groups, namely Groups 2 and 4, performed their work without any difficulties. Group 4 even used a new problem solving method, which was beyond the expectation at this point. Groups 1 and 9 completely ignored the fact they were doing their exercise as a group and only Group 10 failed to do the exercise. In the following section there is a discussion informing teachers on how to deal with the emerging stereotypes from the forum-based discussion logs in order to properly intervene when using the group programming progressive learning scheme.

4 Identifying the Need to Intervene Basically, in order to know when to intervene teachers should always: (i) identify the students who are not corresponding to their expected participation within their groups, because that entails that these students have some difficulties in performing the required task; (ii) identify the bad stereotypes, aiming at helping students whenever they get stuck. Teachers’ observation should focus on: the relationship among interaction patterns presented on Table 1, the group programming progressive learning scheme used as guidance for the exercises posed during the introductory course, the roles students perform within their groups and the identification of stereotypes that act as guidelines for teacher’s intervention. The clues for intervention emerge whenever: (i) an interaction pattern repetitively appears within the forum-based discussion; (ii) only one or two group members hold the floor, even if they are using different interaction patterns and (iii) the combination of interaction patterns fosters bad stereotypes. Table 2 describes the clues extracted from the forum-based discussion for the first case (i) showing the corresponding intervention. Table 2. Clues for Acting Upon Repetitive Interaction Patterns (Case(i)) Interaction Pattern Clue Intervention Making an Artifact There is no turn taking Tell group members to inspect each Available other’s code Informing Wasting time with irrelevant Tell group members to restart the issues discussion Asking Lack of leadership Tell group members to choose a leader

Identifying the Need to Intervene:Analysis and Representation of Interaction Patterns

171

In case (ii), when only one or two group members hold the floor, the clues for intervention come from noticing that a couple of senders dominate the forum-based discussion. In case (iii), when the combination of interaction patterns doesn’t lead to collaboration, group members are probably on a wrong path caused by a bad stereotype. Table 3 describes the clues extracted from the forum-based discussion for case (iii) showing the corresponding interventions. Table 3. Clues for acting upon the stereotypes (case (iii)) Stereotype

Clue

Intervention

Asking, Calling When this stereotype appears before a Making an Tell group members to Attention and Artifact Available takes place or if it loops for subdivide the task as Suggesting approximately 10 turns, the group is struggling to recommended. understand the task Informing, Clarifying

They have difficulties in focusing on the exercise, thus they are not really solving the task. Instead of it, they’re either talking about something not that relevant or about some other unrelated subject

Tell group members to pick whatever is relevant for completing the task and focus on the developing process.

Working with a computational representation for stereotypes, it is possible, just by examining the forum-based discussion, to find potential pitfalls while the groups are still in the process of finding a solution for an exercise. In this case, when such feedback opportunity is identified, and according to an existing knowledge base, the teacher can intervene in the process, helping to improve collaboration within the group. This way, groups achieve a more accurate solution, as it happens with any other collaborative activity [24].

5 Conclusion Web-based environments, especially LMSs, are important resources for supporting both conventional and distance learning, whatever the educational setting considered. This intense and diverse use of LMS’ interaction tools might present unexpected obstacles for their users, as the breakdowns that occur on the logical sequences within a conversation due to synchronization differences, but might also present new opportunities for intervention and support during collaborative learning activities. In this paper, we proposed a web-based record-oriented collaborative and progressive scheme to allow knowledge elicitation on the learning process of group programming and identification of opportunities for teacher’s intervention. First, we showed how the progressive learning scheme could be used to incrementally advance students towards collaboration in group programming learning. Moving from individual coding solutions to group solutions using forum-based discussions as a means for supporting problem clarification, task division and the coding process, successful group members understand that collaboration is the way to go.

172

T. Castro et al.

Then, inspired by the speech acts theory we proposed a set of interaction patterns as a means for identifying the underlying intention in group members’ turns within the forum-based discussion. Starting by figuring out the intention behind group members’ posts, the researcher looks for the initial turn and its relevant complements that comprise the interaction pattern. Good stereotypes are sequences of interaction patterns that show up within the forum-based discussion whenever members successfully collaborate for reaching a group coding solution. Whenever bad or uncategorized stereotypes show up within the conversation, an intervention opportunity emerges. For instance, the repetitive use of an interaction pattern within the forum-based discussion log offers opportunities for teacher’s intervention given that it is expected that these patterns vary during turn taking, engaging all group members in the solving process. For instance, during the discussion that took place to solve exercise 5 some groups started repetitively using the Making an Artifact Available interaction pattern, without any further commentary. That gave the teacher a clue for intervention, immediately calling the groups’ attention for the need to collaborate. According to the progressive scheme, instead of just making one’s code available, students should collaborate discussing all individual codes in order to arrive at a unified code solution. Programming learning, like many other intellectual activities, benefit from collaboration. However, group programming learning also has to tackle several difficulties that turn up when developing abilities related to effective group participation. These difficulties are not always easily identified whereas the groups are still discussing about the task itself. The deployment of the group programming progressive learning scheme gives the teacher a collection of inspection points where she is able to identify difficulties, as those concerning conversation breakdowns, acting on individuals or groups whenever she deems necessary. These inspection points, represented here by a set of interaction patterns, can be inferred and treated automatically, thus, generating automatic responses for the groups. We treated the interaction patterns automatically, representing them in LCC, contributing towards run time interventions from any actor involved in the process and consequently, the creation and further maintenance of a knowledge base about group programming learning. In the exercises that followed exercise 5 discussed here, some groups presented similar bad stereotypes in their conversation logs, needing the same type of intervention. This strengthens the idea of keeping a knowledge based framework with supporting strategies, methodologies like the progressive scheme and a set of interaction patterns in order to identify new stereotypes. Stereotypes should be continuously added to the knowledge-based framework in order to be transformed into group programming learning intervention’s heuristics in the future. The ultimate aim of the approach is, in addition to enhancing group programming learning, to decrease teachers’ workload; to improve their ability to supply feedback and thus to improve overall learning outcomes. Acknowledgments. Hugo Fuks has a research grant from CNPq and “Cientista do Nosso Estado” grant from FAPERJ. This work used resources from GroupwareMining Project – Proc.575553/2008-1, CNPq/CT-Amazônia n.055/2008.

Identifying the Need to Intervene:Analysis and Representation of Interaction Patterns

173

References 1. Almeida, N.F.A., Castro, T., Castro, A.N.: Utilizando o Método Clínico Piagetiano para Acompanhar a Aprendizagem de Programação. In: The Proc. of the XVII SBIE, vol. 17, pp. 184–193. Gráfica e Editora Positiva Ltda, Brasília (2006) 2. Brooks, F.: The Mythical Man-Month (anniversary edition). Addison-Wesley Longman Publishing Co., Amsterdam (1995) 3. Castro, T., Castro, A.N., Oliveira, R.S.C., Boeres, M.C.S., Menezes, C.S.: Enhancing Programming Understanding through Conceptual Schemas in Introductory Courses. CLEI Electronic Journal 8(2), 4 (2005), http://www.clei.cl/cleiej/ 4. Castro, T., Fuks, H., Spósito, M., Castro, A.: The Analysis of a Case Study for Group Programming Learning. In: Castro, T., Fuks, H., Spósito, M., Castro, A. (eds.) ICALT, Proc. of the 8th IEEE International Conference on Advanced Learning Technologies, Santander, Spain, July 1-5 (2008) 5. Castro, T., Fuks, H., Castro, A.: Detecting Code Evolution in Programming Learning. In: Zaverucha, G., da Costa, A.L. (eds.) SBIA 2008. LNCS (LNAI), vol. 5249, pp. 145–156. Springer, Heidelberg (2008) 6. Castro, T., Fuks, H., Castro, A.: Programming in Groups: a Progression Learning Scheme from the Individual to the Group. In: FIE, Proc. of the 38th Annual Frontiers in Education Conference, IEEE Catalog Number, vol. F1F15-F1F20 (2008) 7. Cohen, S.: What Makes Teams Work: Group Effectiveness Research from the Shop Floor to the Executive Suite. Journal of Management 23(3), 239–290 (1997) 8. Delval, J.: Introdução à Prática do Método Clínico: descobrindo o pensamento das crianças. ARTMED Press (2002) 9. Freudenberg, S., Romero, P., du Boulay, B.: Talking the talk: Is intermediate-level conversation the key to the pair programming success story? In: Proc. of Agile 2007, pp. 84–91. IEEE Computer Society, Los Alamitos (2007) 10. Gerosa, M.A., Pimentel, M.G., Fuks, H., de Lucena, C.J.P.: Development of Groupware Based on the 3C Collaboration Model and Component Technology. In: Dimitriadis, Y.A., Zigurs, I., Gómez-Sánchez, E. (eds.) CRIWG 2006. LNCS, vol. 4154, pp. 302–309. Springer, Heidelberg (2006) 11. Hutchley, I., Wooffitt, R.: Conversation Analysis, 2nd edn. Polity Press, USA (2008) 12. McDowell, C., Werner, L., Bullock, H., Fernald, J.: The Impact of Pair Programming on Student Performance, Perception and Persistence. In: The Proc. of the International Conference on Software Engineering, p. 602 (2004) 13. Mendonça, A.P., Castro, A.N., Mota, E.S., Silva, L.S., Pereira, V.L.S.: Uma Experiência com o uso de Mapas Conceituais para Apoiar o Método da Controvérsia Acadêmica. In: XXII CSBC - VIII WIE, vol. 5, pp. 99–107. SBC Press, Florianópolis-SC-BR (2002) 14. Nagappan, N., Williams, L., Ferzli, M., Wiebe, E., Yang, K., Miller, C., Balik, S.: Improving the CS1 experience with pair programming. In: Proceedings of the 34th SIGCSE Technical Symposium on Computer Science Education, pp. 359–362 (2003) 15. Pastel, R.: Student assessment of group laboratories in a data structures course. Journal of Computing Sciences in Colleges 22(1), 221–230 (2006) 16. Pereira, V.L.S., Castro, A.N., Mendonça, A.P., Silva, L.S.: Análise do método Jigsaw de aprendizagem cooperativa através da utilização de mapas conceituais. In: XXII CSBC VIII WIE, vol. 5, pp. 181–188. SBC, Florianópolis-SC (2002) 17. Peres, F., Meira, L.: Educational software evaluation centered on dialogue: interface, collaboration and scientific concepts. In: Proceedings of the Latin American Conference on Human-Computer Interaction, pp. 97–106 (2003)

174

T. Castro et al.

18. Pimentel, M., Escovedo, T., Fuks, H., Lucena, C.J.P.: Investigating the assessment of learners’ participation in asynchronous conference of an online course. In: 22nd ICDE World Conference on Distance Education, September 3-6. ABED, Brazil (2006) 19. Robertson, D.: Multi-agent Coordination as Distributed Logic Programming. In: Demoen, B., Lifschitz, V. (eds.) ICLP 2004. LNCS, vol. 3132, pp. 416–430. Springer, Heidelberg (2004) 20. Searle, J.: Speech Acts: an Essay in the Philosophy of Language, 1st edn. Cambridge University Press, Cambridge (1969); 31st printing 21. Sharan, S.: Handbook of Cooperative Learning Methods. The Greenwood educators reference collection.Praeger Publishers (1999) 22. Silva, L.S., Castro, A.N., Mendonça, A.P., Pereira, V.L.S.: Mapas Conceituais como suporte à estratégia de Investigação em Grupo: Uma experiência na Universidade. In: XXII CSBC - VIII WIE, vol. 5, pp. 163–172. Florianópolis-SC. SBC (2002) 23. Stahl, G.: Supporting group cognition in an online math community: a cognitive tool for small-group referencing in text chat. Journal of Educational Computing Research (2006) 24. Vygotsky, L.S.: Mind in Society: the Development of Higher Psychological Processes. Harvard University Press, London (1978) 25. Weinberg, G.: The Psychology of Computer Programming. Computer Science Series. Litton Educational Publishing (1971) 26. Schummer, T., Lukosch, S.: Patterns for Computer-Mediated Interaction. Wiley Software Patterns Series (2007)

A Collaboration Support Environment for Decision Enhancement in Business Process Improvement Mercy Amiyo and Josephine Nabukenya School of Computing and Informatics Techonology, Makerere University, Uganda {mamiyo,josephine}@cit.mak.ac.ug

Abstract. Continuous Business Process Improvement (BPI) in light of increased business process agility demand necessitates continuous process analysis and exploration of several improvement alternatives. These activities are knowledge intensive thus require multi-disciplinary skills. Furthermore, the cross-cutting nature of business processes as a result of having several people working on related activities in order to attain business goals necessitates collaboration among stakeholders in any business process improvement effort. However current suites provide limited to no support for this kind of collaboration especially in the decision process involved. In light of this, we designed a decision enhancement studio environment consisting of 4 suites to support collaboration, business process analysis and dissemination of information in order to enhance group decision making and achieve business process agility. Evaluation results from testing sessions at two organisations show that the BPI alternative exploration collaboration process supported by the analysis tools and group support systems provides a BPI decision enhancement studio which is a suitable environment to generate and select a BPI alternative. The BPI Decision enhancement studio is thus useable and useful for collaboration support in the BPI decision process. Keywords: Business Process Improvement, Business Process Agility, Collaboration Support, Decision Enhancement, Studio.

1 Introduction Business process agility (BPA) is the ability to ‘swiftly’ and appropriately adjust a set of related activities performed to achieve a given business goal in response to unpredictable internal and external changes that occur in a business environment, beyond the normal level of ‘flexibility’ [1]. The ever changing business environment has increased the demand for BPA in organisations today thus many BPM suites [15, 2, 24] consisting of tools and/or services that support each step in a business process life-cycle have been developed [14]. These suites facilitate business process agility by providing means to easily and flexibly monitor the performance of a business process, and to modify the business process model [15, 2, 14]. Most of them concentrate on enabling the flexible adjustment of business rules within their business processes. Examples include Corticon business rule management studio [7], the IBM BPM suite, that focuses on business measures and business rules points of agility [15] and the BizAgi suite that supports the whole business process life-cycle [2]. A.S. Vivacqua, C. Gutwin, and M.R.S. Borges (Eds.): CRIWG 2011, LNCS 6969, pp. 175–190, 2011. © Springer-Verlag Berlin Heidelberg 2011

176

M. Amiyo and J. Nabukenya

To improve or to further support business process agility, BPM suites have been combined with other technologies such as Service Oriented Architecture (SOA) [6, 8, 16, 14, 18], Event Driven Architecture (EDA) [6, 11] and Collaborative tools [6]. This advancement improved BPA by increasing flexibility [8, 18, 16], support for sense-and-respond patterns [5], extension of limited visibility offered by business activity monitoring dashboards [6] and improvement of communication between SOA services [11, 19]. However, most of these BPM suites do not support collaborative interactions between stakeholders yet, considering that BPM activities such as analyzing and exploring ways of improving a business process require intensive knowledge, involvement of and collaboration among key stakeholders to achieving business process agility [2, 6]. To bridge this gap, research in Collaborative BPM was begun to support collaborative interactions that may take place during the execution of business processes [6]. So far it has been used in three areas; Exception Handling, Case Management and Research process [6]. To this end, we sought to design a Business Process Improvement (BPI) decision enhancement studio to provide an environment to support stakeholder involvement, collaboration and sharing of knowledge to perform this process. A studio has been defined by Keen and Sol [17] as an environment or shared space or forum, which contains a set of integrated tools/technologies that enable stakeholders (people) to interactively collaborate to generate and analyze ‘what-if’ scenarios of the possible solutions to a given problem. An overview of challenges facing collaboration in business process improvement is presented in the following section. Following the design science research approach in section 3, the BPI decision enhancement studio was designed. This design has been detailed in section 4. A prototype of the studio was developed and tested using two case studies described in section 5. Also in this section, the test results and an evaluation are given. We conclude the paper giving directions for future work.

2 Collaboration and Business Process Improvement: Challenges Based on the preceding discussion, we observe that the involvement and collaboration of business process stakeholders is thus paramount for successful and continuous business process improvement [10, 3, 2]. This is so because of the cross-cutting nature of business processes; several people take part at different stages of the business process and thus any changes in the business process would have effect on the various stakeholders. Additionally continuous BPI, is knowledge intensive and calls for multiple skills and expertise. Notwithstanding the various approaches and BPM suites that have been developed to provide BPA as described in the previous section, the aspects of stakeholder involvement and collaboration have received minimal support. This can be attributed to the limited support for collaborative BPM in the recent past [6] though it is observed that collaborative BPM has since then become a fast rising research area [3, 6]. In addition, coordinating the process of BPI to continuously adapt to new conditions needs to be carefully managed to avoid chaos. Involving stakeholders and top management in the decision process involved in business process analysis and BPI alternative exploration would increase their commitment and acceptability of

A Collaboration Support Environment for Decision Enhancement in BPI

177

business process changes. Better still, Muehlen and Ho [21] reiterate that lack of/poor communication between BPM stakeholders and participants as a risk or problem that affects all the phases of a business process’ lifecycle; which includes its analysis and improvement. BPM collaboration thus remains a key challenge in BPM research and is commonly manifested as poor stakeholder involvement or insufficient participation of top management [10] due to limited support for this decision process. Thus far, there is a need to support collaboration among and participation of stakeholders in the decision process of exploring BPI alternatives in response to the identified changes in a business environment or identified improvement opportunities and consequently improving business process agility.

3 Research Approach The research was carried out following the Design Science (DS) research method. DS was selected because it is a problem-solving paradigm that aims at stressing ‘utility of artifacts’ [25, 4, 12]. The method consists of three cycles namely, the relevance cycle, the design cycle also known as the ‘build-and-evaluate loop’, and the rigor cycle [25, 13, 4, 12]. Following the relevance cycle, the researcher explored a case’s business environment in order to gain an in-depth understanding with respect to BPA [1]. Interviews were used to gather information on the factors leading to change and those affecting the decision process involved in exploring business process improvement alternatives in response to the identified changes. Functional requirements were derived from the collected data. In the rigor cycle, existing literature was reviewed in order to affirm our research inquiry (how to improve decision process in BPI using collaboration support) and identify tools and techniques that would be used in the decision enhancement studio to support the activities and decision process involved in exploration of business process improvement alternatives. In the design cycle, the studio functional requirements from the relevance cycle and the tools and techniques identified in the rigor cycle were used in designing the decision enhancement studio. The studio was then tested using interviews, simulations, walk-through sessions, questionnaires and two case studies. The questionnaires use the five-point likert scale ranging from very hard or very poor (1) to very easy or very good (5), and polar questions expecting yes/no answers. They were first pre-tested by purposively selected respondents from different organisations and refined accordingly. Case 1 – Makerere University (Mak.) is a national public university, established on the 1st of July 1970. Since then it has seen growth in the number of students and undergraduate and postgraduate programmes being offered. The current student population is about 33,000 distributed among the 8 Colleges and 2 Schools. Respondents used in the testing included one deputy Registrar, two registration Coordinators, one staff member from the Admission and Records division, one faculty registrar and three assistants, one student and 2 observers. Case 2 – Uganda Revenue Authority (URA) is a government organisation mandated to collect non-tax revenue, and taxes from individuals, companies and other organisations on behalf of the government of Uganda. Since 1991, it is responsible for assessing and collecting specified revenue, administering and enforcing tax laws within the boundaries of the Uganda Revenue Authority Statute. The target groups

178

M. Amiyo and J. Nabukenya

used during the testing sessions were staff members from the Business Process Reengineering (BPR) team, representatives from the service desk and two observers.

4 Design of the BPI Decision Enhancement Studio From the exploratory study [1], several challenges were identified including; limited stakeholder participation, poor information flow, rigidity in the decision-making process, bureaucracy, lack of enough and/or current information and the need to cut costs [1] among others. From these, we derived functional requirements that could be used to design the Business Process Improvement (BPI) decision enhancement studio; (i) Enable in-depth workflow analysis giving insight into the performance and behaviour of a business process, (ii) Support risk assessment of an organization’s business process, (iii) Enable multiple stakeholder participation in the generation and exploration of improvement alternatives, risk assessment, and decision making; additionally enhance their willingness, commitment and motivation to take part in the process. Allow for manipulation through interaction with the business process model, (iv) Enable the simulation of the different possible modifications/improvement to a business process, (v) Provide visualization of the analysis reports/results, and (vi) Provide a means of disseminating or sharing of information among concerned stakeholders about decisions made (action points and responsibilities). The BPI decision enhancement studio was designed to provide the required functionality and collaboration support through four suites (see Fig. 1): Risk Assessment, Workflow Analysis, BPI Exploration and Communication Suites. (i) Risk Assessment Suite. This suite provides support for analyzing risks in a business process. Risk Assessment is considered an important aspect for business process improvement as identified risks give insight to stakeholders involved in the exploration of alternatives on how to improve their business processes [23]. This is due to robustness with regard to decisions that risk management provides that in turn enhances business process agility [23]. Identification of a risk gives stakeholders an opportunity to avoid unwanted consequences, manage the occurrence of an unwanted occurrence or to get ways of mitigating them. In addition, it provides them with an opportunity to improve their business process in response; re-designing or making adjustments to a business process reduces or even eliminates the occurrence of a given risk [21]. Risk management just like business process management necessitates interaction between different stakeholders at different levels of an organisation [6, 21]. In light of this, the risk management collaboration process designed by Briggs, Grinsven and Vreede [9, 26] was adopted to provide support for collaboration during the risk identification, assessment and mitigation activities (see Fig. 2). In the risk identification activity, stakeholders collaboratively analyze the business process and additional information gathered from different stakeholders who interact with the business process, to identify risks under different themes following the risk identification module of the risk management collaboration process. Once risks have been identified, stakeholders collaboratively develop metrics for corresponding risks to act as risk indicators for newly identified risks. Risk indicators are used as a basis for analyzing business process risks. This is done following the left most branch of

A Collaboration Support Environment for Decision Enhancement in BPI

179

the risk assessment module of the risk management collaboration process in Fig. 2. During risk analysis, risk levels are identified and stakeholders collaboratively generate recommendations by discussing the identified risk levels with the aim of generating mitigation or control measures following the risk mitigation module of the risk management collaboration process in Fig. 2.

Fig. 1. Global Design of Decision Enhancement Studio for Improving Business Processes Agility Source: [1]. Analysis reports from the Risk Assessment and Workflow Analysis suites are submitted to stakeholders who use the Suite for Exploration of Improvement Alternatives (a.k.a BPI Exploration suite) to generate BPI alternatives. The risks and performance of the BPI alternatives are evaluated using the Risk Assessment and Workflow Analysis suites respectively.

(ii) Workflow Analysis (WFA) Suite. The main purpose of process/workflow analysis is to understand the performance and behavior of a business process. The business process is analyzed as shown in the activity flow diagram in Fig. 3.

180

M. Amiyo and J. Nabukenya

Fig. 2. Repeatable Collaborative Risk Management Process (Source: Adopted from [26]). Consists of 3 modules; risk identification, risk assessment and risk mitigation. Rounded rectangles represent the thinkLet specifying the activity, think pattern and thinkLet name. The circles represent a decision while the arcs represent the direction flow.

A Collaboration Support Environment for Decision Enhancement in BPI

181

Event logs generated during the execution of a business process, its specification and additional information are used as input into the workflow analysis activity. The first step in analyzing a business process is to ensure that the event logs are in a format that is readable by the workflow analysis tool. If data is not in the Mining eXtensible Mark-up Language (MXML) format it is converted MXML at the Process Data step. The MXML event logs are then mined to Discover the as-is process model. The third step is to Analyze the as-is process model to gain insight into the performance (bottlenecks, process flow time, resource utilization) and behaviour of the mined model. The output of each analysis is exported and compiled to Generate an Analysis Report.

Fig. 3. The activity flow diagram for the Workflow Analysis Process; Rounded rectangles represent activities. The diamond shape represents a decision while the arcs represent the direction flow.

In the case of evaluating BPI alternatives, the first step is to Generate improved business process models (i.e. simulation models) depicting the proposed improvement (adjustments/modifications). This involves the discovery of a simulation model following the procedure described by Rozinat et al. [22]. The discovered simulation model is then exported into the simulation tool and later modified to reflect the proposed improvements. The generated improved business process’ models are verified to ensure that they have no errors in them. Simulation Experiments are then

182

M. Amiyo and J. Nabukenya

carried to generate event logs that are converted into the MXML format. From the simulated event logs business process models associated with each BPI alternative are mined and analyzed to acquire insight of their performance and behaviour. An analysis report that contains information on the performance indicators that have been analyzed and their corresponding result for all the BPI alternatives is generated. This report is used by the stakeholders to make a decision on which BPI alternative to implement. (iii). BPI Exploration Suite. This suite consists of a collaboration process to guide and support stakeholders in the generation of BPI alternatives and the selection of a satisfactory alternative. Using information output from the Risk Assessment and the Workflow Analysis activities plus relevant additional data, stakeholders work jointly together to generate BPI alternatives following the BPI alternative exploration collaboration process shown in Fig. 4. Following the BPI alternative generation module, participating stakeholders first review the provided information, brainstorm on areas of the business process that need to be improved. This list of improvement areas is refined to remain with key areas. Secondly, once the area(s) of a process to be improved have been identified, stakeholders then generate ideas on how the identified business process aspect(s) can be improved. The generated list is then refined getting rid of redundant ideas. Thereafter stakeholders select the most feasible alternative solutions from the refined list and submit them for evaluation; workflow analysis and risk assessment. Risk assessment of the proposed BPI alternatives, and workflow process analysis are then performed in parallel. Analysis reports from these activities are generated and submitted to the people responsible for making decisions on business process improvement. On receiving the risk assessment and workflow analysis reports of the proposed BPI alternatives, the group of stakeholders meet to select a suitable BPI alternative to implement following the BPI alternative selection module of the collaboration process (see Fig. 4). This is done by first reviewing the risk assessment and workflow analysis reports for each of the improvement alternatives to evaluate how each BPI alternative improves the identified business process aspect. The BPI alternative that satisfactorily (in terms of risk and performance) improves the identified aspect of the business process is then selected. (iv). Communication Suite. This suite provides an interface through which stakeholders can communicate their decisions to the people responsible for implementing the improvement once a business process improvement alternative has been selected.

5 Studio Implementation 5.1 The Decision Enhancement Environment Support Tools To support conducting of the collaboration processes in the risk assessment (Fig. 2.) and BPI alternative exploration (Fig. 4) of suites respectively, MeetingWorks version

A Collaboration Support Environment for Decision Enhancement in BPI

183

7.0 Group Support System (GSS) was used. For the WFA, the Process Mining (ProM) Framework that supports business process mining and analysis; Coloured PetriNet (CPN) tools for the simulation; the PromImport Framework and XESame to support conversion execution logs into the MXML were utilized (see Fig. 5).

Fig. 4. The BPI Alternative Exploration Collaboration Process

5.2 Prototype Implementation A prototype of the designed studio was implemented using Java programming language. An interface through which the four BPI decision enhancement studio suites are accessed was developed as shown in Fig. 6. Each suite is comprised of a set of tools that support the different activities discussed in the previous section. WFA Suite: On clicking the Workflow Analysis Suite button, a user is presented with a drop down menu with options to Analyze or Simulate. Selecting the analyze option enables the user to select and automatically start the ProM Framework in case the event logs are in the MXML format. If they are not the ProM Import Framework or XESame tools can be selected and started. Selection of the simulate option gives a user an option to start the ProM framework in order to generate an initial simulation model following the steps provided by Rozinat et al. [22], or to start the CPN tools where simulation experiments are run.

184

M. Amiyo and J. Nabukenya

Risk Assessment Suite: On clicking the Risk Assessment Suite button on the studio interface, the GSS is started. Once in the GSS, the facilitator loads a pre-defined Agenda (created in the AgendaPlanner) based on the Risk Assessment collaboration process into the Chauffeur. He/she then creates a participants roster by inputting their identification and then invites participants to the collaboration session.

Fig. 5. Diagram showing the tools provided in the different suites in the Decision Enhancement Studio Prototype to Improve Business Process Agility. The suites are represented by the dashed rectangles and the tools by the rounded rectangles.

Each participant then connects to the server, and accepts the invitation. The Facilitator then conducts the session following the prescriptions defined in the Agenda. The results of the session are saved in a file that will be an input to the exploration collaboration process suite. This file will be saved in a folder that is accessed by the GSS as an input to the review step of the collaboration process. Business Process Improvement (BPI) Alternative Exploration Suite: On clicking Exploration Suite button on the studio interface, the GSS is launched. The same procedure is conducted as described in preceding suite. Results of the session are saved in a file. Communication Suite: This is made up of a java application. When the Communication Suite button is clicked, the user is presented with an interface, in which a message giving detail of the decision made is written. The title of the message is extracted and sent to the recipient’s phone to inform them about the message that is sent as an email.

A Collaboration Support Environment for Decision Enhancement in BPI

185

Fig. 6. Interface Design for the DES to Improve Business Process Agility

6 Decision Enhancement Studio Testing and Evaluation Testing and evaluation of the BPA Decision Enhancement studio was conducted using two business processes namely, the registration process for students at the Makerere University and the e-Tax registration process at the Uganda Revenue Authority. The studio was evaluated in terms of usability and usefulness of the suites. We define Usefulness and Usability respectively as the ability of the DES to, and the degree to which the studio provides support for the decision process involved in exploring BPI alternatives through the different performed task. 6.1 Studio Testing Case 1: Makerere University (Mak). Initially registration was only done manually however with the increase in the student population, this became a very tedious process characterised by long student queues. Recently, online registration was introduced as a solution to the problem but is not available to first year students in their first semester, and some categories of students of continuing students (these follow the manual process). The online registration process is used only by continuing students on normal progress including first year students in their second semester. Case 2: Uganda Revenue Authority (URA). The organisation has a duty to ensure that all eligible tax payers are registered and pay their taxes. Originally registration and all activities related to the collection of taxes and other government income was carried out manually. This came with a number of challenges such as very long registration periods (2 or more months), difficulty in tracking taxpayers’ returns, generation of more than one Tax Identification Number (TIN) for an individual etc… that necessitated the need for business process re-engineering. The e-Tax project was thus begun with an aim of modeling the organisation’s business process and

186

M. Amiyo and J. Nabukenya

development of a workflow management system to support their business goals. Our focus in this case was the e-Tax registration process. The process consists of three (3) activities, Application, TIN Approval and Account Creation. Process Analysis. Simulations, interviews and group sessions were used to analyze the business processes. At Mak., due to the lack of a supporting workflow management system, process analysis began by conducting interviews with different stakeholders; faculty registrars, registrars at the graduate school, deputy academic registrars and students. The workflow analysis suite was then used to model the student registration process at Makerere University basing on gathered information. Simulations of the registration process were run to generate logs that were used to analyze the process to identify the bottleneck areas in the process. In addition, the risks also viewed as challenges in the process were analyzed by engaging the stakeholders in group sessions and face-to-face interviews. The generated analysis report was then used in the exploration of BPI alternatives. In the case of URA, logs from the eTax registration process, a sub-process within the eTax workflow process, were used. The log data was received as an excel (.xls) file. Using the WFA suite (XESame), the data was converted into a suitable format for process mining. During the data processing stage, the excel file records were broken up into two entries separating the starting and ending of events. The refined excel file was then converted into a Comma Delimited (.csv) which was then converted into MXML format. The generated MXML file was then analyzed to identify the bottleneck areas in the process. Risks assessment was also carried out by engaging the stakeholders in group sessions and face-to-face interviews. BPI Exploration. Using the BPI exploration suite, Information gathered from the analysis phase was presented to the different stakeholders who then took part in a collaboration sessions in which they explored BPI alternatives for selected areas following the collaboration process in Fig. 4. 6.2 Studio Evaluation Feedback from interviews carried out to evaluate the WFA and RA suites emphasized the importance of stakeholder collaboration and rigorous analysis of the business process; to understand its performance and the risks involved, for the success of any business process improvement. These analyses in conjunction with additional relevant information such as feedback from customers, organisational policies, rules, and governing laws, provide information that can be used by stakeholders to identify improvement opportunities. Additionally, stakeholders who took part in the process analysis appreciated the tools provided in the BPI decision enhancement studio as means to support them during business process analysis. However they pointed out that a lot of effort was required to understand and use the provided tools. They suggested the provision of a graphical interface to help in generating and manipulation of the simulation model. Experience with the Collaboration Environment. During the collaboration sessions held to explore BPI alternatives, the participants were able to appreciate the need for various stakeholders when it comes to generating and selecting BPI alternatives. This

A Collaboration Support Environment for Decision Enhancement in BPI

187

was evident at the Mak. case, which lacked a representative from the finance department who would have made more clarification seeing that the chosen BPI alternative regarded updating finance records. Participants also mentioned that during the converging step that called from discussion and clarifications, there is need to guide participants more to ensure that they do not stray from the issues under discussion. Furthermore participants commented that collaboration process helped them to brainstorm on various ideas while eliminating less weighty alternatives. Participants also found the use of a GSS particularly helpful especially when faced with a situation where the BPI alternatives are closely weighed since it provides visualization of the voting results showing the variations in the votes. These could be used for further discussion to build consensus. Usability. Results in tables 1a (average rank of 3.94) and 1b (majority ‘Yes’), indicate that participants generally found the BPI exploration suite easy to use. The participants were able to understand without much effort the collaboration tasks and carried them out with ease. Results in table 1b show that participants from both organisations found the sequence of tasks in the collaboration process enabled them to explore BPI alternatives. A majority of them found the time allocated for each task to be sufficient. Table 1b scores point out that the collaboration process can be carried out repeatedly. However, though participants said the process improved their productivity, the ranking for ‘perceived gain in productivity’ shows that the gain was average indicating that few BPI alternatives were on the final list. Additionally, some difficulty in using the GSS was observed partly attributed to by difficulty in understanding the tool’s interface. Nevertheless, participants were willing to recommend it for business process improvement activities in their organisations. These observations show that the BPI decision enhancement studio provides stakeholders with a collaboration environment to carry out business process analysis and BPI alternative exploration. However, the productivity seen to be average attributed to challenges associated with using the GSS which increase the time and effort required to understand how to use it and thus the ease of carrying out the activities. As a result, more verbal discussions erupted and the ideas generated at this stage were lost leading to low productivity scores. Table 1a. Evaluation of BPI Alternative Exploration Suite’s usability Question Ease of Learning collaboration tool Ease of using the collaboration tool Ease of understanding tool user interface Ease of understanding the tasks in the CP Ease of carrying out the tasks in the CP Perceived gain in productivity

Mak. Mean mode

URA Mean mode

Combined Average

3.8

4

4.143

4

3.97

3.8

4

4

4

3.9

3.8

4

3.857

4

3.83

4.667

5

4

4

4.33

4 3.667

3.5 3 4 Total Average

4

3.75 3.83 3.94

188

M. Amiyo and J. Nabukenya Table 1b. Usability of the BPI Alternative Exploration Suite (Cont'd) Mak. Question Repetitiveness of the CP for BPI exploration

URA

Yes

No

Yes

No

3

0

2

0

Recommendation for use in organisation

3

0

2

0

Time sufficient

5

0

6

1

Sequence of tasks enables BPI generation

5

0

7

0

Improvement of productivity

4

1

7

0

Table 2. Usefulness of BPI Alternative Exploration Suite Mak.

URA

Question usefulness of collaboration process Suitability of the Collaboration Process

Mean

Mode

Mean

Mode

4

5

4.43

5

4

4

4.57

5

Quality of BPI alternatives

4.75

5

4.57

5

Usefulness. This was evaluated by measuring how well participants were able to analyze their business process to identify areas for improvement. Furthermore how well they were able to generate and select a BPI alternative. From the observations made, stakeholders were able to identify areas for improvement (at each case, ten (10) areas were initially identified) and select the most critical to address immediately basing on the process analyses reports. The satisfaction with the generated and selected BPI alternatives was also measured to assess whether the goal was achieved Scores in table 2 show that participants were satisfied with the quality of the BPI alternatives that they generated. From these results we can thus say that participants were able to explore BPI alternatives. Furthermore, the BPI exploration suite provides a suitable environment for continuous exploration of BPI alternatives and supports collaboration.

7 Conclusion and Future Work Research has been done by a number of researchers in the quest to meet the demand for business process agility. In this research these works were reviewed and it was observed that little attention had been given to supporting the collaboration among and involvement of stakeholders taking part in the decision process involved in business process improvement explorations. The research aimed at designing a Business Process Improvement (BPI) decision enhancement studio as an environment to support stakeholder collaboration and involvement during this process. The major requirements derived from an exploratory

A Collaboration Support Environment for Decision Enhancement in BPI

189

study [1] were; enablement of multiple stakeholder participation in exploration of BPI alternatives, risk assessment, and decision making; enablement of in-depth workflow analysis and simulation; support for business process risk assessment; provision of visualization of the analysis reports/results and provision of a information dissemination medium. The BPI decision enhancement studio designed to provide these requirements consists of four suites; Risk Assessment, Workflow Analysis, BPI Exploration and Communication Suites. These were tested and it was found that the WFA suite usable and useful for business process analysis however depending on the format in which process data is stored and whether or not an organisation has a WFMS, the starting point and tools required for workflow analysis differ. In the same breath, the BPI suite was found to be usable and useful for BPI exploration. Notwithstanding, the BPI exploration decision enhancement studio provides a usable and useful environment that support collaboration, stakeholder involvement and interactions during the BPI exploration decision process. Nevertheless, there is a need to make refinements to improve participant productivity in order to improve its usability and the general success of the collaboration process. The next step in this research therefore, is to refine the BPI exploration process so as to improve participant productivity, refine the WFA suite to include an interaction graphical user interface for ease of manipulation of the simulation models. The refined studio will then be subjected to testing using more empirical studies.

References 1. Amiyo, M., Nabukenya, J., Sol, H.G.: Decision Enhancement and Improving Business Process Agility. Paper presented in the 6th Annual International Conference on Computing and ICT Research (ICCIR 2010), pp. 110–128 (2010) 2. BizAgi Limited.: BizAgi Suite (2008), http://www.bizagi.com/eng/products/ (retrieved from May 2, 2009) 3. Bjorn, N., Ralf, P.: Collaborative Business Process Management: Exploring Themes, Achievements and Perspectives. In: 18th European Conference on Information System (2010) 4. Carlsson, A.S.: Towards an Information System Design Research Framework: A Critical Realist Perspective, DESRIST (2006) 5. Chandy, M.K., Shutle, R.: What is Event Driven Architecture (EDA) and Why Does it Matter (2007), http://complexevents.com/?p=212 (retrieved from May 20, 2009) 6. Christine, W.: Oracle: State of the Business Process Management Market (2008), http://www.oracle.com/technologies/bpm/docs/ state-of-bpm-market-whitepaper.pdf (retrieved from May 20, 2009) 7. Corticon Technologies. Business Rules Modeling Studio (2008), http://www.corticon.com/Products/ Business-Rules-Modeling-Studio.php (retrieved from May 2, 2009) 8. Dan, A., Johnson, D.R., Carrato, T.: SOA Service Reuse by Design. In: ACM: International Conference on Software Engineering: Proceedings of the 2nd International Workshop on Systems Development in SOA Environments (2008)

190

M. Amiyo and J. Nabukenya

9. de Vreede, G.-J., Briggs, R.O.: Collaboration engineering: Designing repeatable processes for high-value collaborative tasks. In: Proceedings of the 38th Annual Hawaii International Conference on Systems Science, Los Alamitos (2005) 10. Den Hengst, M., de Vreede, G.-J.: Collaborative Business Engineering: A Decade of Lessons from the Field. Journal of Management Information Systems 20(4), 85–113 (2004) 11. Ghilic-Micu, B., Stoica, M., Mircea, M.: SOA, SoBI & EDA-Paradigms for Integration Capabilities of BI Platform. Revista Informatica 2(46) (2008) 12. Hevner, R.A., March, T.S., Park, J., Ram, S.: Design Science in Information Systems Research. Management Information Systems Quarterly 28(1) (2004) 13. Hevner, R.A.: A Three Cycle View of Design Science Research. Scandinavian Journal of Information Systems 19(2) (2007) 14. Hill, B.J., Sinur, J., Flint, D., Melenovsky, J.M.: Gartner’s Position on Business Process Management. Gartner Research G00136533 (2006) 15. IBM Corporation.: Points of Agility (2008), http://publib.boulder.ibm.com/infocenter/ieduasst/ v1r1m0/index.jsp?topic=/com.ibm.iea.wpi_v6/wbmodeler/ 6.1.2/Modeler-PubServer/WPIv612_PointsOfAgility/player.html (retrieved from May 2, 2009) 16. Kamoun, F.: A Roadmap towards the Convergence of Business Process Management and Service Oriented Architecture. ACM: Ubiquity 8(14) (2007) 17. Keen, P.G.W., Sol, H.G.: Rehearsing the Future: Building Decision Agility through Decision Enhancement Services (2007) 18. Kuhr, M., Drew, H.: Building Executable Service-Oriented Architectures with WSManagement Specification. Springer Simulation MultiConference. In: Proceedings of the 2008 Simulation MultiConference ( Spring 2008) 19. Lundberg, A.: Leverage Complex Event Processing to Improve Operational Performance. Business Intelligence Journal 11(1) (2007) 20. Maruster, L., Beest, N.R.T.P.: Redesigning Business Processes: A methodology based on Simulation and Process Mining Techniques. Knowledge and Information Systems 21(3), 267–297 (2009) 21. Muehlen, M., Ho, D.T.: Risk Management in BPM Life Cycle. In: Process Management Workshops, vol. 3812. LNCS, pp. 454–466 (2006) 22. Rozinat, A., Mans, R.S., Song, M., Aalst, W.M.P.: Discovering Simulation Models. Information Systems 34, 305–327 (2009) 23. Sienou, A., Lamine, E., Pingaud, H.: A Method for Integrated Management of ProcessRisk. In: Proceedings of GRCIS (2008) 24. Singh, C., Thompson, M.: AgilePoint BPM Suite (2008), http://www.ascentnemea.com/News/In_the_News/docs/ Butler_Group_Ascentn.pdf (retrieved from May 2, 2009) 25. Winter, R.: Design Science Research in Europe. European Journal of Information Systems 17 (2008) 26. Grinsven Van, J., Vreede De, G.J.: Addressing Productivity Concerns in Risk Management Through Repeatable Distributed Collaboration Processes. In: Proceedings of the 36th Hawaii International Conference on System Sciences, HICSS 2003 (2002)

A Collaborative Environment for Offshore Engineering Simulations Ismael H.F. dos Santos2, Alberto Raposo1, Paulo G. Rodrigues1, Rogério P. Souza1, and Wagner Gomes do Amaral1 1 Tecgraf/DI/PUC-Rio {abraposo,gallotti,rogerps,wagnerga}@tecgraf.puc-rio.br 2 CENPES/Petrobras [email protected]

Abstract. The main objective of this article is to find effective solutions for collaboration of team workers during the execution of Large Scale Engineering Projects (LSEP). The research is based on actual operational needs of Petrobras, a large Brazilian governmental oil & gas company. For this article we have focused on Offshore Engineering Projects as our case study. We have implemented a Service Oriented Architecture aimed to create a collaborative environment, called CEE (Collaborative Engineering Environment), for visualizing engineering simulations considering important requirements identified for LSEPs, such as collaboration, workflow coordination, and immersive visualization. CEE allows team workers to concentrate in the task of solving a problem using seamlessly the computational resources available, from the execution of engineering simulations on a Grid to the collaborative visualization of results in an immersive or desktop environment. Keywords: Scientific Workflow Management Systems, Collaborative Problem Solving Environments, Virtual Environments, Offshore Engineering.

1 Introduction Contemporary Science and Engineering projects, specially the large scale ones, have common characteristics. They are highly data intensive and computational demanding, highly multidisciplinary and often involve large distributed teams of researchers working together on a single complex problem. Each team of specialists has its own model of the engineering artifacts to be designed, simulated or analyzed, and may use several different models or partial models for different purposes during the project life cycle. Specialists communicate using a shared vocabulary, but not necessarily shared technical knowledge. They also proceed by successive refinement of the models, which are coordinated and updated together, and negotiating design decisions among themselves. Due to their huge complexity, LSEP are commonly divided into smaller interrelated subprojects where each one has a complementary representation of the models. LSEP also involve the interaction of people where information and data are distributed and knowledge is shared at request. Moreover, LSEP demand lengthy and A.S. Vivacqua, C. Gutwin, and M.R.S. Borges (Eds.): CRIWG 2011, LNCS 6969, pp. 191–206, 2011. © Springer-Verlag Berlin Heidelberg 2011

192

I.H.F. dos Santos et al.

complex processes involving multidisciplinary teams, usually geographically distributed with multiple information and storage systems and also using distributed and heterogeneous resources. Therefore, an integrated computer-supported solution to LSEP must include support for human collaboration and distributed resource management. The concept of Problem Solving Environment (PSE) promises to provide LSEP with integrated environments for problem solving specialized in the application domain, increasing team members’ productivity allowing them to focus on the problem at hand rather than on general computational issues. A PSE is a specialized software system that provides all the computational facilities needed to solve a target class of problems [1]. PSEs allow users to define and modify problems, choose solution strategies, interact with and manage appropriate hardware and software resources, visualize and analyze results, record and coordinate extended problem solving tasks. Collaborative Problem Solving Environments (CPSE) focus on the development of a PSE coupled with collaborative environments to support the modeling and simulation of complex scientific and engineering problems. For LSEP, a CPSE should focus on the development and integration of scientific tools and technologies, coupled with visualization capabilities and collaborative environments to support the modeling and simulation of complex scientific and engineering problems in a collaborative way. Such capabilities enable engineers to easily setup computations in an integrated environment that supports the storage, retrieval, and analysis of the rapidly growing volumes of data produced by computational studies. Experience in dealing with LSEP design and analysis problems has indicated the critical needs for a CPSE with six distinguishing characteristics: interoperability facilities to integrate different applications; support for human collaboration; computing power for numerical simulations; visualization capabilities for 3D realtime rendering of massive models; transparency for the use of distributed resources; and advisory support to the user. CEE (Collaborative Engineering Environment), our proposed solution, was conceived as a CPSE especially tailored for assisting the control and execution of shared engineering projects involving geographically distributed teams. It also allows an easy integration of different engineering applications providing team workers with means of information exchange, aiming to reduce the barriers imposed by applications with limited or no collaboration support. In order to achieve its goals the CEE architecture is a composition of different CSCW technologies to create a useful collaborative engineering environment. CEE is composed of a Collaborative Visualization Environment based on a Virtual Reality Visualization tool [2] and a Videoconference System [3]; a Scientific Workflow Environment with a Grid Computing infrastructure support for executing large engineering simulations; and a Project Management Environment responsible for controlling the overall execution of the project and keeping track of all the information and different artifacts generated during the project entire life cycle. The structure of the paper is a follows. Section 2 presents the related works that inspired the development of the CEE. The conceptual model of the CEE is presented in section 3 and the SOA Architecture in section 4. The application scenario of Offshore Engineering is presented in section 5 and conclusions follows in section 6.

A Collaborative Environment for Offshore Engineering Simulations

193

2 Related Work Dynamic data-driven approaches, such as the Data Driven Multiphysics Simulation Framework (DDMSF), are increasingly becoming more feasible because of the confluence of several technologies. First, advanced sensor technologies have improved the ability to capture data faster and at higher resolution. Second, Grid Computing infrastructure aims to dynamically and seamlessly link powerful and remote resources to support the execution of large scale and disparate processes characterizing a particular problem. Among all DDMSF components, the Discover Computational Collaboratory [4] strongly inspired our proposed solution. Its overall objective is to create a CPSE that enables geographically distributed scientists and engineers to collaboratively monitor, interact with, and control high performance applications in a truly pervasive manner, transforming high-performance simulations into modalities for research and instruction. Paventhan et al. [5] proposed the creation of a Scientific Workflow for wind tunnel applications. They observed that scientific and engineering experiments often produce large volumes of data that should ideally be processed and visualized in near realtime. The difficulty to achieve this goal is that the overall turnaround time from data acquisition, data processing and visualization of results is frequently inhibited by factors such as manual data movement, system interoperability issues, manual resource discovery for job scheduling and disparate physical locality between the experiment and the scientist or engineer workstation. They argued that customized application specific workflows could reduce the time taken to accomplish a job by automating data flow driven activities, supplementing or replacing manual user-driven tasks. Vistrails [6] is a visualization management system that provides a Scientific Workflow infrastructure, which can be combined with existing visualization systems and libraries. A key feature that sets Vistrails apart from other Visualization Systems as well as Scientific Workflow Systems is the support for data exploration. It separates the notion of dataflow specification from its instances. A dataflow instance consists of a sequence of operations used to generate a specific visualization. The Vistrails approach inspired our CEE strategy, but some of the differences of the CEE are the use of a BPEL (Business Process Execution Language) engine as our ScWfMS and the focus on immersive and realistic visualization. Parker et al. [7] describe SCIRun, a PSE that allows users to interactively compose, execute, and control a large-scale computer simulation by visually "steering" a dataflow network model. Paraview [8] is a kind of PSE for visualization that allows the interactive creation and manipulation of complex visualizations. The success of SCIRun and Paraview demonstrates the importance of adding visualization to a PSE. In the Geology field, Kreylos et al [9] presented an approach for turning immersive visualization software into scientific tool. They created immersive visualization measurement and analysis tools that allow scientists to use real word skills and methods inside Virtual Environments. They have also conducted some informal studies to determine the impact of using VR methods on some geosciences tasks such as Geological-Mapping and Displacement Analysis (GMDA). As shown by GMDA, the usage of a VR Visualization system to debug engineering simulations is a very powerful tool for LSEP. Although not being a quantitative study, due to the small numbers of participants, they observed that VR visualization enabled scientists to make more

194

I.H.F. dos Santos et al.

accurate observations in less time and with more confidence. This observation motivated us to include a VR Visualization system as an important component of the CEE architecture. Service Oriented Architecture (SOA) [10] provides a platform for building application services with interesting characteristics such as: loose coupling, location transparency and protocol independence. An SOA application that influenced our research is the Integrated Asset Management framework (IAM). IAM provides to its users a front-end modeling environment for specifying and executing a variety of workflows from reservoir simulations to economic evaluation [11]. The IAM framework is intended to facilitate seamless interaction of diverse and independently developed applications that accomplish various sub-tasks in the overall workflow. In Fig. 1 we present a comparison of the features provided by CEE and the features presented by the related solutions. It can be seen that CEE has a wider spectra addressing the most important requirements of LSEPs.

Fig. 1. Feature comparisons between CEE and related solutions

3 CEE Conceptual Model CEE allows users to collaboratively solve their problems through the use of predefined scientific workflows or assembling new ones. Each workflow comprises a sequence of simulations, in the form of workflow tasks, usually finishing with a collaborative visualization task. This task is responsible to create a collaborative session supported by CEE. To achieve its goals CEE needs to be extensible, flexible and platform-independent, allowing a transparent flow of information among different teams, systems and their models. The challenges in building an effective CEE could be scrutinized in three domains. Collaborative Visualization Environment – this domain encompasses different challenges from the areas of CSCW and VR. Regarding collaborative work, in this domain there is the necessity of providing effective human-to-human interaction and communication for solving conflicts and enhancing group productivity. Also there is

A Collaborative Environment for Offshore Engineering Simulations

195

the need of some support for coordinating the execution of tasks. Regarding virtual reality visualization, high performance and scalability are important aspects of virtual environment architectures intended to support execution of large shared virtual worlds over long periods of time. For this domain, we created the Collaboration Manager Service (Fig. 2), which is responsible for managing the user interaction with the CEE. The Videoconference Service and the VR Visualization Service work closely coupled with the Collaboration Manager Service to enable the creation of collaborative visualization sessions driven inside the CEE.

Fig. 2. CEE Conceptual Model

Scientific Workflow Environment – this domain includes challenges related to the control of the execution of engineering simulations. Regarding interoperability and distributed execution, there is a myriad of software that specialists, potentially geographically distributed and using distributed resources, are forced to use in order to accomplish their tasks in a reasonable time. For this domain, we created the Scientific Workflow Service to help the users build engineering workflows and seamlessly execute them in a Grid Computing Infrastructure (GCI). More generally for Distributed Execution, we use the interoperability characteristics of the ScWfMS and the distributed execution support provided both by the GCI of the CEE and by the SOA backbone infrastructure. The Engineering Simulations Service provides a Webservices interface for remotely execute an engineering simulation program. In the Offshore Engineering, some of those simulators are, among others, Anflex [12] a Finite Element riser analysis software, and Prosim [13] a coupled analysis software for the design of floating production systems. Project Management Environment - this domain points to the necessity of keeping track of all the documents and artifacts generated during project's life cycle. Multiple and different visions of the on-going project must be provided while users have

196

I.H.F. dos Santos et al.

different background and need different types of information to accomplish their duties. For this domain, the introduction of a Project Management System is a valuable resource, but is out of the scope of this article. In the following sections we present the major CEE functionalities regarding visualization and collaboration. 3.1 Collaborative Visualization Environment Collaborative systems should not only allow multiple users to interact with shared objects but also to communicate and to coordinate their actions. Collaboration may be seen as the combination of communication, coordination and cooperation [14]. Communication is related to the exchange of messages and information among people. Coordination is related to the management of people, their activities interdependencies and the used resources. Cooperation is the production of common artifacts taking place on a shared space through the operations available to the group. The communication support is provided by a Video Conferencing System seamlessly integrated into CEE so that users can start a videoconference communication at anytime, while modeling their workflows or during visualization of results. There are different types of coordination and awareness support provided in CEE [15]. Workspace awareness in the virtual environment provides control of collaborative interaction and changing of the user location. Mutual awareness allows users see each other’s identity and observe each other’s actions. Group awareness facilitates the perception of groups of interest connecting people who need to collaborate more intensely. Informal communication enhances team awareness, even with no support to cooperation and with restricted coordination functionalities for controlling the simultaneous use of communication channels [16]. The cooperation occurs by the different types of model visualization available at the CEE, as well as data management infrastructure related to these models, real-time simulation and visualization of 3D models, possibilities of walkthroughs in the models, object interaction and manipulation, edition and planning and also access to organizational work history. Cooperation also occurs during the assembling of useful engineering workflows that will be used to orchestrate the execution of engineering applications. The three services provided by Collaborative Visualization Environment (Fig. 2) are described below. Video Conferencing System (VCS). The development of a custom videoconferencing system, CSVTool [3], allowed us to automatically establish videoconferencing channels among the participants of a conference, which greatly simplify and improve the communication. We can also tightly control the multiple audio and video streams among participants implementing different scenarios of usage. Besides the transmission of audio and video to multi-participants, with different operating systems platform, CSVTool provides extra interesting features for CEE: video stream from the image captured by the camera or the user screen, a textual chat tool and screen snapshots. VR Visualization (VRV). Environ [2] is a tool designed to allow visualization of massive CAD models and engineering simulations in immersive environments (VR and Desktop). It is a system composed of a 3D environment for real-time visualization and

A Collaborative Environment for Offshore Engineering Simulations

197

plug-ins to import models from other applications, allowing users to view and interact with different types of 3D data, such as refineries, oil platforms, risers, pipelines and terrain data. In order to serve as the CEE’s VRV, Environ was adapted to be transformed into a collaborative application with the support provided by the CEE collaborative infrastructure. Collaboration Manager. The Collaboration Manager is responsible for managing the users’ participation in a collaborative session and also integrates the resources of VRV and VCS. There are three kinds of sessions available. In an Informal session each participant uses its individual telepointers all the time. There is no mediation of camera movements and the users are free to move around the scene propagating the camera movements to others. In this model, once a collaborative session is created, all users can use audio and video at any time. The only mediation mechanism supported is furnished by the social protocol available whenever a videoconference is started. In a Classroom session one specific participant, the instructor, acts as a coordinator of the session which means that all camera movements he performs are followed by other users, while the other participants have their telepointers disabled. The instructor also controls the audio and video channels of the participants, and he is also allowed to pass control of collaboration resources (telepointers, camera control, etc.) among participants. Users can also request the coordination role to the current coordinator who can accept or reject the request. The Lecture session has a speaker that acts as the coordinator of the session, with the same characteristics of a Classroom session. However, in this type of session there is no exchange control between the coordinator and participants and the participants can only receive audio and video stream from the coordinator. At any time a user can disconnect from the session, for doing some private work, and reconnect to session in later time, when its state is synchronized with the sate of the session, that is controlled by the Collaboration Manager Service. Collaboration Bus (CBus). The CBus is a key component of the overall architecture and provides synchronous and asynchronous communication for the CEE components. The CBus is an infrastructure for communication based on the JMS Service Provider, the Message Oriented Middleware (MOM) used for giving the public/subscribe and point-to-point paradigms, and the Enterprise Service Bus (ESB). The integration of the VRV and the VCS with the other components is done in a seamless way through the Collaboration Bus, in a way that the user always interacts with the same interface independent of the application he/she is currently using. This is a very important aspect of the solution to keep the user conscious of what he/she is doing and what should be the next steps of the current task being executed. 3.2 Scientific Workflow Environment In recent years, several industries have improved their operations through WfMS, improving data management and having a better coordination of activities through specific Business and Scientific Process. However, there are remarkable differences between Business (BWfs) and Scientific Workflows (ScWfs). In WASA project [17] the authors identified that in a scientific environment scientists will typically specify

198

I.H.F. dos Santos et al.

their workflows themselves, while in a business environment, a system administrator is commonly responsible for this task. Another characteristic of ScWfs mentioned in their work is the need to trace workflow executions. An engineer may need to reuse a workflow in order to reproduce results. The operations a user performs on a given data must be recorded in order to provide engineers with the benefits of successful and unsuccessful workflows. Scientific Workflows describe series of structured activities and computations that arise in scientific problem-solving. In many science and engineering areas, the use of computation is not only heavily demanding, but also complex and structured with intricate dependencies. A Scientific Workflow is composed by coupling service interfaces in the desired order, created through a graphical or textual front end and the actual service calls are generated automatically and have their execution controlled by the workflow engine. All the consistency, adequacy and compatibility of the shared data among its users should be done by the kernel of the CEE, in order to reduce non useful iterations during the project’s life cycle. The ability of reusing partial workflows, which were previously stored in the system with some guidelines, provides an optimized usage of the available computational resources and also a better control of the costs and time scheduling. Scientific workflows often begin as research workflows and end up as production workflows. Early in the lifecycle, they require considerable human intervention and collaboration; later they begin to be executed increasingly automatically. Thus in the production mode, there is typically less room for collaboration at the scientific level and the computations are more long-lived. During the research phase, Scientific Workflows need to be enacted and animated (fake enactment) far more intensively than Business Workflows. In this phase, which is more extensive than the corresponding phase for business workflows, the emphasis is on execution with a view to design, and thus naturally includes iterative execution. The corresponding activity can be viewed as “Business Process Engineering” (BPE). For this reason, the approaches for constructing, managing, and coordinating process models are useful also in scientific settings. In this way, Scientific Workflows are to Problem Solving Environments what Business Workflows are to Enterprise Integration [18]. Scientific Workflow Management Systems (ScWfMS) are more data-flow oriented while Business Workflow Management Systems (BWfMS) are more control-flow oriented. BWfMS require the coordination of a number of small messages and document exchanges. In ScWfMS usually no documents undergo modifications. Instead, often a dataset is obtained via analysis and transformation of another dataset. BWfMS need complex control flow, but they are not data-intensive pipelines. On the other hand, ScWfMS must deal with the heterogeneity, complexity, volume, and physical distribution of scientific data. In addition to these data problems, ScWfMS often deal with legacy or third-party programs, which can also be heterogeneous, and possibly with no source code available. In a typical scenario, data is usually passed from one program to another in order to complete several steps of the simulation. Once in the CEE, the sequence of operations to perform an engineering simulation are modeled as scientific workflows, there is an interoperability problem, since in most of the cases, data conversion steps are needed every time a different program needs to be run over the data. To solve the data

A Collaborative Environment for Offshore Engineering Simulations

199

interoperability problem, allowing applications to share engineering data in the context of such scientific workflows, a unified data format called GXML have been defined and developed [19].

4 CEE SOA Architecture Service Oriented Architecture (SOA) is an architecture that allows independence between service providers and consumers. Enterprise Service Bus (ESB) represents the next generation of integration middleware, which establishes an enterprise-class messaging bus that combines a messaging infrastructure with message transformation and content-based routing in a layer of integration between service consumers and providers. The use of an ESB in the CEE architecture allows a seamlessly integration of distributed applications modeled as SOA services. For each external engineering application that will be invoked by the Scientific Workflow during the execution of a user job, we built a service interface (Engineering Simulation Service) that allows the application to be called from inside the workflow or any other application connected to the ESB. We distinguish three main layers in the overall architecture (Fig. 3).

Fig. 3. CEE Architecture Layers.

Technology Layer. CEE requires a solid infrastructure to provide security, persistence, transactions support, scalability and performance. We have chosen the JEE (Java Enterprise Edition) standard as the technology infrastructure. The JEE middleware is responsible for the basic infrastructure such as security, performance, server federation, database persistence among others. As a Message Oriented Middleware, we have used ActiveMQ, an open source Java Messaging Service Provider. The overall architecture uses pervasively XML for data interchange among the Engineering Simulations, Pre and Post Processors and the VR Visualization Tool (Environ).

200

I.H.F. dos Santos et al.

The Business Process Execution Language (BPEL) provides a standard-based way of orchestrating a business process composed of services [20]. As an execution language, BPEL defines how to represent the activities in a business process, along with flow control logic, data, message correlation, exception handling, and more. This capability is important for having a flexible environment for the execution of Scientific Workflows; therefore we chose the BPEL Engine as our Scientific Workflow. For the Grid subsystem we have chosen Condor [21] and GridSAM [22]. GridSAM is a Grid Job Submission and Monitoring WebService for submitting and monitoring jobs managed by a variety of Distributed Resource Managers. GridSAM implements the Job Submission Description Language (JSDL) defined by the Global Grid Forum (GGF) [23]. Using GridSAM to execute jobs on a Grid (in our case, Condor) gives us transparency of the underlying Grid scheduler. Scientists only need to define the JSDL for their jobs once and not worry about which scheduler is used now or at any point in the future. Collaborative Engineering Layer. This layer is the most important part of the overall system, and has been designed taking into account the CEE main components. The system is divided into several modules. CEE Core is composed by a collection of collaboration tools, providing services like shared spaces, access control, floor management, and integration for both synchronous and asynchronous communication through the use of a Collaboration Bus (CBUS). CBUS is an infrastructure for communication based on the Java Message Service (JMS) Provider and the Enterprise Service Bus (ESB) available on the technology layer. The CEE Awareness Service (AWS) provides appropriate actuators for events received from the CBUS. It is responsible for signaling distributed events to the users participating in a collaborative session. In one side all components trigger events to this distributed bus, and in the other side awareness components listen to the bus for information about what is happening in the system. For example, when users leave a collaborative session or when there is a change in its state from offline to online and vice-versa, “update user” events are triggered to the CBUS and the CEE Awareness mechanism send messages to VRV Service and VC Service notifying the event. By their turn, those services signal those events in their user interfaces making the user conscious of what have happened. There are a lot of services in this layer providing collaboration support to CEE applications. The VR Visualization Service and the Collaboration Manager Service are the most important components. They use the CEE Core, CEE AWS and CEE CBUS components to create a collaborative visualization tool to allow the users to visualize the results of an engineering simulation in an immersive or desktop environment. Application Layer. The engineering applications supported by the CEE are in the Application Layer. It can be generically divided in four different components: Pre and Post Processors, Engineering Simulators (Anflex [12], Prosim [13]), Data Access Services and VR Visualization Tools.

A Collaborative Environment for Offshore Engineering Simulations

201

5 CEE Application Scenario: Offshore Engineering This section describes the Collaborative Riser Analysis Workflow project, an Offshore Engineering scenario where we applied the CEE. Offshore Engineering projects share all the typical characteristics of LSEP already mentioned. Due to their huge complexity, these projects are divided into smaller interrelated subprojects where each one deals with an abstract representation of the others. Because decisions are interdependent, collaboration is a key point in this area. Each team activity or new decision can affect other activities. For example, during the design of a floating production and storage offloading, changing structural characteristics of the unit influences the mooring system, risers and can compromise the stability of the production unit. As a consequence, an inadequate mooring system design can possibly lead to an increase in the geologic and geotechnical risks. Moreover, changes in environmental conditions, as the direction of wind and currents, as well as changes in the height and frequency of waves, induce movements in the mooring system, in the production risers and also in the ship, which generates second order movements that propagates to the whole system backwards. All those movements should be carefully analyzed to guarantee compatibility with the structural equilibrium of the production unit and the recommended operational conditions of the production risers. To certificate the operation of the risers for their entire life cycle (30 years or so), simulations of the stress applied to the riser system are conducted based on meteooceanographic data about wind, tide and water currents. In order to avoid operational problems, simulations are made under extreme environment conditions to test against stress resistance. In our case we have used a riser analysis software called Anflex [12], an internally developed Finite-Element-based structural analysis package. Fig. 4 shows the main components of the CEE interaction. Initially after the user is logged in the system, the CEE User Service on the client machine registers the user in the Collaboration Manager Service on the CEE server, all services that the user’s machine is able to support (Environ Service, CSVTool Service, etc) is also registered on the CEE server Service Registry. After registration of its services on the server, User A accesses the CEE Portal (1) through a web browser to request the execution services on the CEE server on his behalf (2). As an example, User A can model collaboratively with User B a Concrete Scientific Workflow (3). When the model is assembled and all input parameters of the concrete workflow are informed, User A can submit the workflow as a simulation on a Grid integrated into the CEE infrastructure (4). Examples of such simulations, in the context of Offshore Engineering, can be: design of a mooring system for a production unit or a fatigue analysis of a set of risers that bring the oil to an offshore production unit. Upon finishing its execution, the results of the concrete workflow may be visualized in a Collaborative Visualization Session with User B (5). During the collaborative visualization session, the users can require the execution of alternative simulations and have its results exhibited automatically (6 and 7).

202

I.H.F. dos Santos et al.

Fig. 4. Overview of the user interaction with CEE

BPEL Scientific Workflow - we have defined an Anflex-based riser analysis workflow controlled by the BPEL engine for automating the validation process and certification of riser analysis. The workflow integrates the execution of the following services: Ocean Service, Anflex Service e Grid Job Service. In Fig. 5 we show the final version of the Riser analysis workflow in a BPEL designer. The workflow starts with an Anflex base-case, where the basic configuration of the experiment is defined such as a production unit, riser’s geometry, soil bathymetry, etc. Anflex Service receives user input parameters from BPEL designer and is responsible for creating different loading cases according to the different meteooceanographic conditions provided by the OceanService. After that, BPEL instructs CEE GridJob Service to communicate with Condor to submit jobs for executing the Anflex simulation program on the available nodes of the Numerical Grid.

A Collaborative Environment for Offshore Engineering Simulations

203

Fig. 5. Constructing the Riser Analysis workflow on BPEL Designer

Video Conferencing – Fig. 6 shows a collaborative visualization session with the presence of two users, represented by two distinct 3D-cursors, visualizing the simulation results in their desktop with the support of a Videoconference. The blue arrow represents the water currents that actuate over the riser, while the red arrow represents the direction of the movement of the riser.

Fig. 6. Riser Analysis in CEE

In the first screen the coordinator desktop is presented, while the second screen shows the participant. Both users receive a video stream from the other user, improving the efficiency of the collaboration due to the user awareness obtained by the use of the videoconferencing tool. 3D Annotations and Measurements - Environ has special capabilities to show the extreme values and where are they located in the model, also allowing users to create 3D Annotations at any time. In Fig. 7 two annotations were created automatically by the Environ, showing the extreme points (maximum and minimum values) of a selected force or strength in the riser. The third 3D annotation was created by one of the users to register some important observation made in this collaborative session.

204

I.H.F. dos Santos et al.

Fig. 7. Two users in a CEE collaborative visualization session

Among other resources, it is possible to playback the simulation, examine pipes, sea waves and ship movements, and track elements in the risers that are subjected to extreme conditions (e.g., high stress values). It is also possible to select any element in a riser and examine it carefully; especially those elements in places subjected to great stress, such as the joints connection and the Touch Down Point.

6 Conclusions This article presented the conceptualization and implementation of a CPSE we devised for Offshore Engineering projects. As a proof of concept we have developed CEE, a collaborative environment to optimize the execution of Large Engineering Projects developed at Petrobras. Through the use of the CEE we have build an effective collaborative environment that allow users to mitigate problems that usually happen during the execution of large and complex engineering projects. Upon the integration of VR technologies into the workflow of the team workers we expect to improve the use of VR in Offshore Engineering projects. It is clear that visualization resources improve the quality of engineering projects, but users do not want to spend their time preparing the content to be visualized in other system, like an immersive multi-projection environment. In this concern CEE is already showing its value, upon simplifying the daily job of the engineers, from running simulations on a Grid through visualizing its results on an immersive environment or on a desktop. We believe that the main contribution of this research is the junction of approaches and technologies from different areas composing a CPSE suitable for LSEP (more specifically, Offshore Engineering projects), with distinguishable characteristics, when compared to similar systems. From Offshore Engineering point of view, the introduction of a Scientific Workflow in the project life cycle and the use of a CPSE are important contributions in the sense of providing a more structured way to solve the problems and the creation of tools more widely used.

A Collaborative Environment for Offshore Engineering Simulations

205

From the VR and Visualization point of view, CEE approach treats them as first class tools, exploring their potential for facilitating information exchange and common understanding of complex problems. It was not possible to find any other approach complete as presented here in the academic literature or in any oil & gas company in the world. The perspectives for the future is that many other organizations are going to start to use Scientific Workflows and this will become a common solution in high complex enterprises that have several areas that must be integrated and synchronized. Although this work is focused on a solution for Offshore Engineering projects, we believe that the proposed CEE could also be used in other areas. We believe that CEE is a step towards a new frontier in CPSE, which is the use of a computation steering approach in tele-immersive CPSE. Computational steering is the practice of manually intervening with an otherwise autonomous computational process, to change its outcome. Abstractly, we can think of it as an API for interactive application control, furnishing interesting tools for data exploration visualization such as modify parameters while (long) running and “what if” explorations. The steering approach is a very valuable feature for any CPSE for science and engineering. Acknowledgments. Tecgraf is a laboratory mainly supported by Petrobras. Alberto Raposo receives a grant from FAPERJ E-26/102273/2009.

References 1. Houstis, E.N., Gallopoulos, E., Bramley, R., Rice, J.R.: Problem-Solving Environments for Computational Science. IEEE Comp. Sc. Eng. 4(3), 18–21 (1997) 2. Raposo, A.B., Santos, I.H.F., Soares, L.P., Wagner, G., Corseuil, E., Gattass, M.: ENVIRON: Integrating VR and CAD in Engineering Projects. IEEE Computer Graphics & Applications 29(6), 91–95 (2009); ISSN 0272-1716, doi: 10.1109/ MCG.2009.118 3. Lima, L.S., Karlsson, B., Raposo, A.B., Santos, I.H.F.: Uma Ferramenta de Videoconferência para apoiar Múltiplas Sessões de Trabalho Colaborativo. In: XIII Brazilian Symposium on Multimedia and Web, WebMidia 2007, Gramado, RS, Brazil (October 2007) 4. Mann, V., Parashar, M.: DISCOVER: a computational collaboratory for interactive grid applications. In: Fox, F.B.G., Hey, T. (eds.) Grid Computing: Making the Global Infrastructure a Reality, pp. 727–744. Wiley, Chichester (2003) 5. Paventhan, K., Takeda, S.J., Cox, D., Nicole, A.: Leveraging Windows Workflow Foundation for Scientific Workflows in Wind Tunnel Applications. In: Proceedings of the 22nd International Conference on Data Engineering Workshops, ICDEW 2006, Atlanta, Georgia (April 2006) 6. Callaban, S.P., Freire, J., Santos, E., Scheidegger, C.E., Silva, C.T., Vo, H.T.: VisTrails: Visualization meets Data Management. In: The Proceedings of the 2006 ACM SIGMOD Inter. Conf. Management of Data, Chicago, IL, USA (2006) 7. Parker, S.G., Miller, M., Hansen, C.D., Johnson, C.R.: An integrated problem solving environment: The SCIRun computational steering system. In: 31st Hawaii International Conference on System Sciences (HICSS-31) , pp. 147–156 (1998) 8. Paraview website, http://www.paraview.org

206

I.H.F. dos Santos et al.

9. Kreylos, O., Bernardin, T., Billen, M.I., et al.: Enabling Scientific Workflows in Virtual Reality. In: ACM SIGGRAPH International Conference on Virtual-Reality Continuum and its Applications in Industry, VRCIA 2006, Hong Kong (June 2006) 10. High, R., Kindler, S., Graham, S.: IBM SOA Foundation: An architectural introduction and overview. IBM developer Works (November 2005), http://www-128.ibm.com/developerworks/webservices/ library/ws-soa-whitepaper/ 11. Soma, R., Bakshi, A., Orangi, A., Prasanna, V.K., Sie, W.D.: Service-Oriented Data Composition Architecture for Integrated Asset Management. In: SPE Intelligent Energy Conference and Exhibition, IECE (April 2006) 12. Mourelle, M.M., Gonzalez, E.C., Jacob, B.P.: ANFLEX - Computational System for Flexible and Rigid Riser Analysis. In: Proceedings of the 9th International Symposium on Offshore Engineering, Brazil (1995) 13. Jacob, B.P., Ebecken, N.F.F.: An Optimized Implementation of the Newmark/NewtonRaphson Algorithm for the Time Integration of Nonlinear Problems. Communications in Numerical Methods in Engineering 10, 983–992 (1994) 14. Fuks, H., Raposo, A.B., Gerosa, M.A., Lucena, C.J.P.: Applying the 3C Model to Groupware Development. Intern. Journal of Coop Information Systems (IJCIS) 14(2-13), 299–328 (2005) ;ISSN 0218-8430 15. Schummer, T., Lukosch, S.: Patterns for Computer-Mediated Interaction. Wiley Series in Software Design Patterns. Wiley & Sons, England (2007) 16. Mackay, W.E.: Media Spaces: environments for informal multimedia interaction. In: Beaudouin-Lafon, M. (ed.) Computer Supported Cooperative Work, Trends in Software, vol. 7, pp. 55–82. John Wiley & Sons, Chichester (1999) 17. Medeiros, C.B., Vossen, G., Weske, M.: WASA: A Workflow-Based Architecture to Support Scientific Database Applications. In: DEXA, pp. 574–583 (1995) 18. Singh, M.P., Vouk, M.A.: Scientific Workflows: Scientific Computing Meets Transactional Workflows (2007), http://www.csc.ncsu.edu/faculty/mpsingh/papers/databases/ workflows/sciworkflows.html 19. Santos, I.H.F., Braganholo, V., Mattoso, M., Jacob, B.P., Albrecht, C.: Integrating The Galileo Applications For Simulation of Offshore Systems Via The GXML Unified Format. In: XXX CILAMCE - Iberian Latin American Congress on Computational Methods in Engineering 2009, Buzios, RJ, Brasil, pp. 1–15 (2009) 20. OASIS Web Services Business Process Execution Language (WSBPEL), http://www. oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel 21. Condor web site – High Throughput Computing, http://www.cs.wisc.edu/condor/ 22. GridSAM - Grid Job Submission and Monitoring WebService, http://www.omii.ac.uk/wiki/GridSAM 23. Lee, W., McGough, S., Newhouse, S., Darlington, J.: A standard based approach to job submission through web services. In: Proc. of the UK e-Science All Hands Meeting, UK EPSRC, pp. 901–905 (2004)

Design and Implementation of a 3D Collaborative Telerobotic Simulator Claudinei Dias, Marcelo da Silva Hounsell, Maurício Aronne Pillon, and Carla Diacui Medeiros Berkenbrock Computer Science Department - DCC Santa Catarina State University - UDESC Campus Universitário Prof. Avelino Marcante s/n - Bairro Bom Retiro - Joinville, Brazil [email protected], {marcelo,mpillon,diacui}@joinville.udesc.br

Abstract. Three-dimensional robotic simulations represent a way to protect the physical integrity of both the robot and its operator. Among their applications, teleoperation enable to command robot manipulations of hazardous 3D objects (such as radioactive or explosive ones) on a remote site. To some telerobotic applications there is the need for two or more operators due to task complexity or due to the object being handled. A collaborative robotic simulator would provide a multi-user environment to perform tasks that are split to generate interdependence between operators. This paper presents a simulated 3D telerobotic system where two 5 degrees-of-freedom robots perform collaborative tasks. The system, called CollBot4us (Collaborative roBot for Us), proposes a task and continuously evaluate the scenario to determine when operators have reached a specified goal and, at the same time, it captures metrics that can be used to assess the collaboration process. While using CollBot4us operators see a single scene from their own perspective but the operations they command come from geographically distinct locations. CollBot4us can be used for teaching robotics through collaboration or teaching collaboration strategies through robotics. Keywords: Collaboration, Telerobotics, 3D Simulator.

1 Introduction Robots are the highlight of many processes automation thanks to their high degree of accuracy and capability to perform tasks that are repetitive and harmful to humans. Remote robots provide a work environment in which the controller is geographically distant from the task. These tasks could be operations on a radioactive power plant leak, manipulation of a potentially explosive content under suspicion of terrorism or any other scenario that requires intervention but is hazardous to humans. Telerobotic experiments can be performed in two ways: applying commands directly on a real robot, or; applying commands to a simulated robot. The use of simulators reduces risks of damaging the robot or injuring personnel at the same time that it reduces costs such as robot maintenance, material and energy. A.S. Vivacqua, C. Gutwin, and M.R.S. Borges (Eds.): CRIWG 2011, LNCS 6969, pp. 207–214, 2011. © Springer-Verlag Berlin Heidelberg 2011

208

C. Dias et al.

This paper presents a 3D Collaborative Virtual Environment (CVE)[2] for telerobotic simulation, called “Collaborative roBot for us” (CollBot4us), for “multiple-operator multiple-robots” approach containing two Scorbot ER 4PC virtual robots with five degrees of freedom (DoF) each. CollBot4us provides a controlled 3D virtual environment where telerobotic collaboration can be studied and measured. CollBot4us proposes tasks which can only be solved by simulated telerobotic manipulations. These tasks however were carefully designed to require a collaborative intervention on a game look and feel 3D environment. CollBot4us, on his end, provides special features to support collaborative robotic manipulations and assessment. The remainder of this paper is organized as follows: Section 2 discusses some of the characteristics of collaborative robotics and presents related work; Section 3 describes the proposed system where its interface, collaborative task design and metrics are described; Section 4 discusses the implementation issues with emphasis on communication approach, and; Section 5 presents conclusions and future work.

2 Collaborative Robotics and Related Work It was observed [3] that users with little experience on collaborative works tend not to use collaboration strategies. In this case, there is a need to identify the weaknesses of the process (software and task) and improve them. To achieve collaboration both at system level as well as task level, Collaborative Requirements (CR) proposed by Collazos et al [3] and Marek et al [4] were taken into account when developing CollBot4us. Collaborative robots are used for tasks that cannot be performed by a single robot in a satisfactory manner. Collaboration requires planning, coordination, interdependence, control and decision making in order to keep both robots in a synchronized and informed situation. A collaborative robotic task is comprised of sub-tasks that depend on actions and configurations (positioning and orientation) of both (if there are two of them) robots but it also comprises sub-tasks that each robot must perform on its own. Therefore, there are moments where all robots interact with each other and moments to work alone but all the time the goal is a common one. For the sake of simplicity, hereafter only two robots and their operators, called the “pair”, will be referred to. Thus, the pair should develop strategies for the realization of collaborative tasks that occur in a shared space for manipulation of objects. The predictive graphic simulator for the PA-10 robot with 7 DoF [1] is a CVE for telecontrol. Prediction means that a simulation of the robot movements and collisions are performed in the graphics software and, in case it is approved, it is sent to the actual robot. Robots are placed opposite to each other to rearrange objects of different shapes and colors that are distributed on a table in a strategic way. Only one collaborative task was developed, the architecture is based only on local network and, there is no resource for assessing collaboration or task efficiency. Quintena is a CVE that simulates a real work cell containing five CRS F3 robot arms of 6 DoF [5]. The system simulates the control panel and 3D virtual environment

Design and Implementation of a 3D Collaborative Telerobotic Simulator

209

to train users before they teleoperate the real robotic system. Two tasks are presented: one in which a pair interact to solve the 2x2 Rubik’s Cube game, and; the other is performed involving all five robots that are required to pass on a ring delivered from one robot to its neighbor until the ring reaches the robot that lies at the other end of the work cell. The actual system (with real robots) is not always available and there are no collaboration assessment capabilities and the shared work space is kept to a minimum in order to avoid collisions. None of above mentioned work applied loggings or metrics to assess the degree of collaboration albeit CollBot4us, was developed in such a way as to capture metrics related both to the collaboration process as well as to task performance. It also features a chat to foster negotiation and communication between (distant) operators. None of the above provides a chat on their CVE.

3 CollBot4us To perform the tasks imposed by the 3D simulator, CollBot4us offers two Scorbot ER4-PC virtual robots placed opposite to each other on a desk. The two robots are operated by a pair of operator where each operator controls a robotic arm identified by different colors but they can see the whole scene with the two robots altogether. The environment is symmetrical which allows each operator to infer the collaborator´s solution strategy by just comparing his surrounding spheres to his collaborator´s. Operators have Xj3D [10] native commands available for free 3D navigation and visualization control available on the bottom of their screen. CollBot4us provides two types of viewpoints: orthogonal and perspectives. 3.1 Collaborative Task CollBot4us proposes collaborative task with spheres scattered over a table in predefined and symmetrical positions. Operators will have to catch objects, transport them to a disposal area and then release them until all objects of a specific kind are disposed. There are spheres outside the robots reach in which case the other operator (hereafter called collaborator) must help the former. User can drive the robot, obtain robot placement in space and control robot gripper positions and approach towards the objects (in this case, spheres). See green panel at the left side of Figure 1. In order to ensure that communication and coordination are effective, each operator must realize, even without communicating directly, the work progress of the collaborator. This progress includes [7]: what was done; how it was done (what strategies have been applied); what still has to be done to finish the task and; what the preliminary results are. As a consequence, each operator should be able to identify interdependent (sub) tasks before directing his actions. Figure 1 shows the CollBot4us simulator in perspective with the proposed task, called Puzzle. The goal is: “Together with your collaborator, discover what the task to be performed is and execute it in the shortest time possible”.

210

C. Dias et al.

1

2

4

3 5

Fig. 1. CollBot4us Simulator Presenting a Puzzle Task

3.2 Task Design Focused on Collaboration Each operator has a complete knowledge of the collaborator job status because CollBot4us is a 3D environment where navigation is free and it allows both operators to see any part of it. It must be observed that the displacement of the two robots in the scene leads to a partial overlap on their work space. In this case both operators have access to the same place, which allows the exchange of objects between robots. In an effort to encourage the exploration of the environment, communication and cooperative construction of a common goal, some of the Collaborative Requirements (CR) mentioned before were applied: Objects were distributed in order to increase the probability of collision and therefore the activities require much more attention from operators, and; some objects were placed so to appear that they are close to the reach of the robotic arm, but they are not. This fact encourages communication both to warn when an operator discovers this situation, since the scenario is symmetrical, and to ask collaborator to bring spheres into the reach of his robots. There are 18 spheres of three colors: blue, yellow and gray. A robotic arm can pick any sphere of any color. The operator will have to figure it out what is the color of the sphere he is supposed to pick as well as what is the color of his collaborator´s spheres. So, the operator must keep his attention to the collaborator´s actions for the purpose of being able to help him. The user has to find which color would lead to a successful disposal of spheres. One of the three colors exists only to represent an obstacle. There are spheres of direct manipulation (no help from the collaborator) where the operator can collect them and deposit them. In addition, there are spheres of indirect manipulation (which requires help from the collaborator) because they are out of reach of the robotic arm. In this case, mutual interactions among the operators are needed to collect the spheres and place them within the shared work space. The shared work

Design and Implementation of a 3D Collaborative Telerobotic Simulator

211

space is where there is a higher probability of collision, however. Thus, operators must acquire notions of spatial movements, and learn to control the robot to avoid collisions. There are two circular areas near the robots to dispose the spheres. Their colors and the colors of their respective deposits are different. This is another feature that operators have to figure it out. Two cones with some degree of transparency are included to serve as spatial references and obstacles. The color of the cone near the green robot is blue which coincides with the color of the spheres to be deposited by the green robot. The opposite occurs for the red robot, yellow cone and yellow spheres. The operator may make attempts to collect some spheres and if he manages to succeed and gather the meaning of the color in the scene he should give advice to his collaborator. A limit of 3000 possible manipulations for both two robots was set. An average of 130 manipulations per successfully disposed sphere is needed. For this reason, a global countdown displays the number of manipulations on the manipulation window, see item 2 in Figure 1. If this number comes to zero, the task fails. At the beginning of the task both the operators have 500 manipulations to start. Considering that first spheres are easier to be collected, operators must save manipulations for latter needs. The chat tool could help while performing this reasoning. For each sphere properly disposed, the pair wins a bonus amount of manipulations. Each operator can add a whole of 1250 manipulations. If the total manipulation is running out, the pair has to assess who is able to collect spheres using fewer movements for depositing them with success, in order to gain more manipulations. Therefore, an operator should be more careful and efficient to collect last spheres. For each collision detected, operators are penalized by losing 10 manipulations. The manipulation window shows the counter for monitoring collisions; see item 2 in Figure 1.The task ends successfully when all six spheres of each robot are properly deposited. Over time the operators might realize that it is a good idea to plan their strategies in advance in order to solve the task efficiently. Thus, the pair must work collaboratively to achieve a satisfactory result which requires awareness, coordination and communication. Through communication, the pair must build a common understanding, share ideas, discuss, negotiate and make decisions. Awareness of information is essential to ensure that communication and coordination are effective. So, each operator must understand the work that is been done by his collaborator: what was done, how it was done, what is missing for the ending and what are the preliminary results. 3.3 Metrics CollBot4us was implemented so that it collects a wide set of measurements that can be used to evaluate both the performance in the task itself as well as the collaboration between operators. For collaboration to occur, an environment has to allow a common view among users and a simple and intuitive form of interaction. And to check for collaboration, it is necessary to use qualitative and quantitative metrics in order to be able to infer success, performance and quality of collaboration. CollBot4us was implemented so that it is possible to automatically collect a systemwide set of measurements, such as: Number of attempts to grasp an objects; Elapsed time for gripping the first object; Elapsed time for disposing the first object; Total task

212

C. Dias et al.

time; Number of collisions with the environment; Number of collisions with the robot; Total number of commands, and; Total number of messages.

4 Implementation Object modeling was done using X3D [6] which allows to represent 3D interactive environments on the Internet. Also, the dynamics of the system was developed using Java language. One advantage of Java is to support platform heterogeneity. CollBot4us runs in the internet, so it should execute in almost all platforms (non extensive tests were made to confirm that but JVM – Java Virtual Machine –is the supporting technology that guarantees that). Processes communication across the computer network was implemented using Java RMI (Remote Method Invocation) [9] and the integration of Java to X3D was made possible thanks to an external authoring tool available from Xj3D [10]. In a distributed application like CollBot4us, the system works with distributed memory architectures. Two or more process communicates through message passing. The communication module was developed in Java RMI because a much higher level of abstraction was preferred than sockets (for instance). The communication doesn´t cause a bottleneck to the system with two virtual robots and Java RMI is appropriate to distribute objects. RMI encapsulates data and provides a communication protocol for transferring data over the network layer to the target machine as well as defines how and when exceptions can occur. The remote object determines which of its methods can be invoked by clients through an interface. Clients can identify how parameters are passed and returned to remote methods [2]. The RMI middleware abstracts all communications. For a client to communicate to a server, it only needs to identify the remote method and access an active object in a virtual machine [9]. 4.1 Communication Technology and Modules The communication module in CollBot4us is based on a Client/Server architecture [8] where the server coordinates all actions made by the robots (using message passing) and the clients are the green and red robots in each computer. The server is an object that can be invoked remotely. The server registers its name in rmiregistry tool as the Mediator. Rmiregistry stays on a public default network port number 1099. The server object publishes his methods through static class Naming and method rebind. When an operator hits the mouse or keyboard in order to operate his robot (say, to close the gripper) this is transformed into a message that is sent to the Mediator which acknowledges the message by forwarding the just received command to the pair of collaborators (including the one who sent the original message). When the message arrives in each Client, the 3D graphic scene is updated in that computer. So, clients command the actions to the respective robot but it only update his own scene when the server authorizes it. The actions of clients/operators are authorized one-by-one, so commands and scene updates are synchronized. Clients need to know the server location in the network (IP address and port number) before their execution and the server must be up and running. The task starts only when there are two operators registered in CollBot4us. The first operator informs

Design and Implementation of a 3D Collaborative Telerobotic Simulator

213

his nickname, IP address of the intended server and waits for a collaborator. When the second operator does his registry, CollBot4us establishes a collaboration pair and enables the task to start by producing a welcome message where the task description is given to both operators. After both operators acknowledge the welcome message, a timer starts off and each operator is freed to actually use the system by initiating a chat, operating their robots, changing viewpoints, selecting grip approach, etc. This whole initiating process is controlled by the communication module. In the server side, the system is composed of two modules: The Mediator is an object that implements the methods for message passing coordination between the virtual robots. Mediator is also responsible for accounting the collaboration metrics, and; Client/Server Communication Module consists in a communication public interface and middleware. It is responsible for establishing the communication between the server and the pair of clients. In the client side, the subsystem is composed of three modules: Client/Server Communication Module, has the same functions as defined in the server subsystem counterpart, however it is in the client side; Collaborator, is used to invoke the remote methods of communication between the virtual robots as well as passing chat messages and, interpreting authorized and synchronized actions to be executed on the robots on the local scene, and; Collbot4us, is responsible for rendering the 3D graphic scene, viewing control, robot direct kinematics calculations, grip approach control, collision detection, grasping simulation, feedback messaging, specific task loading, disposal analysis, presenting chat messages and, GUI functions.

5 Conclusions This work presented a 3D remote simulator with two robotic arms, called CollBot4us that implements a Multiple Operator Multiple Robots telerobotic approach. CollBot4us proposes collaborative robotic tasks to pairs of operators which could be in different locations over the computer network. The simulator captures metrics related to the collaborative process as well as to robotic manipulations. With CollBot4us it is possible to maintain the integrity of the operator and the robot as it is a simulated 3D graphical environment with task manipulation designed in order to foster the interdependence of actions and decisions among operators. CollBot4us differentials from previous work in that it put together features of three different areas: (i) robotics: two teleoperated 5 DoF articulated virtual robots are used; (ii) networking: a client/server communications architecture for synchronization with chat option for operators is available, and; (iii) collaboration: 3D collaborative robotic tasks which capture robotic handling metrics and tasks solving process. A set of metrics were proposed and implemented. These metrics are related both to the robotic task at hand as well as to the collaboration process. Therefore, CollBot4us represents, among other things, a platform for the study of collaboration, robotics and the issues of network communication and synchronization. The potential for CollBot4us to be used both as a telerobotic learning tool with the support of collaboration and/or, a collaborative learning tool with the support of Telerobotics appeared as an extra and interesting feature. Client and Server source codes can be downloaded free from http://www2.joinville.udesc.br/~larva/collbot4us/.

214

C. Dias et al.

Future works include using CollBot4us to investigate the correlation of some of the collaborative metrics to operators’ profile, gender, knowledge and other features. For instance, it seems interesting to investigate if pairs of female operators rely more on communication than men? What age-range pairs of men obtain the best overall performance? Is there a correlation between higher performance (lower time) and greater use of communication?

References 1. Chong, N., Kotoku, T., Ohba, K., Tanie, K.: Virtual Repulsive Force Field Guided Coordination for Multi-telerobot Collaboration. In: Proceedings of the 2000 IEEE International Conference on Robotics & Automation, Seoul, Korea, pp. 21–26 (2001) 2. Cioi, D., Vatau, S., Maniu, I.: Virtual Reality Laboratory for Robotic Systems. In: SACI Romanian-Hungarian Joint Symposium on Applied Computational Intelligence, Timisoara, pp. 1–8 (2006) 3. Collazos, C.A., Guerrero, L.A., Pino, J.A.: Evaluating Collaborative Learning Processes using System-based Measurement. Educational Technology & Society 10(3), 257–274 (2007) 4. Marek, J., Kemczinski, A., Hounsell, M., Gasparini, I.: Colaboração e Cooperação: Pertinência, Concorrência ou Complementaridade. In: Revista Produção On-Line UFSCABEPRO Florianópolis, SC, Brasil, vol. 7(3), pp. 396–401 (2007) ISSN: 1676-1901, (in Portuguese), http://www.producaoonline.ufsc.br; 5. Wang, X., Moallem, M., Patel, R.: An Internet-Based Distributed Multiple-Telerobot System. IEEE Transactions On Systems, Man, And Cybernetics-Part A: Systems And Humans 33(5), 627–633 (2003) 6. Brutzman, D., Daly, L.: X3D Extensible 3D Graphics for Web Authors. Elsevier Inc. (2007); ISBN-13: 978-0-12-088500-8 7. Fuks, H., Raposo, A.B., Gerosa, M.A.: Engenharia de Groupware: Desenvolvimento de Aplicações Colaborativas. In: XXI Jornada de Atualização em Informática, XXII Congresso da Sociedade Brasileira de Computação. ch. 3, vol. 2, pp. 89–128 (2002); ISBN 85-88442-24-8, (in Portuguese) 8. Farley, J.: Distributed Computing in Java, 2nd edn., vol. 1.O’ Rally & Associates (1998); ISBN 1-56592-206-9E 9. Borges, F.S., Freitas, A.L.C.: Estudo de Caso Sobre Programação Orientada a Aspectos Utilizando Protocolo RMI. Hífen 32(62), 41–50 (2008); (in Portuguese), ISSN 1983-6511 10. WEB3DCONSORTION. Open Standards for Real-Time 3D Communication, http://www.web3d.org/x3d (last access: October 15, 2009)

Hey yaa: A Haptic Warning Wearable to Support Deaf People Communication Maria Paula Saba, Denise Filippo, Fernando Reiszel Pereira, and Pedro Luiz Pereira de Souza Escola Superior de Desenho Industrial, Evaristo da Veiga 95, 20031-040, Lapa, Rio de Janeiro, Brazil {msaba,dfilippo,freiszel,pedro}@esdi.uerj.br Abstract. This paper investigates Hey yaa, a haptic wearable interaction system that allows sensory-motor communication through vibration. The system allows users to call each other attention through haptic sensation, without using voice or vision. Hey yaa, thereby, meets the special needs of the hearing impaired and works as an assistive technological solution to call people when they usually wouldn’t be able to do so. Hey yaa prototype consists of two waist belts. When a button is pressed in one, the other one vibrates, drawing the user’s attention. We evaluated Hey yaa concept and prototype regarding usability, usefulness, usage learning, communication with interlocutor and appearance. As a result, test users confirmed its relevance and gave directions for further improvement. Keywords: wearable, haptic interface, deaf communication, accessibility, assistive technology, hearing impairment computer aid.

1 Introduction Communication can be a difficult task for those who can’t hear. They talk through hand gestures and therefore they depend on visual contact to have conversations. We usually use our voices to call someone’s attention, but to do so deaf people necessarily need either visual or physical contact. For them, starting a conversation is difficult when the other one is not looking and it is not close enough to be touched. We focused in this particular problem, looking for an alternative way to call people through a tactile wearable. Interpersonal communication technologies usually rely on audiovisual and textbased, e.g. mobile phones, while touch has been left largely unexplored in this field. However, we believe there is a huge potential in haptic wearables systems. Our goal in this work is to explore how we can provide support to deaf through wearable computing. In this paper, we describe a new way of establishing communication through haptic feedback in a wearable device. The intention was to enrich current real-time communication by opening a channel through touch. We built a system called hey yaa, composed by two waist belts that allow users to communicate with each other through vibration. The interaction occurs by pressing a button in one belt, which triggers a vibration in the other belt, drawing the user’s attention and implying that another user wants his/her attention. After building the system, we evaluated it with potential users, both individually and in focus group A.S. Vivacqua, C. Gutwin, and M.R.S. Borges (Eds.): CRIWG 2011, LNCS 6969, pp. 215–223, 2011. © Springer-Verlag Berlin Heidelberg 2011

216

M.P. Saba et al.

research. The evaluation aimed at finding out how they interact with Hey yaa, what they think about comfort and appearance, and if they were interested in calling someone through vibration. The remainder of this paper is organized as follows. In the related work section we discuss previous work on haptic and wearable communication. Next, we present hey yaa and the design principles behind the system. While, in the following sections we describe the usability tests and their results. The last section concludes this paper and provides several future work directions. In this paper, we use the term “deaf” following the orientation that the people interviewed wanted to be called this way and not “hearing impaired”.

2 Related Work The area of haptic communication hasn’t been so much explored in commercial products but it can be found in many research ventures. Tactile devices present information to their users by stimulating the perceptual nerves of the skin. They can be really useful in situations where users are deaf, blind or when environmental factors don’t allow audio or visual input and output. The Tangible Media Group from MIT [1] explores the sense of touch in several areas. Regarding to interpersonal communication, they have developed inTouch [2], a system with two objects coupled in a haptic way such that each one receives other’s movement. The project’s goal was to explore a mean for expression through touch and not a practical application in daily life. Tactile sense has been also explored in wearable computing as a mean of navigation for the blind. Two popular forms of wearable tactile displays are a back array and a waist belt. The Wearable Haptic Navigation Guidance System, also from MIT [3], is a display consisting of a 4-by-4 array of micromotors for delivering haptic signals to user’s back in order to provide navigation guidelines, together with a wearable computer to route planning. An example of tactile display as a belt is ActiveBelt[4], a waist belt with GPS sensor and eight vibration motors spread around the belt that enables users to obtain multiple directional information. Both tactile displays – belt and array - have been compared in a posterior study, concluding that participants performed significantly faster and more accurately with the belt than with the array. Physical contact is a channel whereby people achieve a sense of connection and affection. Some projects try to simulate this affective feeling through haptic wearable systems, creating the sensation of physical link between people separated by distance. HugMe[5], also a commercial product HugShirtTM[6], is a system for hapto-audiovisual teleconferencing that enables people to exchange stimuli over a network. User must wear a haptic jacket that is embedded with arrays of vibrating motors. People can send hugs to a HugShirt user via mobile phones. Another project that exploits touch is SOS Stress Out Sourced [7], also from MIT. The networked wearable system allows users to receive body massages through haptic jackets anonymously. Differently from these projects, in this work we focus on haptic wearables to support people in establishing communication when visual, audible and physical contact is not possible and in noisy environments or in places where speech is not allowed, e.g., libraries. In particular, we investigate the difficulties of the deaf communication.

Hey yaa: A Haptic Warning Wearable to Support Deaf People Communication

217

3 Hey yaa In this section, we discuss the development of Hey yaa, including for which context it was developed, the design guidelines we set up and the prototype we built. 3.1 Context Communication among deaf happens through sign language. Some hearing impaired develop the capacity of reading the movements of lips, understanding someone’s talk only looking at the mouth. In both cases, message’s decoding occurs through visual interpretation of movements. That means visual contact is of great importance for hearing impaired and their main communication channel. Therefore, alert calls must be adapted for hearing impaired. For example, doorbells for deaf are usually connected to the house’s light, in a way that a visual sign replaces the sound sign. Another alternative is Hearing Dogs for Deaf People [8] consists of training dogs to alert deaf people to specific sounds, whether in the home, workplace or public buildings. It is an interesting alternative way for deaf perception of the environment, but it depends on having a dog, which can be unpleasant or not possible to everyone. In order to protect deaf children from coaches running over while they were playing in the streets, Graham Bell gave them air balloons. The deaf children could feel when a coach was coming by feeling the balloon’s vibration [9]. Deaf community also communicates via mobile devices. When using text-messages via cell phone, the vibrate setting was the alert mechanism for most users, even though it could be only occasionally detected [10]. In our project Hey yaa, we also investigate the use of tactile vibration for hearing impaired users. We suggest Hey yaa as a new medium for instant communication. Through a wearable device, one can send vibration to other as an alert mechanism. The metaphor is that vibration represents someone shaking or poking another person for attention, meaning “I want to talk to you”. The main concept is to provide haptic communication between two people, in a linear reaction, where one calls another through vibration. This concept can be applied to several daily life situations,

Fig. 1. Hey yaa changing deaf people’s routine: calling someone in other room can be done without need of physical contact (the man uses the belt below his shirt)

218

M.P. Saba et al.

changing people’s routine. Supposing one is in the kitchen and the other person is in the living-room. If one of them can’t hear, they are not able to call each other. The use of Hey yaa would change this situation and they would just press a button to achieve the same goal, modifying the user’s routine, as can be seen in Figure 1. Differently of mobile phones, Hey yaa is a wearable system, therefore it has the advantage of easy mobility and constant contact with the body, increasing the effectiveness of the call. Another scenario is when a person is sick in bed and need to call someone in other room, or even when two persons are working in bays and can’t see each other. When walking in the street, deaf people can use Hey yaa when one person moves away some meters from the other – situation in which a mobile phone wouldn’t be helpful. Besides peer-to-peer current communication, it can also bring other possibilities for improving deaf routine: they could be linked to systems such as doorbells. The system could be enhanced and integrated with other technologies, such as GPS, voice recognition or identification of sound direction so they could be notified, for example, when they pass by a specific address or when certain soundalerts are triggered. It could also advice from which direction some defined word, e.g. a name, is being called. 3.2 Design Guidelines Hey yaa must create a haptic channel between two users. In order to achieve an adequate usability, several guidelines underlie the design of the system and the choice for being a wearable device. They are: - The system must be ubiquitous, being present all time. However, while interaction doesn’t happen, it must keep a peripheral position at user’s attention. - Hey yaa is a product to be used throughout daily routine: users must carry the system easily, maintaining the product next to their bodies all the time. - Calling one’s attention might be an urgent task. Easy handling must be provided. - Vibration must be strong enough to draw user’s attention. The vibe board needs to be as close as possible to user’s skin, located in an area of high sensibility. - Feedback must be provided to confirm the other user has received the call. -Appearance: how a wearable should look like – computers or clothes? Impressions people have while looking for an enlightened interactive piece of clothing are totally different when looking for common clothes. It is important to let users decide which message they will be transmitting through the pieces they wear and if they want to show that they are wearing computers. - It should be discrete enough to be used in public spaces without being heavily noticed by others. It should be seen as an ordinary accessory. - It was chosen to be an accessory instead of a piece clothing to reduce, or even to eliminate, the need of washing. 3.3 Prototype In this first prototype version, Hey yaa was built as a pair of 10 cm wide belts that allow 2 users to call each other’s attention by sending vibrations. In our prototype, when a button in one belt is pressed, the other one vibrates. To provide feedback to the calling user, the sending belt also shakes to confirm the message was received by the called one. In this way, the user will always know when the other belt is working.

Hey yaa: A Haptic Warning Wearable to Support Deaf People Communication

219

To build our prototype we selected the Lilypad Arduino microcontroller and its accessories, specially designed for creating wearables [11], and added a transceiver/receiver module from Digi International, since the Lilypad family product doesn’t include one. The components to set up one Hey yaa belt are: 1 microcontroller Arduino 328 board, 1 battery and its holder, 1 vibe board, 1 button and 1 Xbee 2.5 transmitter/receiver and its holder. Since the system is designed for users nearby, the prototype does not need to work in long distances. All components were placed in the exterior side of the belt, except the vibe board, which was placed in the inner part of the belt to be closer to the skin. In order to provide choice for users, we designed a buckle that enables handling the belt in different ways: to hide or show up electronic components, as can be seen in Figure 2.

Fig. 2. Hey yaa belt in two different ways: hiding or showing the electronic components

4 Evaluation For evaluating our prototype, we performed usability tests with participants with whom we have direct communication through voice (individual tests) and a focus group conducted with deaf people and aid of translator (focus group). 4.1 Individual Tests Usability tests were performed with 5 people: 3 young people and 2 adults, 3 women and 2 men. All could hear and talk, with exception of one hearing impaired girl, who was able to talk but hears partially and does lip-reading most of time. Users had to accomplish the following tasks: to wear the belt, to turn it on, to make it work by sending and receiving vibrations to and from the interviewer’s belt in the same room. Later, he/she was asked to walk around in other rooms or out of the building and return when he/she felt the belt vibrating. At first, no help was provided to them. When someone could not succeed in one task, a printed manual was given to help. After returning, users had to fulfill a multiple choice written questionnaire. Questions were about belt interface, learning to use the system, communication with interlocutor and appearance. Then, open questions were made orally in an interview and video recorded. The results were: - All users considered the belt easy to dress and undress. - All of them, except the hearing impaired girl, had difficulties to turn on the belts. They had to use the printed manual to accomplish the task.

220

M.P. Saba et al.

- All complained about the switch button to turn on/off the belt. This button is from the Lilypad battery holder and it was considered too small and too discrete. - They reported it was easy to locate other belt components, such as the call button, as well as to feel its vibration. - Despite the initial difficulty of finding how to turn on the belt, all users have learned quickly how to do it, registering the task of turning on the belt as easy. - 3 of 5 were concerned about getting an electric shock. The same 3 also said they usually feel comfortable when using technological devices. Meanwhile, those 2 who were not concerned with electrical shocks reported they usually feel uncomfortable with technology. - They considered easy to call another person through the belt, pressing the button once or twice in each call. A user compared the system to a walkie-talkie, suggesting people could create their own code for communicating. - It was also considered simple to feel the calling. 4 of 5 users could strongly perceive the call’s vibration, feeling it with ease. - All interviewed considered feedback vibration really useful because they could be sure the call was received by other. 3 of 5 showed spontaneously interest in having different levels of vibration for users to choose from. - 3 people said they would like to use it in daily life, pointing their home and work as main places where they would use it. From this group, 2 revealed they would buy the belt depending on its price and the hearing impaired one said she wanted to buy it, regardless of the price. In the conversation, she also asked for an implementation of the system in her home, creating an environment connected to the belt in order to be aware of the doorbell or the telephone. - Aesthetically, 2 users found it “pleasant”, 2 “neutral” and 1 “unpleasant”. This last one also found it very uncomfortable, and complained that it was too big. The 4 others found it “comfortable” or “very comfortable”. - Concerning to the electric components, 3 of them were not bother by their appearance and size, saying that they understand it is necessary to function, while 2 said clearly that they preferred it to be smaller and more discrete. As conclusion of the individual testing, people were interested in the product’s concept, but they would only buy it if they had any specific need, such as hearing problems or living with elderly. The belts were considered good, but its on/off switch button could be improved in order to become bigger and more visible. It could also be added the possibility of choosing vibration levels. 4.2 Focus Group For focus group evaluation we have selected as target deaf adults older than those of the previous test. We choose a deaf pastoral group from a church and communicated with them with the aid of a language translator that also takes part of this group. The decision for focus group evaluation was considered adequate both as a way to have insights, explore feelings and attitudes about a new product [12] and as a way to facilitate and provide a better communication with users that are not able to talk.

Hey yaa: A Haptic Warning Wearable to Support Deaf People Communication

221

Before conducting the focus group, this pastoral group was visited for allowing us to be introduced and to evaluate receptiveness to the product concept and feasibility of a group research with them. They were receptive to the idea, imagining several situations they could use it in daily life. In the second meeting, we conducted the focus group. The Hey yaa prototype was taken to them so they could experience it (Figure 3). There were 6 women and 4 men, all between 45 and 70 years old. This focus group took 40 minutes long and was video recorded. First, we presented the belt in a 3-minute explanation of its basic functionality - calling person by pressing a button and being called through a vibration on the belt - without showing how to operate it. This was accomplished with the help of the translator. Then, they were allowed to try the system freely, asking for help to put it and handle it when necessary and avoiding any embarrassing situation. We didn’t establish any rules, since we wanted to investigate what calls first their attention and if it was easy to learn how to use it. Once they tried it on and felt the system working, the participants revealed to be very interested in knowing how far the system reached. In the space where the focus group was held, a classroom near the church and the paths around it, they reached up to 20m. They also helped themselves to wear and use the belts, when needed. Women were much more interested: all tried the belt. On the other hand no men tried it. After testing Hey yaa functionality, open questions were asked to the whole group. They were asked about their perceptions, opinions and beliefs towards the evaluated system: comfort, appearance, scenarios in which they would use it. All of them enjoyed the project idea, even the men. They called it good and beautiful and indicated some improvements that could be done. The first and most emphasized was the vibration intensity. They considered it too low, as they would not feel it in daily use. It was a totally opposite result comparing to the hearing people results, which claimed vibration to be enough or sometimes too strong, even tickling (Lilypad vibe board has a frequency of 12.000 rpm and 0.8 G amplitude).

Fig. 3. Hey yaa focus group with Deaf Pastoral of Rio de Janeiro

Regarding to appearance, most of them were pleased, although one of them stated that she would like it to be thinner. Three participants tried it on under their clothing, but they didn’t feel comfortable and reported that it was more difficult to press the button. Those also reported that using under their clothing could be very hot. They considered using the belt in private places, such as home, work and parties. They mention a scenario in which an ill person in bed calls someone in another room or in which you need to call someone at work. They said it wouldn’t be useful in

222

M.P. Saba et al.

public places, as in the streets: 2 women explained that in a street one might be very far apart from another and in this case they would use their cell phone instead.

5 Conclusion We have presented Hey yaa, a wearable interaction system for haptic interaction that creates a channel where information can be sent and received through touch. The system prototype was developed as two belt-type devices that enable users to draw each other’s attention by sending vibrations. Hey yaa was evaluated in two different manners: individually, with people who hear and talk with us, and in a focus group of deaf people. It was largely accepted by users, regardless of their ages, to the point that 3 test participants revealed themselves interested to buy it. It has also brought up many situations in which Hey yaa could be applied to improve people’s lives. Besides the results presented concerning the usability, easy learning, applicability of the system and appearance, this work provides a set of guidelines to be considered in the design of a peer-to-peer communication wearable. Further development of this research are: improving the current system according to user’s feedback and performing immersion tests to evaluate the belts in daily constant use. It is important to find out whether the vibration is noticeable at any moment, even when the system is in a peripheral spot of user’s attention. We plan to implement Hey yaa prototype to be interactive for multiple users, in a way people could identify whom they are calling and who is calling them or send a broadcast call. We also plan to explore the use of codes through different ways to press the button, such as one person warning the other about urgency with a long press of the button or pressing it many times. Haptic communication can bring several opportunities to wearable computing development, especially as an assistive technology. Although touch cannot replace vision or hearing, it can work as complementary aid, allowing different and innovative kinds of interaction, yet unexplored. Many are the possibilities of development for the Hey yaa concept. With this work, we hope to show some paths of how wearable computing together with haptic communication can bring improvements to deaf people’s lives. Acknowledgments. We would like to thank the Deaf Pastoral of Rio de Janeiro and all others volunteers for participating in our usability tests.

References 1. Tangible Media Group, http://tangible.media.mit.edu/ 2. Brave, S., Ishii, H., Dahley, A.: Tangible Interfaces for Remote Collaboration and Communication. In: Proceedings of CSCW (1998) 3. Ertan, P., Lee, C., Willets, A., Tan, H., Pentand, A.: A Wearable Haptic Navigation System Guidance. In: 2nd International Symposium on Wearables Computers, pp. 164– 165 (1998) 4. Tsukada, K., Yasumrua, M.: ActiveBelt: Belt-type Wearable Tactile Display for Directional Navigation. In: Proceedings of UbiCom 2004, pp. 384–399 (2004)

Hey yaa: A Haptic Warning Wearable to Support Deaf People Communication

223

5. Cha, J., Eid, M., Rahal, L., Saddik, A.: HugMe: An Interpersonal Haptic Communication System. In: IEEE International Workshops on Haptic Audio Visual Environments and their Applications, Canada (2008) 6. HugShirt from CuteCircuitTM, http://www.cutecircuit.com/products/thehugshirt/ 7. Stress Outsourced, http://www.stressoutsourced.com/ 8. Hearing Dogs for Deaf People, http://www.hearingdogs.org.uk/ 9. Bodanis, D.: Electric Universe: The Shocking True Story of Electricity, New York (2005) 10. Henderson-Summet, V., Grinter, R., Carroll, J., Starner, T.: Electronic Communication: Themes from a Case Study of the Deaf Community. In: Baranauskas, C., Abascal, J., Barbosa, S.D.J. (eds.) INTERACT 2007. LNCS, vol. 4662, pp. 347–360. Springer, Heidelberg (2007) 11. Lilypad Arduino, http://web.media.mit.edu/~leah/LilyPad/index.html 12. Fern, E.F.: The use of focus groups for idea generation: the effects of group size, acquaintanceship and moderator on response quantity and quality. Journal of Marketing Research XIX, 1–13 (1982)

Trusty: A Tool to Improve Communication and Collaboration in DSD Gabriela Noemi Aranda1, Aurora Vizcaíno2, José Luís Hernández2, Ramón R. Palacio3, and Alberto L. Morán3 1 GIISCo Research Group, Facultad de Informática, Universidad Nacional del Comahue, Neuquén, Argentina [email protected] 2 ALARCOS Research Group, Information Systems and Technologies Department, UCLM-INDRA Research and Development Institute, Universidad de Castilla-La Mancha, Ciudad Real, Spain {aurora.vizcaino,joseluis.hernandez}@uclm.es 3 Facultad de Ingeniería, Facultad de Ciencias, Universidad Autónoma de Baja California, Ensenada, México {rpalacio,alberto_moran}@uabc.mx

Abstract. Distributed Software Development (DSD) projects frequently confront the problem of a lack of face-to-face interaction, which is a great obstacle in informal communication. Since informal communication is the means by which people normally discover facts about their co-workers, thus leading to their mutual trust, we have designed a tool called Trusty with which to support DSD. In this paper we describe the main characteristics of Trusty, which provides mechanisms to support communication, coordination, knowledge management and other capabilities such as the statistical analysis of those networks which are valuable in virtual environments.

1 Introduction It is a fact that the number of enterprises whose teams are distributed across the limits of a country has undergone continual growth in the last decade. The software industry is also part of this tendency, and Distributed Software Development (DSD) has become a common means of producing software. However, it is well known that, although distributed software development projects are more and more common, there is still a number of challenges that causes a varied range of problems in such settings [18]. For example, the lack of face to face communication between people on distant sites leads to very little informal communication in DSD teams [13], while informal communication supports different kinds of functions which not only concern workrelated activity execution and coordination [23], but also social functions which are particularly related to trust building [12]. Since a team spirit depends both on how well people know each other and the level of trust between them [5], improving communication and trust building in DSD environments is a necessity, and information and communication technologies are the best means towards this end A.S. Vivacqua, C. Gutwin, and M.R.S. Borges (Eds.): CRIWG 2011, LNCS 6969, pp. 224–231, 2011. © Springer-Verlag Berlin Heidelberg 2011

Trusty: A Tool to Improve Communication and Collaboration in DSD

225

[12]. For example, good mechanisms through which to promote interactivity between individuals and share information about them are web-based social networks (WBSN) [9, 21]. WBSN can easily be applied in DSD virtual teams, but using public social networks in a work environment may be problematic since people join them to share information related to private aspects of their lives with their friends and family, and not work related aspects. As an alternative, it is possible to use a social network as an intra-organization tool (Work Social Network) to help employees to communicate in such a way that workmates can obtain an “expressive picture” of their colleagues at a personal and professional level [9]. Bearing this in mind, we first carried out a survey in different companies that run distributed software development projects, in which we inquired about the information that people usually know and would like to know about their distributed co-workers. The results of the analysis of this survey were used as a starting point for the design of our tool, denominated as Trusty. The remainder of the paper is structured as follows: First, we introduce Trusty, our tool for social knowledge management in DSD projects, and later we compare it with related works. Conclusions and future work are addressed in the final section.

2 Trusty As it was mentioned above, Trusty is a tool which was designed to support the distributed software development process. Considering that social ties and knowledge sharing have been reported as key elements for successful collaboration in GSD environments [14], we designed Trusty to have the following main capabilities: 

It provides useful information about co-workers, focusing on easing the communication among team members.  It provides mechanisms through which to share informal information in order to increase the friendship among members and, consequently, the team’s spirit of trust.  It provides mechanisms to support communication by means of a set of groupware tools.  It provides mechanisms to support knowledge management.  It provides mechanisms to support coordination by means of event creation and sharing.  It provides reports and statistical analyses about the social network supported by the tool in order to help project leaders to obtain feedback about members’ interactions. A description of how each of these capabilities has been implemented in Trusty is presented as follows. 2.1 Providing Useful Information about Co-workers In order to design Trusty according to the actual needs of people working in DSD environments, we carried out a survey based on the principal question: What information do stakeholders consider to be important with regard to their partners? The questionnaire was sent to virtual team members in 7 companies that run DSD and GSD projects, with headquarters in Spain, USA, and Argentina. 36 questionnaires were analysed from different perspectives, whose results were presented and

226

G.N. Aranda et al.

discussed in [1]. Doing so, we defined three categories: A (data items that most people considered to be very useful), B (data items that people considered to be useful), and C (data items that most people did not consider to be useful). Then we designed Trusty to cover all the information items in categories A and B. Only one data item from category C (gender) was included despite its not having been considered useful by most people in the survey, since Trusty has been designed for use in globally distributed environments (where different languages and cultures are involved) and gender cannot usually be easily inferred from a name, while it may be necessary for a first contact (for example, for the appropriate use of the title Mr. or Ms.). Distributed developers need to be aware of one another, at a general level for the entire team and in a more detailed way for people they plan to work with [11]. Furthermore, we considered that people that work or have worked together, might want to share more information about them. To do so, we decided to group data items into three different profiles (public, project and personal) to allow the information to be organised correctly and to provide suitable levels of privacy. As shown in Figure 1, these profiles are nested; the public profile provides less information but can be accessed by everybody in the organization. The project profile includes the information in the public profile and adds information that may be valuable for the project’s execution. Finally, the personal profile includes information on the public and project profiles and adds information that can only be accessed by a selected group of people.

Public profile

Organization

Project profile Personal profile

Project co-workers

Work friends

Fig. 1. Relationship between Trusty profiles and their level of access

The public profile shows general information about stakeholders. It is therefore visible to all the people in the organization in order to provide a starting point for communication between them. The information shown in this profile includes the data items that obtained the highest usefulness rankings in the survey (first name, contact information such as email address and phone number, and the time and the manner in which people prefer to be contacted) and other items that were considered to be important for a first contact, such as last name, gender, nationality, native language and level of knowledge of foreign languages. An example of a view of this profile is shown in Figure 2. As it was explained previously, the project profile includes all the information in the public profile, but it particularly appends project related information, such as role

Trusty: A Tool to Improve Communication and Collaboration in DSD

227

in the project, current activities, forthcoming events, etc. Information concerning people skills (such as best known programming languages or technologies) is also included. This information is useful to discover who is an expert in a particular topic. When a person has a problem, s/he can therefore search for an expert and contact him/her. Our idea is to take advantage of other people’s experience and avoid reinventing the wheel, a situation that often occurs in software development [19]. Furthermore, information about people’s geographical location (country, city, time zone) is considered.

Fig. 2. Public profile view

This information is important if we wish to know the most suitable time to contact somebody, as it lets us know what the time is at that moment on other sites. This profile is only visible to those people who are participating on the same project. The idea of this profile is, therefore, to share information about the members who are working on the same project, which might make communication and coordination easier. Finally, the personal profile includes other data items that are specifically related to the person in order to encourage interpersonal interaction. The information added in this profile is related to studies, work experience, cultural aspects, etc. It is only visible to people that have been previously accepted as “friends”. Its goal is to give people the opportunity to share more information about them and to provide a

228

G.N. Aranda et al.

channel for informal communication in virtual teams, with the objective of increasing mutual knowledge and helping in trust building. 2.2 Providing Mechanisms to Support Communication Given the lack of face to face communication, tools providing support in DSD environments must offer other communication channels. Trusty does this by incorporating three different mechanisms: the wall, private messages, and chat. The wall is a place, which is only available to users that have access to personal and project profiles, where the owner of the account or other users may post a comment. This comment can be answered or commented on by the other users. It works as a blackboard where it is possible to leave reminders, greetings, etc. This tool is important in DSD, especially for general announcements, when sites are in different time zones and asynchronous communication is crucial. It is recommended for short messages but is not suitable for discussions. Another possibility for communication in Trusty is the use of private messages. In contrast to the wall, where posts are seen by all the people that have access to personal and project profiles, private messages are only visible to the author and the recipient/s of the message. It is also possible to attach documents to a private message. It is an asynchronous tool which is recommended for short discussions. Trusty allows access to received, sent and deleted messages, and also allows searches to be performed by using different criteria. Trusty additionally offers the chat tool, an instrument for synchronous communication. Different kinds of chat-rooms are available. First, there is an open chat-room for all the organization’s members. There is also a chat-room for each project which only members of that project can enter. Finally, users can create chatrooms for private usage with one or more colleagues. One important characteristic of tools to support distributed software development is the existence of a mechanism to detect availability for contact. For example Lilsys [4] uses ambient sensors to collect cues and uses this information to infer availability. On the contrary, Trusty includes a mechanism to help identifying the best moment to initiate communication with other users based on their personal preferences. To do this, user profiles in Trusty show information about the user’s working hours, the time at his/her site, his/her current status regarding availability (see right-hand side of Trusty screens in Figure 2), his/her preferred time to be contacted, etc. It should be highlighted that some of this information is provided by users at profile definition time. Moreover, in order to make this information clearer for the users, Trusty represents the user’s status with a colour code similar to that of CWS [15]. This colour code is guided by selective availability criteria [16], such as "I am available only to people who are related to the task I am dealing with now and am not available to other people”. Trusty does this by using different colours on the photo frame in the panel on the right of the screen in order to indicate whether or not it is an appropriate moment to start a synchronous interaction with the other person. There are five possible colours (blue, green, yellow, orange and red). Table 1 shows the colour code for the photo frame, taking into account the setting of the current status and the time at the site with regard to the hours at which that person prefers to be contacted. We thus attempt to encourage people to contact others by considering the most suitable moment for the receiver of the interaction, since it has been found that workers are continually interrupted by synchronous communication technologies (e.g.

Trusty: A Tool to Improve Communication and Collaboration in DSD

229

telephone and instant messenger), which have been reported to be constant sources of disruption [2, 6]. In addition, it has been shown that interruptions have a negative impact on task completion time [6, 7], decision-making [17, 20], and people’s emotional state [3]. Interruptions may also result in prospective memory failure [7, 10], which refers to an individual’s problem in remembering what s/he has to do as regards a planned task (or in this case, the interrupted task). Table 1. Photo frame colour code meaning

Frame colour

Is s/he connected?

Is current time within the interval of his/her working hours?

Is current time within the interval of preferred time to be contacted?

Meaning

Blue

No

?

?

Disconnected

Red

Yes

No

No

Connected but not available

Orange

Yes

Yes

No

Probably available for contact

Yellow

Yes

Yes

Yes (Time is close to the end of his/her preferred interval)

Available for a short time

Green

Yes

Yes

Yes

Available for contact

2.3 Supporting Coordination Coordination in DSD virtual teams is crucial because of the geographical dispersion of their members. In order to help support coordination Trusty provides a Calendar on which forthcoming events are displayed. Events can be created, consulted, and deleted. Invitations for a given event can also be sent to other users. Past events are kept in the system but they are shown in grey. Forthcoming and past events can be consulted by means of a search and filter mechanism. There are three different kinds of events:   

General work events: These events are displayed in yellow. They represent work related events that are not related to the project/s the user is working on. Project events: These events are displayed on the calendar in red. They represent work related events specifically related to topics on the project/s on which the user is working. Personal events: These events are displayed in blue. They represent personal events like reminders of birthdays, family celebrations, etc.

2.4 Supporting Network Analysis One of the main capabilities included during the design of Trusty was to obtain information about the usage of the tool by team members. This information may, for example, be useful to detect message overload to a particular person or the lack of interaction between certain team members.

230

G.N. Aranda et al.

The algorithm that implements this capability is based on Social Network Analysis (SNA) [22], a paradigm widely used in social and behavioural sciences and developed over the last decades by researchers in psychology, sociology, and anthropology. The analysis concerns different levels, such as actors, groups, subgroups, along with the social network as a whole. The information is shown as a graph on which nodes represent Trusty users. This statistical mechanism is accessible to project managers and system administrators. The tool can be used to analyze various aspects of interaction in the social network, including message traffic, event publication, wall usage, profile visits, and knowledge repository usage.

3 Conclusions and Future Work This paper describes a tool which has been implemented to solve some of the typical problems that take place in DSD. The main goal when designing this tool was to increase trust among team members. In order to fulfil this goal it was necessary to know what information engineers considered it was important to know about their colleagues. This information was obtained by means of a survey. Other features have also been added to improve communication and coordination. As future work we plan to evaluate the prospective and actual use of Trusty. With regard to prospective use, we plan to conduct a scenario-based evaluation of the tool with the same group of pilot users from the survey study. Concerning actual use, we plan to conduct an in-situ evaluation at a multinational software factory that is interested in using Trusty in its DSD projects. These evaluations will focus on the usability and ease of use of the tool, and we plan to use both the SUS (System Usability Scale) and TAM (Technology Acceptance Model) scales [4, 8]. Acknowledgements. This work has been funded by the PEGASO/MAGO project (Ministerio de Ciencia e Innovación MICINN and Fondos FEDER, TIN2009-13718C02-01). It is also supported by MEVALHE (HITO-09-126), ENGLOBAS (PII2I090147-8235) and GLOBALIA (PEII11-0291-5274), funded by Consejería de Educación y Ciencia (Junta de Comunidades de Castilla-La Mancha) and co-funded by Fondos FEDER (Spain), as well as, ORIGIN (IDI-2010043 (1-5)) funded by CDTI and FEDER.

References 1. Aranda, G., Vizcaíno, A., Palacio, R.R., Morán, A.L.: What information would you like to know about your co-worker? A case study. In: ICGSE 2010, 5th International Conference on Global Software Engineering, Princeton, US, pp. 135–144 (2010) 2. Bailey, B.P., Iqbal, S.T.: Understanding changes in mental workload during execution of goal-directed tasks and its application for interruption management. ACM Transactions Computer-Human Interaction 14(4), 1–28 (2008) 3. Bailey, B.P., Konstan, J.A.: On the need for attention-aware systems: Measuring effects of interruption on task performance error rate and affective state. Computers in Human Behavior 22(4), 685–708 (2006) 4. Brooke, J.: SUS: A quick and dirty usability scale. In: Thomas, B., Jordan, P.W., Weerdmeester, B.A., McClelland, I.L. (eds.) Usability Evaluation in Industry, London, UK, pp. 189–194 (1996) 5. Carmel, E.: Global software teams: collaborating across borders and time zones, vol. 269. Prentice Hall PTR, Upper Saddle River (1999)

Trusty: A Tool to Improve Communication and Collaboration in DSD

231

6. Cutrell, E.B., Czerwinski, M., Horvitz, E.: Effects of instant messaging interruptions on computing tasks. In: CHI 2000 Extended Abstracts on Human Factors in Computing Systems, pp. 99–100. ACM, New York (2000) 7. Czerwinski, M., Horvitz, E., Wilhite, S.: A diary study of task switching and interruptions. In: SIGCHI Conference on Human Factors in Computing Systems, pp. 175–182 (2004) 8. Davis, F.: Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology. MIS Quarterly 13, 319–340 (1989) 9. DiMicco, J., Millen, D.R., Geyer, W., Dugan, C., Brownholtz, B., Muller, M.: Motivations for Social Networking at Work. In: CSCW 2008, ACM Conference on Computer Supported Cooperative Work, San Diego, California, USA, pp. 8–12 (2008) 10. Ellis, J., Kvavilashvili, L.: Prospective memory in 2000: Past, present and future directions. Applied Cognitive Psychology 14, 1–9 (2000) 11. Gutwin, C., Penner, R., Schneider, K.: Group awareness in distributed software development. In: 2004 ACM Conference on Computer Supported Cooperative Work, Chicago, Illinois, USA, pp. 71–81 (2004) 12. Harell, G., Daim, T.U.: Virtual Teams and the Importance of Building Trust. IT Professional 11(6), 46–49 (2009) 13. Herbsleb, J.D., Moitra, D.: Guest Editors’ Introduction: Global Software Development. IEEE Software 18(2), 16–20 (2001) 14. Kotlarsky, J., Oshri, I.: Social ties, knowledge sharing and successful collaboration in globally distributed system development projects. European Journal of Information Systems 14, 37–48 (2005) 15. Palacio, R.R., Morán, A.L., González, V.M.: CWS: An Awareness Tool to Support Starting Collaboration in Global Software Development. The Open Software Engineering Journal, Special Issue on Global Software Development and its Challenges, 38–51 (2010) 16. Palacio, R.R., Morán, A.L., González, V.M., Vizcaíno, A.: Collaborative Working Spheres as support for starting collaboration in distributed software development. In: 3rd International Conference on Computer Supported Cooperative Work in Design, pp. 636–641 (2009) 17. Prikladnicki, R., Audy, J., Evaristo, R.: Distributed Software Development: Toward an Understanding of the Relationship between Project Team, Users and Customers. In: 5th International Conference on Enterprise Information Systems (ICEIS 2003), pp. 417–423 (2003) 18. Richardson, I., Casey, V., Zage, D., Zage, W.: Global Software Development – the Challenges. University of Limerick, Ball State University: SERC Technical Report 278. p. 10 (2005) 19. Schach, S.R.: Object-Oriented and Classical Software Engineering. McGraw-Hill, New York (2006) 20. Speier, C., Vessey, I., Valacich, J.S.: The effects of interruptions, task complexity, and information presentation on computer-supported decision-making performance. Decision Sciences 34(4), 771–797 (2003) 21. Staab, S., Domingos, P., Mika, P., Golbeck, J., Ding, L., Finin, T., Joshi, A., Nowak, A., Vallacher, R.R.: Social Networks Applied. IEEE Intelligent Systems 20(1), 80–93 (2005) 22. Wasserman, S., Faust, K.: Social Network Analysis: Methods and Applications (Structural Analysis in the Social Sciences). Cambridge University Press, Cambridge (1994) 23. Whittaker, S., Frohlich, D., Daly-Jones, O.: Informal workplace communication: what is it like and how might we support it? In: SIGCHI Conference on Human Factors in Computing Systems: Celebrating Interdependence, Boston, Massachusetts, USA, pp. 131– 137 (1994)

Author Index

Adege, Ayneta 110 Amiyo, Mercy 175 Aranda, Gabriela Noemi

Lapasini Leal, Gislaine Camila Linnemann, Martin 110 Lukosch, Stephan 126

224

Baloian, Nelson 14 Berkenbrock, Carla Diacui Medeiros 207 Bourdeau, Jacqueline 1 Briggs, Robert O. 126 Buttler, Tanja 126 Castro, Alberto 158 Castro, Thais 158 Chaves Steinmacher, Ana Paula

Martins, Paulo 102 Matzdorf, Thomas 110 Mizoguchi, Riichiro 1 Mor´ an, Alberto L. 224 Morgado, Leonel 102 Nabukenya, Josephine

30

Olivier, Hannes

175

89

de Melo Bezerra, Juliana 57 de Souza, Cleidson R.B. 73 de Souza, Pedro Luiz Pereira 215 Dias, Claudinei 207 dos Santos, Ismael H.F. 191

Palacio, Ram´ on R. 224 Paredes, Hugo 102 Pereira, Fernando Reiszel 215 Pillon, Maur´ıcio Aronne 207 Pinkwart, Niels 89

Filippo, Denise 215 Fonseca, Benjamim 102 Fuks, Hugo 158

Rafael, Lt. Jorge 102 Raposo, Alberto 191 Robertson, David 158 Rodrigues, Paulo G. 191 Rohde, Markus 81

Gerosa, Marco Aur´elio 142 Gomes do Amaral, Wagner 191 Gutierrez, Francisco 14 Hatsue Moriya Huzita, Elisa 30 Hayashi, Yusuke 1 Hern´ andez, Jos´e Lu´ıs 224 Hirata, Celso Massaki 57 Horton, Graham 110 Hounsell, Marcelo da Silva 207 Irandoust, Hengameh Isotani, Seiji 1 Janeiro, Jordan

45

Treccani, Pedro J.F.

110

81

Zurita, Gustavo

14

142

73

Vivian, Rafael Leonardo Vizca´ıno, Aurora 224 Wulf, Volker

126

Knoll, Stefan Werner

Saba, Maria Paula 215 Saeed, Saqib 81 Santos de Oliveira, Lucas Schumann, Jana 110 Souza, Rog´erio P. 191

30

30