GMD Research Series GMD Forschungszentrum Informationstechnik GmbH Markus Sohlenkamp Supporting Group Awareness in Multi-User Environments through Perceptualization N° 6/1999 © GMD 1999 GMD Forschungszentrum Informationstechnik GmbH Schloß Birlinghoven D-53754 Sankt Augustin, Germany Telefon +49 -2241 -14 -0 Telefax +49 -2241 -14 -2618 http://www.gmd.de In der Reihe GMD Research Series werden Forschungs- und Entwicklungsergebnisse aus der GMD zum wissenschaftlichen, nicht- kommerziellen Gebrauch veröffentlicht. Jegliche Inhaltsänderung des Dokuments sowie die entgeltliche Weitergabe sind verboten. The purpose of the GMD Research Series is the dissemination of research work for scientific non-commercial use. The commercial distribution of this document is prohibited, as is any modification of its content. Anschrift des Verfassers/Address of the author: Markus Sohlenkamp Auf der Schleide 93 D-53225 Bonn E-mail: sohlenkamp@acm.org Die vorliegende Veröffentlichung entstand im/ The present publication was prepared within: Institut für Angewandte Informationstechnik (FIT) Institute for Applied Information Technology http://fit.gmd.de/ Die Deutsche Bibliothek - CIP-Einheitsaufnahme: Sohlenkamp, Markus: Supporting Group Awareness in Multi-User Environments through Perceptualization / Markus Sohlenkamp. GMD Forschungszentrum Informationstechnik GmbH. - Sankt Augustin : GMD Forschungszentrum Informationstechnik, 1999 (GMD Research Series ; 1999, No. 6) Zugl.: Paderborn, Univ., Diss., 1998 ISBN 3-88457-355-1 ISSN 1435-2699 ISBN 3-88457-355-1 Abstract Rapidly growing, widely used computer networks on the one hand and the emergence of flat, decentralized, distributed organizations on the other hand dramatically increase the demand for computer support of cooperative work. Although computer-supported cooperative work (CSCW) has been a research topic for quite a while and even software industry begins to adopt corresponding concepts, convincing solutions are still rare. This is due to a variety of reasons, ranging from social and organizational problems to purely technical issues. Frequently, groupware systems are little more than single-user applications with added connectivity. In particular, the user interfaces of many CSCW systems suffer from their single-user origins. The design of interfaces for multi-user applications offers many more challenges than the design of interfaces for single user applications, because details that are not relevant for single users have to be integrated. The interface must provide information about what others are doing to efficiently support cooperative work-it must support awareness. Awareness, which can be defined as an understanding of the overall state of a system, is a key factor for CSCW systems-it allows users to coordinate and structure their work, because they can perceive what others are working on. Without awareness, coordinated cooperative work is almost impossible. However, despite its importance, systematic support for this feature in groupware systems is an exception; ad-hoc solutions are prevailing. To support awareness, the user interface of multi-user applications must support perceptualization. Perceptualization denotes the continuous act of making others' activities perceivable at the user interface. Perceptualization is a necessary precondition to become aware of a user action. However, not all forms of perceptualization are equally well suited to stimulate this process. On one hand, enough information to make awareness possible must be conveyed, while on the other hand information overload and user disruption should be prevented. A wide variety of different aspects, including for example relevance metrics, information fidelity, and spatial and temporal distortion, have to be combined to adequately support perceptualization. The presentation discusses design and implementation of multi-user interfaces supporting awareness. Both theoretical aspects and practical implementations are considered. In particular, the following questions regarding the design of user interfaces which support awareness are covered: * Why is awareness important in multi-user environments? * How is awareness created? * How can the user interface support awareness? * Which are the key factors for the design of an awareness service? * Which are the key factors for the design of perceptualization mechanisms? * How can corresponding systems be realized and what do they look like? * What are user requirements, expectations, and experiences when using these systems? Keywords: CSCW, HCI, Groupware, User Interface Design, Awareness, Perceptualization, DIVA, POLITeam, Design Framework, Common Artefact, Groupware Evaluation Zusammenfassung Die elektronische Unterstützung kooperativen Arbeitens gewinnt zunehmend an Bedeutung. Diese Entwicklung wird sowohl durch die zunehmende Vernetzung der elektronischen Infrastruktur als auch durch den Trend zu dezentralen, verteilten Organisationen begünstigt. Obwohl im entsprechenden Forschungsgebiet (Computer-Supported Cooperative Work, CSCW) schon seit einiger Zeit an dieser Problemstellung gearbeitet wird, sind in der Praxis überzeugende Lösungen immer noch die Ausnahme. Dies ist auf eine Reihe von Ursachen zurückzuführen, die sowohl soziale und organisatorische Probleme als auch technische Unzulänglichkeiten einschließen. Häufig sind CSCW-Systeme wenig mehr als verteilte Einzelplatzanwendungen. Speziell den Benutzungsschnittstellen von CSCW-Systemen sieht man ihre Herkunft von traditionellen Einbenutzerlösungen an. Der Entwurf derartiger Benutzungsschnittstellen stellt jedoch weitaus höhere Anforderungen an den Designer, da eine Reihe von Faktoren zu berücksichtigen sind, die für einzelne Benutzer nicht von Relevanz sind. Insbesondere muß die Schnittstelle Informationen über die Tätigkeiten der Kooperationspartner im verteilten Umfeld vermitteln ­ sie muß "Awareness"1 unterstützen. Dieses Verständnis für den Gesamtzustand des Systems ist ein grundlegender Aspekt von kooperativen Prozessen, der auch bei 1 In Ermangelung einer geeigneten Übersetzung hat sich auch in der deutschsprachigen Literatur der englische Term weitgehend durchgesetzt. elektronischer Unterstützung nicht vernachlässigt werden darf. Durch die Wahrnehmung der Aktivitäten anderer wird es Benutzern ermöglicht, ihre Arbeit zu strukturieren und aufeinander abzustimmen. Ohne diese gegenseitige Wahrnehmbarkeit ist koordiniertes kooperatives Arbeiten praktisch unmöglich. Ungeachtet dieser Argumente ist eine systematische Unterstützung dieser Funktionalität in existierenden Groupware-Systemen die Ausnahme: bestenfalls werden Ad-Hoc-Lösungen geboten. Um eine angemessene Umsetzung zu gewährleisten, muß die Benutzungsschnittstelle die Aktionen anderer kontinuierlich wahrnehmbar machen ("Perceptualization"). Dies ist eine notwendige Voraussetzung, damit sich der Einzelne ein Bild über den Stand des Kooperationsprozesses machen kann. Verschiedene Formen der Wahrnehmbarmachung sind dabei unterschiedlich gut geeignet, diesen kognitiven Prozeß zu unterstützen. Einerseits muß eine ausreichende Menge an Information übermittelt werden; andererseits sollte eine Informationsüberflutung vermieden werden. Eine Reihe verschiedener Ansätze ­ u.a. Relevanzmetriken, Wiedergabetreue, räumliche und zeitliche Verzerrung ­ müssen geeignet kombiniert werden, um ein optimales Ergebnis zu erzielen. Diese Dissertation behandelt Entwurf und Implementierung entsprechender Mehrbenutzerschnittstellen. Sowohl theoretische Aspekte als auch deren praktische Umsetzung werden dabei gebührend berücksichtigt. Schlagworte: CSCW, HCI, MMK, Groupware, Benutzungsschnittstellen, Awareness, Gruppenwahrnehmung, Kooperative Transparenz, Wahrnehmbarmachung, DIVA, POLITeam, Designrahmen, Common Artefact, Groupware-Evaluierung Acknowledgements A multitude of people assisted me in writing this thesis, by contributing valuable ideas, discussing its contents, or providing emotional backup. I would like to thank the supervisors of the thesis, Prof. Dr. Gerd Szwillus and Prof. Dr. Alfred Kobsa, for their insights and ideas for improvement. The directors of the GMD institutes FIT.MMK and FIT.CSCW, Dr. Peter Wisskirchen, Prof. Dr. Alfred Kobsa, and Dr. Peter Hoschka, made this work possible by their continuous support. Dr. Thomas Berlage, Dr. Wolfgang Prinz, and Anja Syri were of invaluable help by providing a constant stream of ideas, encouragement, and incentive. Ludwin Fuchs participated in countless discussions on the issues raised by the thesis. Axel Kramer and Uta Pankoke-Babatz indicated many opportunities for improvement. The members of the DIVA and POLITeam projects not mentioned already-Andreas Bäcker, Cici Beilken, Greg Chwelos, Andreas Genau, Wolfgang Gräther, Karl-Heinz Klein, Konrad Klöckner, Sabine Kolvenbach, Dr. Gloria Mark, Dr. Peter Mambrey, Andreas Pfeiffer, Claus Riemann, Dr. Michael Spenke, Dr. Volker Wulf-all contributed to the thesis in one way or the other. Finally, I would like to thank my parents and my brother for their patience during the time I was working on the thesis. This work is dedicated to them. . Table of Contents 1 INTRODUCTION 1 1.1 AWARENESS AND PERCEPTUALIZATION 2 1.2 DIVA AND POLITEAM 3 1.3 SCOPE AND CONTENTS 4 2 INTRODUCTORY EXAMPLE: DIVA 7 2.1 DESIGN GOALS 8 2.1.1 FUNCTIONALITY 9 2.1.2 USER INTERFACE 9 2.2 ELEMENTS OF THE DIVA VIRTUAL OFFICE 11 2.3 A DIVA SESSION 12 2.4 COLLABORATION 13 2.5 COMMUNICATION 16 2.6 AWARENESS 18 2.7 IMPLEMENTATION 21 x Table of Contents 2.8 EVALUATION 23 2.9 SIMILAR APPROACHES 25 2.10 BENEFITS AND SHORTCOMINGS 26 2.11 CONCLUSIONS 27 3 MULTI-USER ENVIRONMENTS 29 3.1 MULTI-USER SYSTEMS AND CSCW 30 3.1.1 COLLABORATION 31 3.1.2 COMMUNICATION 33 3.1.3 COORDINATION 33 3.1.4 COMMON ARTEFACTS 34 3.2 MULTI-USER INTERFACES 34 3.2.1 GRAPHICAL USER INTERFACES 35 3.2.2 WEB-BASED APPROACHES 35 3.2.3 VIRTUAL REALITY 36 3.3 CONCLUSIONS 37 4 AWARENESS 39 4.1 DEFINITION 40 4.2 AWARENESS AND COOPERATIVE WORK 41 4.2.1 BENEFITS OF PROVIDING AWARENESS 42 4.2.1.1 Support for Coordination 43 4.2.1.2 Support for Informal Communication 44 4.2.1.3 Support for Conventions 45 4.2.2 PROBLEMS OF PROVIDING AWARENESS 46 4.2.2.1 Privacy Violations 47 4.2.2.2 Disruption 48 4.3 THE PROCESS OF CREATING AWARENESS 48 4.3.1 THREE STAGES IN THE PROVISION OF AWARENESS INFORMATION 48 4.3.2 ABSTRACT PROCESS MODEL 49 4.4 CLASSIFICATION OF AWARENESS INFORMATION 50 4.5 DESIGN REQUIREMENTS FOR AWARENESS SUPPORT 52 4.5.1 SOCIAL ASPECTS 53 4.5.1.1 Legal Constraints 54 4.5.1.2 Organizational Issues 54 4.5.2 TECHNICAL ASPECTS 55 4.5.2.1 Human Capabilities 55 4.6 DESIGN MODEL 55 4.6.1 THE AWARENESS INFORMATION PIPELINE 56 4.6.2 COMPONENTS OF THE AWARENESS INFORMATION PIPELINE 57 4.6.2.1 Collection 57 4.6.2.2 Transport and Distribution 58 4.6.2.3 Global Configuration 58 4.6.2.4 Privacy 58 4.6.2.5 Event History 58 4.6.2.6 Individual Interest 59 4.6.2.7 User Interface 59 4.7 CONCLUSIONS 60 Table of Contents xi 5 PERCEPTUALIZATION 61 5.1 THE PERCEPTUALIZATION PROCESS 62 5.2 DISTORTION 64 5.3 SELECTION OF AWARENESS INFORMATION 64 5.3.1 INFORMATION ORIGIN 65 5.3.2 TIME ASPECTS 65 5.3.3 ESTIMATING RELEVANCE 66 5.3.4 VISIBILITY 68 5.3.5 FIDELITY 69 5.4 PRESENTATION OF AWARENESS INFORMATION 70 5.4.1 STATIC AND DYNAMIC ASPECTS 71 5.4.2 MEDIUM 72 5.4.3 TEMPORAL DISTORTION 73 5.4.4 SPATIAL DISTORTION 73 5.4.5 PRESENTATION MODEL 75 5.4.5.1 Metaphors 76 5.4.5.2 User Representation 76 5.4.6 INTERACTION 78 5.5 DESIGN RECOMMENDATIONS 79 5.6 CONCLUSIONS 81 6 APPLICATION OF THE FRAMEWORK 83 6.1 FACE-TO-FACE COOPERATION 84 6.2 DIVA 85 6.3 LINKWORKS 86 6.4 BSCW 88 6.5 DIVE 90 6.6 CONCLUSIONS 91 7 THE POLITEAM AWARENESS SERVICE 93 7.1 THE POLITEAM SYSTEM 94 7.1.1 PROJECT GOALS 94 7.1.2 DESIGN APPROACH 95 7.1.3 THE APPLICATION DOMAIN 96 7.1.4 THE BASE SYSTEM 98 7.2 DESIGN GOALS 99 7.3 CONSTRUCTIVE APPLICATION OF THE FRAMEWORK 100 7.4 USER REQUIREMENTS 101 7.5 POLIAWAC 105 7.5.1 DESIGN FOR REAL USE 105 7.5.2 GENERAL CONCEPT 106 7.5.3 A BETTER LINKWORKS THAN LINKWORKS 107 7.5.4 THE CLIENT WINDOW 109 7.5.4.1 Metaphors 110 7.5.4.2 Enhanced Icons 110 7.5.4.3 Overview 112 7.5.4.4 User Representation 113 7.5.5 ASYNCHRONOUS PRESENTATION OF AWARENESS INFORMATION 114 xii Table of Contents 7.5.6 INTEGRATION WITH STANDARD APPLICATIONS 116 7.5.7 EVENT DISTRIBUTION AND COLLECTION: INTEREST CONTEXTS 118 7.5.8 AWARENESS 119 7.6 IMPLEMENTATION 121 7.6.1 RESTRICTIONS OF THE BASE SYSTEM 122 7.6.2 ARCHITECTURE 123 7.6.3 OBJECT MODEL 124 7.7 EVALUATION 125 7.7.1 PROBLEMS OF GROUPWARE EVALUATION 125 7.7.2 APPROACH 126 7.7.3 PROJECT MEMBERS WORKSHOP 127 7.7.4 MINISTERIAL USERS WORKSHOP 127 7.7.5 MINISTERIAL WORK PRACTICE 128 7.7.6 SYSTEM DEMONSTRATION 130 7.7.7 PROJECT FIELD TEST 131 7.7.8 DESIGNERS WORKSHOP 133 7.7.9 SUMMARY OF EVALUATION FINDINGS 134 7.8 OTHER APPROACHES 136 7.8.1 CONTEXT DEPENDENT NOTIFICATION FOR SHARED WORKSPACES 137 7.8.2 POLIWEB 137 7.8.3 VIRTUAL REALITY INTERFACE 139 7.9 CONCLUSIONS 140 8 CONCLUSIONS AND OUTLOOK 143 8.1 CONTRIBUTIONS 144 8.2 QUESTIONS ANSWERED 145 8.3 THE FUTURE OF USER INTERFACES 148 9 REFERENCES 151 1 Introduction "aware - aware·ness noun 1: archaic : watchful, wary 2 : having or showing realization, perception, or knowledge." Excerpt from WWWebster's Dictionary Rapidly growing, widely used computer networks on the one hand and the emergence of flat, decentralized, distributed organizations on the other hand dramatically increase the demand for computer support of cooperative work. Although computer-supported cooperative work (CSCW) has been a research topic for quite a while and even software industry begins to adopt corresponding concepts, convincing solutions are still rare. This is due to a variety of reasons, ranging from social and organizational problems to purely technical issues (Grudin, 1994). Frequently, groupware systems are little more than single-user applications with added connectivity. 2 Introduction In particular, the user interfaces of many CSCW systems suffer from their single-user origins. The design of interfaces for multi-user applications offers many more challenges than the design of interfaces for single user applications, because details that are not relevant for single users have to be integrated. The interface must provide information about what others are doing to efficiently support cooperative work-it must support awareness. Awareness, which can be defined as an understanding of the overall state of a system, is a key factor for CSCW systems (e.g. Root, 1988; Beaudouin-Lafon and Karsenty, 1992; Dourish and Bellotti, 1992)-it allows users to coordinate and structure their work, because they can perceive what others are working on. Without awareness, coordinated cooperative work is almost impossible. However, despite its importance, systematic support for this feature in groupware systems is an exception; ad-hoc solutions are prevailing. 1.1 Awareness and Perceptualization The user interface is crucial for the success of any computer application. This is also true for multi-user applications and their most important instantiation, CSCW systems. Without specialized interfaces, acceptance rates of these applications will remain low, usage will be difficult, gains and benefits will stay short from their potential. Adequate interfaces must integrate results of HCI research while considering the special problems of groupware applications. Interfaces of these multi-user applications differ from those of traditional single-user systems in two main aspects. Additional (groupware) functionality must be made accessible by the interface, and additional information has to be presented. In particular, the effects of other users' activities on the shared working environment must be communicated-the interface must support awareness. This is a sophisticated problem requiring the consideration of technical, psychological, social, legal, and organizational questions. Awareness is essential for any form of cooperation: it allows implicit coordination of collaborative work, shows opportunities for informal, spontaneous communication, and supports the establishment and maintenance of conventions regarding groupware usage. Awareness encompasses an understanding of past activities, present status, and future options. Understanding relies on cognitive processes which cannot be enforced by a computer. However, systems can stimulate these processes. Awareness in computer-mediated cooperation is created in multiple steps; available information about users and system activities must be communicated and must be processed by the other users. To support awareness, multi-user interfaces must support perceptualization. Perceptualization denotes the continuous act of making others' activities perceivable at the user interface. Perceptualization is a necessary precondition to become aware of a user action. However, not all forms of perceptualization are equally well suited to stimulate this process. On one hand, enough information to make awareness possible must be conveyed, while on the other hand information overload and user disruption should be prevented. A wide variety of different DIVA and POLITeam 3 aspects, including for example relevance metrics, information fidelity, and spatial and temporal distortion, have to be combined to adequately support perceptualization. 1.2 DIVA and POLITeam The thesis develops theoretical frameworks both for general awareness support and for perceptualization in particular. These theoretical considerations are backed up and validated by two implementations of the corresponding concepts: DIVA and POLITeam. While DIVA is a research prototype, the POLITeam system is actually in use in several German ministries, allowing evaluation under real-life conditions. DIVA is a prototype virtual office environment which unites in a single interface many of the key facilities needed by distributed working groups (Sohlenkamp and Chwelos, 1994). In particular, it focuses on providing integrated support for awareness of co-workers in both the synchronous and asynchronous modes of work. The standard office was used as the organizing metaphor for DIVA because it is very familiar to most users and provides the elements necessary to support group work. DIVA may be viewed as a prototype replacement for the ubiquitous graphical user interface (GUI) desktop. DIVA is used throughout the thesis as an example to illustrate theoretical concepts and considerations. Furthermore, the discussion of the background, the design, and the implementation of DIVA gives valuable insights into the problems of providing awareness at the user interface. To verify the concepts discussed in this thesis beyond the first experiences made with DIVA, a prototypical implementation and evaluation have also been realized in the context of the POLITeam project (Klöckner et al., 1995; Sohlenkamp et al., 1997b). POLITeam has resulted from the decision of the German parliament to move the capital from Bonn to Berlin. Since not all federal agencies and ministries will entirely move to Berlin, the government will be distributed between the new and the old capital. As a consequence, several research projects were launched to develop the necessary telecooperation infrastructure and tools. The main goal of POLITeam is the development and the introduction of a system supporting cooperation in large, geographically distributed organizations. A main component of the system is an event and notification service which allows users to become aware of the cooperative environment. The POLITeam design approach is based on the continuous, cyclic improvement of an existing groupware system. Selected pilot users, situated in several German ministries, have been involved in the design process from the very beginning. Since they use the system for their daily work, groupware functionality can be evaluated in the application domain. Therefore, POLITeam provides important insights regarding user requirements for awareness support, and actual experiences with corresponding functionality. 4 Introduction 1.3 Scope and Contents This thesis discusses design and implementation of multi-user interfaces supporting awareness, making contributions both to the theoretical foundations of awareness support and to the practical realization and evaluation of these concepts. The process of creating awareness is analyzed, and the relevant factors that influence the design of interfaces supporting awareness are identified. A description of the DIVA system, developed with awareness support as a primary design goal, reveals basic problems, concepts, and design solutions. Based on the experiences made with DIVA, a conceptual framework is developed to categorize and analyze the main interface concept regarding user awareness: the perceptualization. The framework proposes a set of key interface mechanisms that are essential to build multi-user applications with adequate support for awareness. To validate these concepts, they are implemented and evaluated under real-life conditions in the context of the POLITeam project which develops telecooperation tools for the distributed German government. This thesis does not analyze how information can best be presented in general, or general aspects of building CSCW systems. However, it includes existing work on these and related issues to give answers to the following questions regarding the design of user interfaces which support awareness: * Why is awareness important in multi-user environments? * How is awareness created? * How can the user interface support awareness? * Which are the key factors for the design of an awareness service? * Which are the key factors for the design of perceptualization mechanisms? * How can corresponding systems be realized and what do they look like? * What are user requirements, expectations, and experiences when using these systems? The thesis is based on a symmetrical structure (Figure 1-1). A pair of chapters is provided for the theoretical background, the practical implementation, and the related work discussion. The theoretical core is formed by Chapters 4 and 5 which describe the definition, problem domain, design requirements, and possible design solutions for awareness and perceptualization services, respectively. Chapters 3 and 6 describe work related to multi-user interfaces in general and to the theoretical framework developed before. Chapters 2 and 7 discuss concrete implementations of systems providing extensive awareness support: DIVA and POLITeam. Scope and Contents 5 Figure 1-1. Structure of the thesis While the introductory chapter on DIVA serves to highlight and discuss the problems related to supporting awareness at the user interface, the closing chapter on POLITeam is used to validate the theoretical concepts discussed before in an actual work setting. Chapters 1 and 8 provide this introduction and final conclusions. . 2 Introductory Example: DIVA "Interface designers come up against a complex interplay of individual, group and organizational factors when they enter the realm of multi-user interfaces." S. Gibbs The DIVA system is a good starting point for the discussion of awareness support in multi-user environments. For this purpose, an intuitive notion of the concepts of multi-user environments and awareness is sufficient. We will give more precise definitions later. DIVA was a research project conducted by the German National Research Center for Computer Science (GMD). Duration of the project was approximately 18 months; the project team consisted of five computer scientists. DIVA was designed as an extension of the standard graphical user interface desktop. It is based on a virtual office metaphor, allowing intuitive 8 Introductory Example: DIVA access to key features needed for computer supported cooperative work (Sohlenkamp, 1994a; Sohlenkamp and Chwelos, 1994). It offers tools for shared tasks, facilities to support communication, and interface mechanisms to provide awareness of co-workers. Its main design goal was a consistent user interface design which seamlessly integrates the different aspects of cooperative work, and allows easy transitions between different modes of work. We will discuss DIVA in some detail for several reasons: * In contrast to many groupware applications that cover only limited parts of the cooperation spectrum, DIVA integrates different functionality and time modes into a single system using a uniform user interface. Therefore, awareness information is provided for different working situations as well. * The user interface, and in particular the problem of supporting awareness of co-workers activities, was the primary design issue of DIVA from the very beginning. Therefore, the discussion on the background, the design solutions, and the implementation of DIVA gives valuable insights on the problems associated with this particular problem of groupware applications. * DIVA will be used as an example throughout the rest of this thesis to illustrate the theoretical concepts discussed in the following chapters. Abstract concepts are much easier to understand if they are explained and illustrated by concrete realizations. * DIVA provides the background for the theoretical framework and for the design and implementation of awareness functionality in its successor project, POLITeam, which will both be described in detail below. The rest of this chapter discusses the design goals of the DIVA virtual office environment, its realization, the implementation, and the pros and cons that resulted from this design. 2.1 Design Goals DIVA unites in a single interface many of the key facilities needed by distributed working groups. In particular we have focused on providing integrated support for awareness of co- workers, tools for performing shared tasks, and facilities to support communication, in both the synchronous and asynchronous modes of work. Motivation for the project were two broad design themes: * Integrate multiple groupware technologies into a single environment in order to eliminate artificial boundaries between CSCW activities which exist in current products and prototypes but are not found in the real work place. We aim not only to provide multiple facilities, but to smoothly integrate these so that transitions from one to another are almost transparent, allowing users to fluidly move between supporting technologies as their needs vary throughout the day. Design Goals 9 * Utilize the intuitions, knowledge, and skills that people have acquired through years of shared work in the real world. In particular, we include here making use of users' knowledge of current GUI desktops and their direct manipulation nature. 2.1.1 Functionality We have aimed for integration along two main, orthogonal dimensions: functionality and time mode. Along the functionality dimension, we targeted three key CSCW services: awareness of co-workers, communication with co-workers, and collaboration on the development of shared artefacts using groupware tools. The time modes are same-time work (synchronous) and different-time work (asynchronous) (Johansen, 1988). Synchronous Asynchronous Communicate in Leave messages Communication real time. for others. Simultaneous Turn-taking Collaboration work using work. groupware tools. What are others What have Awareness doing now? others done recently? Table 2-1. Classes of CSCW activities These two dimensions interact to form a conceptual framework as shown in Table 2-1. Table 2- 2 expands this framework by showing specific design goals that DIVA aimed at. We aimed for a seamless integration of individual and group work so that the same artefacts, tools, and actions should be used for both individual and group work. For example, the action required to open a document for editing should be the same in both cases. 2.1.2 User Interface Our second design theme relates to the look and feel of the interface, rather than the functionality. It guides how the design goals are realized. In order to make use of existing user skills, we wanted the elements of the interface and the operations performed on them to have real world counterparts wherever possible. However, it was clear that this design goal could not be followed rigidly, otherwise some limitations of the real world would be re-created in the virtual office, such as the limitation that physical objects can only exist in one place at a time. Instead, real world elements (objects and actions) are mimicked whenever it is sensible to do so and novel virtual world elements are defined as needed. 10 Introductory Example: DIVA Synchronous Asynchronous * Make and break verbal and visual * Leave notes for others wherever they contact with one or more other are needed. Communication people. * Establish private conversations while in a larger conference. * Quickly suspend all audio to facilitate real-world communication. * Control access to their communication media. * Manipulate (create, edit, etc.) shared * Coordinate turn-taking work. artefacts. * Determine what changes were made Collaboration * Create, join, or leave synchronous to a shared artefact by others. cooperation sessions. * Merge divergent work on shared * Select the appropriate degree of artefacts. coupling for synchronous sessions. * Obtain some idea of what co-workers * Determine when shared artefacts have are doing. been changed by others. * Ascertain a co-worker's availability * Determine how those artefacts have for contact. changed. Awareness * Control their own level of * Determine when and where others availability. have left messages for them. * Control the information about themselves which is broadcasted to others. * Know when shared documents are in use by others. * Know exactly what others are doing during a shared editing session. * Quickly join others in a shared work context (communication and collaboration activities). Others * Suspend and later resume a complete work context. * Control access to shared artefacts. * Dynamically configure work groups to adapt to changing needs. * Customize the view of the shared environment. Table 2-2. DIVA design goals2 As in the single user desktop metaphor, DIVA is a very simple abstraction which models only the essential elements of the real world in the virtual world: people, rooms, desks, and documents. In DIVA, CSCW activities become an integral part of the overall environment. Group actions are not initiated by ad hoc actions in special applications (e.g. make connection in a media space application or start a group session in a shared editor), but arise naturally out of ordinary actions in the shared virtual office (e.g. communication channels open when users enter the same virtual room and synchronous group sessions occur when users simultaneously work on the same document). Finally, in keeping with accepted principles of interface design, we tried to make all operations be direct manipulations of visible artefacts (Shneiderman, 1992). Our overall approach is a blend of analogical design and evolutionary design (Olson and Olson, 1991). 2 Each entry completes the sentence "Users should be able to ... " Elements of the DIVA Virtual Office 11 2.2 Elements of the DIVA Virtual Office The standard office was used as the organizing metaphor for DIVA because it is very familiar to most users and provides the elements necessary to support group work. We do not model the facilities of a real office in a highly realistic way, but rather abstract those elements which best support our design goals. The result, the DIVA virtual office environment, may be viewed as a prototype replacement for the ubiquitous graphical user interface (GUI) desktop, which also models its elements in an abstract fashion. Whereas the GUI desktop is a work environment for a single computer user, DIVA is an environment for group work. DIVA includes many of the features of the single user desktop, but defines a more expansive metaphor, that of the office building, in order to meet the much broader needs of groups. DIVA models four principal elements of real offices: people, rooms, desks, and documents. Additional minor elements are briefcases, stick-on notes, and a trash can. Rooms are containers for people, desks, and documents. They also control the audio/video communication status of users. Just as people located in the same real room are able to see and hear one another, so too can people in the same DIVA virtual room hear and see each other; when a DIVA user enters a virtual room already occupied by one or more users, audio and video links are established between the newcomer and the other occupants. Rooms also serve to indicate availability and communication willingness: they can be in different states (open, closed, or locked), providing different levels of access and visibility of their inhabitants. Rooms themselves are contained in the DIVA virtual office environment. A glance at the rooms contained in the virtual office shows who is inside each open room. Rooms can be used as private offices, public meeting places, or special purpose spaces. Users may customize their own view of the virtual office by placing the rooms as they like. People represent the users of the DIVA system and are implemented as small snapshots with a name beneath. They can be moved by their owner to change their virtual location and thereby determine what they are doing and whom they are in audio/visual contact with. Documents represent the objects people work on in the virtual office. They are very similar to documents in the single user GUI desktop, but have some additional properties, such as change status and current activity status, which are needed to adequately support group work. They differ from real documents in that they may be in two or more places at once, for the sake of convenience. Multiple copies in different places are simply access points for a single shared document. Desks serve a variety of purposes: they are the arena for work within a room, they control the coupling mode of a cooperation, and they can be used to preserve working context. 12 Introductory Example: DIVA 2.3 A DIVA Session People move through the virtual office, from room to room, by dragging their icon. They may glance into rooms which are not open and they enter a room in order to do work or establish contact with others in the room. Once in a room, the desks and documents in it become visible. By moving shared documents and themselves to a desk in the room, users may work together in either tightly coupled or loosely coupled mode. People working at the same desk are engaged in a focused collaboration, using a tightly coupled editing mode, while people working on the same document but at different desks are less focused and use a loosely coupled mode. b d c a Figure 2-1. An exemplary DIVA session An exemplary DIVA session is illustrated in Figure 2-1. The virtual office, shown from the point of view of user Markus, is displayed in two main windows. The first window (a) contains the virtual office itself and the second (b) shows the virtual room that the user is currently in. The virtual office window displays the DIVA rooms and the people present in the virtual office. It indicates the location of the users and displays their movements from room to room. As illustrated in the example, a glance at the virtual office window provides a broad level of awareness of co-worker activities: Markus, Cici, and Mike are together in Markus' office; Claus and Andreas have met in the project room; Greg and Thomas are each alone, but Collaboration 13 available for contact; the people in the "Conference" room would like some privacy; and user Jim does not want to be disturbed, as indicated by the lock on his DIVA office. The other DIVA window, labeled "Room Markus" in the example, is the virtual room window. It reveals the contents of the room that the user is currently in. In addition to the people who are in the room, the desks and documents in the room are shown. Awareness information is also conveyed by this window: Markus, Cici, and Mike are all working on the shared drawing "figure" (c); Mike is also editing a spreadsheet named "Costs"; the documents "Song" and "text" have changed since Markus looked at them; and there are some notes for Markus in the room. Working at the same desk, such as Markus and Cici are doing, indicates focused work and results in a tightly coupled synchronous editing session. Although Mike is also editing the same drawing, he is at another desk so his work is independent and he is loosely coupled with the others. In this manner work on the shared artefacts in the room focuses around the desks in the room, as it usually does in real offices. Finally, the small windows shown in the example (d) are live video images of the people in the room. 2.4 Collaboration The actual tools for working in DIVA are multi-user applications built with the GINA application framework (Berlage and Genau, 1993a; Spenke, 1993). A wide variety of prototype multi-user applications have been implemented in GINA in order to demonstrate its generic nature. These applications include a text editor, spreadsheet, structured drawing tool, music editor, and a chess program. Facilities to support synchronous group editing which are provided by every multi-user GINA application include group awareness in the form of visual representation of others' actions, unlimited multi-user undo/redo, multiple coupling modes, embedded annotations, optimistic concurrency control, and conflict resolution. The physical office is used as the model for the DIVA implementation of shared work: work happens at desks. To edit a document found in a virtual room or to launch an application program, the DIVA user drags the corresponding icon to a desk. This causes the application to start and open the document. This is just like double-clicking on an icon in the typical single user desktop and, for the sake of backward compatibility, double-click has the same effect in DIVA. Documents are closed by double-clicking the their icon on the desk or by closing them from within the application. Desks do more than simply start applications, however; they are used as a natural means to control the coupling of synchronous groupware sessions and to save work contexts. To work together in tightly coupled mode, two DIVA users simply work on the document at the same desk. To work together in loosely coupled mode they work on the same document but at different desks-they each drag the document to a different desk. They can easily switch coupling modes by moving from desk to desk. 14 Introductory Example: DIVA In the example Markus and Cici are tightly coupled because they are editing the drawing at the same desk, but Mike is loosely coupled because he is working on it another desk. The number and coupling status of people synchronously editing a document is additionally indicated within the DIVA groupware applications, on the status line found near the top of the application window. This shows all users, their coupling status (tightly coupled groups are shown in brackets), and their signature colors. Users can also change the coupling mode from within the application by dragging their names on this status line. This action causes their icon to move in the DIVA room window, so that the DIVA room always represents the actual user activity. Desks can also be used to preserve a working context simply by leaving documents on them. When users drag their icons away from a desk with documents on it, the application windows for the documents close, as if the documents themselves had been closed. The users may then return to work on those documents by later dragging their icon back to the desk, at which point all of the documents on the desk will be reopened. Closely related to the desks, every user has a personal briefcase. It is displayed beneath the own video image and therefore always visible (At the upper left corner in the example). The briefcase moves from room to room with the user and is not visible to others, though they see their own. The briefcase may be used to move documents from room to room, as a place to privately edit documents while in a room with others, and as a consistent personal working context which moves from room to room. Figure 2-2 shows the different forms of collaboration supported by DIVA desks and their corresponding visualization. In the first example (a), a single user is working on a single document. In the second example (b), two users are working tightly coupled on a single document. In the third example (c), two users are working loosely coupled on a single document. Note that the document is actually displayed twice. However, this is consistent with the DIVA approach of allowing multiple access points for documents; see below for details. In the fourth example (d), two users edit a document in tightly coupled mode, while a third one working on the same document is only loosely coupled to them. The third user is also working on another document on its own. The fifth example (e) shows the context-preserving function of desks: two documents are left on a desk, ready for future work. For all these examples, the two desks do not necessarily have to be located in the same virtual room. Finally, the sixth example (f) shows individual work on a document contained in the briefcase. Note that unlike the other five examples, this information is not visible to other participants since they are only shown their own briefcase. Collaboration 15 Figure 2-2. Desks in DIVA showing different forms of collaboration Unlike most other groupware systems, no special actions are necessary to start or join a synchronous groupware session. Furthermore, the same action-dragging a document to a desk-is used for asynchronous work. The model employed to distinguish work in the two modes is based on physical shared artefacts. If two or more users wish to use the same artefact at the same time, then they must share it. Otherwise users manipulate the artefact on their own, asynchronously. Therefore, in DIVA whenever a user opens a document which is already in use by another person, a synchronous session is started. The transition from asynchronous to synchronous is automatic, requiring no other user action. Other people also wanting to work on the document automatically join the synchronous session. Asynchronous collaboration is further supported in DIVA with catch-up and merge facilities. A key need of people editing documents asynchronously is the ability to know what changes others have made in their absence. DIVA provides a uniform mechanism for catch-up across all multi-user GINA applications, based on the replay of saved history. Changes made by others are replayed with animation so that they may be viewed exactly as if the user had been there watching them being made, except that the replay may be sped up. This mechanism is provided by the multi-user GINA framework itself, so that all applications developed using GINA inherit the catch-up facility, including our basic spreadsheet, text editor, and graphics editor. In fact, the exact same mechanism which reveals the actions of others during synchronous editing is used to show those actions during asynchronous catch-up. Figure 2-3. Document icons in DIVA DIVA users know from the visual cues on the document icon if a document has changed before they open it (Figure 2-3 summarizes how the document icons display additional awareness information). On opening a changed document, users are given the opportunity to catch-up to the changes before proceeding with their editing. Furthermore, the same replay mechanism can be used at any later time to review changes made by others or by oneself. Merging of parallel, divergent work is assisted by the GINA merge facility which semi-automatically appends one stream of changes after another. 16 Introductory Example: DIVA DIVA goes beyond the office metaphor by permitting multiple symbolic copies of documents. This means that a document may be in two or more places at once and may be open in more than one place. The automatic creation of groupware sessions among users simultaneously editing a document occurs even if those users are in different virtual rooms accessing different symbolic copies of the document. In this case the users have no accompanying audio/video conference and they are necessarily loosely coupled because they are at different desks. This implementation of symbolic copies allows users to keep documents in as many places as is convenient. For example, if A and B are writing a paper together, they may each have a copy in their office and they may also have a copy in their project room, where they often work together. This automatic creation of synchronous editing sessions during simultaneous access not only smoothly integrates the two time modes of work but it also minimizes the occurrence of parallel, divergent work. In summary, the DIVA virtual desk, as the focus of work, supports: synchronous, asynchronous, and individual work; easy switching of coupling modes; and dynamic extension and contraction of synchronous sessions. 2.5 Communication Real-time person to person communication is supported in DIVA through audio/video conferencing. Control of conferences is based on a very simple model taken from the real world-people in the same room can see and hear one another while others cannot. So, in order to converse with another person in the DIVA virtual office users simply drag their icon into the DIVA room where the target person is working, using the virtual office window (Figure 2-4). Small video windows are then automatically opened and placed at the top of the screen, one window for each occupant of the room. Audio channels are opened at the same time and people already in the room are informed of the arrival of a newcomer by an audio cue. The audio and video channels to a particular user are broken when that user leaves the room. In this manner DIVA maintains separate audio/video conferences for each room in the virtual office. With good reason, DIVA allows users to have only one virtual representation. This prevents the technical difficulty of users participating in several different video conferences at the same time. Moreover, this also is consistent with the room metaphor: real people also occupy one room at a time only. Communication 17 Figure 2-4. Joining a conference in DIVA Amongst groups of people holding a general discussion it is often desirable to be able to have private conversations, either to make aside comments or for more extended conversation. Users at the same desk may initiate a private conversation by dragging their icon so that it overlaps the icon of another user. This action is intended to be an intuitive surrogate for the real world action, in which people talking privately draw close together. It is performed inside a room, in the virtual room window, and is only visible to occupants of that room. During a private conversation in DIVA the sound of the conversation is transmitted to others in the room at a very low volume, while the sounds from the others are received normally. This mimics what happens in real groups. A possible problem with the virtual office metaphor used in DIVA is that it could be difficult to find a virtual co-worker, if they are in an unusual place or in a closed room. To eliminate the need for exhaustive searches, DIVA provides each user with their own office, called a home room, and provides a find function. To locate a person, users drag their icons into that person's home office and onto the find icon (the icon shown in Thomas' room in the example). This will move them in the virtual office space to the threshold of the room where the target person is located. Home offices themselves should always be easy to find as each user organizes the room layout as they like. Users who do not want to be found can disable this feature by locking their home rooms. DIVA support for asynchronous communication is based on another object from the real world office: the stick-on note. Notes can be attached to the objects in the virtual office: people, rooms, desks, and documents. To do so, a user drags the note tool onto the target object (Second icon on the tool bar of the room window in the example.). This causes the note editor to pop up which both permits the creation of new notes to attach to the object or the review of the existing notes on the object. After the new note is created, a note icon appears on the object, with one exception. Just as we do not actually stick notes on people in the real world, in DIVA notes directed at people do not appear on their icons but instead appear on their briefcases, where they are both private and accessible to the recipient. Notes can be read by clicking on them or by using the note tool. The note editor and viewer support text, audio, and video notes. Every groupware system needs to support some form of access control. DIVA implements rudimentary object access control in the form of access lists for rooms and documents. The room access list determines which users are allowed to enter the room when it is locked. Conceptually, users on the access list have a key to the room. Visual feedback is provided in the form of small key icons on the rooms which the user has access to (e.g. The "Coffee room" in the example.). Only users on the access list for a room are able to change the room access 18 Introductory Example: DIVA status. Typically, the only person on the access list of a private office is the owner of that room. The document access list controls document appearance and accessibility. Users on the access list of a document will see the document icon in its normal form in the virtual room window and have full access to it. Users not on the list see a mute gray equivalent of the document icon and have no access to the document (Document "1993" in the example). Room and document access lists are managed similarly. Anyone on an access list may add others to the list while initially the list only contains the person who created the corresponding room or document. This simple mechanism is sufficient to allow the development of social protocols governing access control. 2.6 Awareness Having described the basic concepts of DIVA to support collaboration and communication in the previous sections, we will now discuss how these are supported by underlying awareness mechanisms. Awareness is necessary to coordinate collaborative work, to allow effective usage of shared resources, and to support spontaneous communication. DIVA provides a variety of mechanisms for these purposes at different levels of detail and in both synchronous (What are others doing?) and asynchronous (What did others do?) modes. For the synchronous mode, the virtual office window provides a broad overview of co-workers' activities throughout the virtual office, while the virtual room window provides more detailed information about a particular room. In the virtual office, the display of the icons of the users inside a room within the room's results in the visual impression that the users are in the room. It is possible to observe the location of other users, who is talking to whom, as well as determine the availability of others for contact. Much of the information may be perceived even when not being actively attended to. If most of the rooms are kept open, a short glance at the display provides a good overview of the activities in the office. The animated movement of users and documents in the virtual office provides an additional visual indication of the overall activity. Additionally, rooms containing documents which the user has access to and which are currently in use are flagged with a red bar at the top of the room (The "Project" room in the example.). In a virtual room, users can see who is working with whom and on which documents. Besides the animation showing user movement into a room, an acoustic signal informs the user if someone entered the virtual room. The coupling mode between users is also indicated clearly, providing an important clue as to how focused a work session is and thus how available the participants are for interruption. The document icons visually indicate the status of the document: documents not opened by the user but which others are editing, even in a different room, are flagged as in-use and displayed with a red background (e.g. "Costs" in the example). Additionally, when sharing a room, the audio and video channels provide further direct cues as to the activities of co-workers. DIVA also provides artificial audio cues for certain actions, such as another user entering the room or joining a groupware session. Awareness 19 Finally, while editing a shared document using a multi-user GINA application, the activities of others can be seen, especially in tightly coupled mode. The status line of these applications shows the names of all the connected users (in unique, signature colors), together with their coupling mode. To varying degree, depending on the coupling mode, the operations performed by each user are animated for others in that user's color. The problem of mapping a limited amount of distinguishable colors to a potentially large amount of collaborators is alleviated by the fact that the actual set of cooperation partners tends to be small (we will discuss this problem in more detail in Section 7.5.4.4). Furthermore, temporary rubber band lines drawn from the video window of the user issuing a command to his cursor position provide an unobtrusive visual link between a command and its originator. In the example Cici is currently drawing a rectangle which Markus can see grow in real-time as Cici drags his mouse. The outline is displayed in Cici's signature color and the cursor point is connected to his image by the temporary rubber band line. Work Context Coupling Status Remote User Cursor Link Remote Feedback Pending Messages Change Indicator Conferences In-Use Indicator Communication Availability Figure 2-5. Awareness cues in the DIVA interface All of these cues-in the virtual office, in a virtual room, and within a shared application- provide information as to what co-workers are currently doing in the current working context. Figure 2-5 summarizes the different cues in the example. In the asynchronous working mode, DIVA also provides information as to what others have done. In the virtual office window, rooms containing documents which the user has access to and that have been changed by others are flagged with a green bar at the top of the room (The "Conference" room in the example.). This flag is also set if notes have been left for the user on artefacts on the room. In the virtual room window, documents which have changed by others since the user last edited them are flagged as changed and displayed with a green background (Documents "Song" and "text" in the example.). Notes left by others on objects are shown as yellow squares on the corner of the objects. Notes are on the "Coffee room", the briefcase, and 20 Introductory Example: DIVA the "Song" and "Drawing" documents in the example. Visual cues are thus provided both at the office level and at the room level indicating what others have done that is of interest to the user. Figure 2-6. Document history in DIVA DIVA also maintains a detailed interaction history for every document. Figure 2-6 shows the graphical browser provided for navigation in the history. User actions are depicted as series of rectangles in the color associated with the user. Diverging document versions resulting from uncoupled work result in different branches of the history tree, which may be merged semi- automatically on explicit user request. Users may click on individual history entries to examine the particular command, and to restore the document version resulting from the execution of that command. Alternatively, they may press the "play" button to get an animated replay of the complete command history leading to the current version. In summary, DIVA supports awareness of co-workers activities, both synchronous and asynchronous, at a variety of levels (Table 2-3). Synchronous Asynchronous * Shows virtual location, grouping, and * Signals recent activities of others, such as documents availability of co-workers. (office view) changed by others and rooms containing these. * Shows who is editing what, including the * Signals messages left by others: a) within a shared degree of focus of connected groups. (room artefact, b) on an office object, and c) for the user. view) * Shows changes made to shared artefacts by others * Permits users to control this information. through activity replay. * Provides visual and aural awareness, and immediate access (open audio/video connection). * Provides explicit audio cues to signal consequential activities, such as entering a room. * Shows current activity, such as documents currently in-use and rooms containing these. * Provides detailed feedback of others' activities during synchronous editing sessions. Table 2-3. Awareness support in DIVA We believe that the DIVA awareness information, excluding the audio and video channels, is benign and unthreatening and thus is unlikely to raise concerns over privacy. Nonetheless it is Implementation 21 possible for users to limit this information by closing or locking the room they are currently in. This does not overly restrict their ability to work as they can always bring copies of documents into the room with them. Users can also use the access control mechanisms to limit access to rooms and documents. The cost of privacy is loss of awareness and accessibility. Working in a DIVA room, on the other hand, necessarily entails a significant loss of privacy as video and audio channels are automatically established. However, even these can be moderated, through the private conversation mechanism and a privacy facility which temporarily stops all DIVA audio activity and outgoing video. 2.7 Implementation In the same way as the tools used in DIVA, the virtual office application itself is based on the application framework GINA (Spenke and Beilken, 1990). GINA was originally developed as an object-oriented application framework for single-user applications. It is written in Common Lisp and CLOS (Common Lisp Object System)3 and is based on X11 and OSF/Motif. It is a generic interactive application that is executable and has a complete standard graphical user interface, but lacks any application specific behavior. New applications are created by defining subclasses of GINA classes and adding or redefining methods. GINA also supports user- defined graphical objects and a linear undo/redo mechanism via command objects. By extending the history mechanism of GINA to support a non-linear history and a selective undo/redo feature, it turned out that GINA can be used as a generic application framework for multi-user applications as well (Spenke, 1993). It provides support for different forms of coupling between applications: from strict WYSIWIS (What You See Is What I See) over common document state to complete decoupling. Furthermore, the system allows smooth transitions from one coupling mode to another. The mechanism is based on command objects which are used to encapsulate all user actions (Berlage and Genau, 1993a). In the coupled cases, command objects are broadcast by the creating application to all connected applications and are replicated locally. Virtual time stamps are used to detect conflicts, which are resolved by reordering the conflicting commands. Which types of commands are transmitted depends on the coupling mode. If only the document state is shared, it suffices to transmit state changing commands. Otherwise, commands such as the scrolling of windows or the selection of objects have to be transmitted as well. Of course, there is no need to transmit any commands in the decoupled case. The problem here is the merging of different document states if a closer coupling mode is selected later. This is realized by regarding the different states as different branches of the history tree and by appending one branch at the end of the other by means of the selective redo feature. A graphical display of the history tree help users to navigate through different versions of a document. These mechanisms are fully exploited by the groupware applications used in the virtual office. In particular, this allows for the sophisticated awareness cues discussed before. DIVA itself, 3 A slightly less sophisticated version implemented in C++ exists as well (Bäcker et al., 1993). 22 Introductory Example: DIVA however, deviates from this replicated approach. Since undoing user actions in the virtual world is senseless in most cases, it is implemented as a single central server application keeping a database of users, rooms, and documents. A video and audio link is used to provide a natural way of communication between users. For the transmission of audio signals, most workstations offer hardware support (microphones and speakers) to record and replay sound samples of at least telephone line quality. This is enough to support verbal communication. For the video link, special hardware is needed. For DIVA, this consists of a video camera mounted on top of the computer monitor in combination with a special video board that allows the display of a digitized video signal in a window and hardware JPEG compression of images. This configuration allows the usual face-to-face conversations in a video conference. The audio connection is necessary to permit at least a minimum of communication. The same is not true for the video link: the video information is not absolutely essential in a shared session. Therefore, machines without the special video hardware can also be used to participate in the virtual office by transmitting a predefined still picture. Video and audio connections are automatically established between all users sharing the same room. Video images can be manipulated and adjusted individually as well as switched off. The image others receive from an individual user is controlled entirely by this user: besides switching off his camera, he can as well disable the transmission of video data temporarily-in this case, a predefined still image is displayed. Because the own image is reflected for each user, it is possible to constantly supervise what picture is being sent to others. In an analog way, users control their audio connections: they also can be turned off individually. Technically, the transmission of video and audio data is accomplished by the use of two separate processes: a video and an audio server. Thus, DIVA relies on three server processes to do its work: the X window system server to handle user input and display graphics, the audio server to perform audio input and output and the video server to display the digitized video images (Sohlenkamp, 1994b; Sohlenkamp and Berlage, 1996). Both video and audio data are transmitted via standard network connections (e.g. TCP/IP over Ethernet). The AudioFile system (Levergood et al., 1993) is used as the audio server: it is device- independent, network transparent and allows multiple applications to share the same audio hardware. The basic mechanisms for audio input and output resemble those of the X window system for graphical input and output. While the device independence is only a potential benefit for DIVA, network transparency and the fact that multiple clients can share the same hardware is crucial: it allows the mixing of different sound input channels, for example the voices of different communication partners all speaking together. Furthermore, sound effects can easily be mixed into an audio conference to provide additional clues to ongoing activities. Audio conferences are realized by special AudioFile clients that collect audio input on every machine that runs DIVA, and replay it on connected machines. Evaluation 23 :RUNVWDWLRQ#$ :RUNVWDWLRQ#% &RQIHUHQFH $) $) &RQIHUHQFH 96 96 ; ; ',9$ 1HWZRUN Figure 2-7. DIVA: schematic overview For the video conference, a video server-based on X and the special extensions for the video hardware-is used. It is a X client with the basic capabilities to display an image in a given window and to copy the contents of an arbitrary window to another window-possibly located on a screen of a different machine. For the copying process, the JPEG compression built into the video hardware is used to maximize the transmitted frame rate. Once started, the video server performs its duties automatically by permanently displaying the video image from a connected camera in a given window. Requests from the client program to start or terminate copying of the contents of that window-and thus to start or terminate a video conference with another user-are given by special X events that encode the necessary parameters. Figure 2-7 shows the different parts comprising the DIVA system for two connected machines. X, AF and VS denote the X server, the AudioFile server and the video server, respectively. Arrows show connections between components, dashed arrows symbolize potential connections to additional machines. 2.8 Evaluation A systematic user evaluation of the DIVA system never took place. This is due to a variety of reasons, particularly its prototypical nature, and the missing support for `real' applications. Therefore, the question whether the interface concepts and the general design of the virtual office are really adequate to support cooperative work remains open. However, there is some limited user experience with the system. 24 Introductory Example: DIVA A demonstration of an early version of the system at an open house showed the feasibility of the approach. The demonstration consisted of a short scenario were the visitor was asked to write a short musical score in cooperation with two remote `experts'. Figure 2-8. Original DIVA version A simple cooperative music editor was written for this purpose which allowed the editing and manipulation of musical scores (Figure 2-8). Users were given instructions on how to integrate themselves into the virtual office. This was accomplished by taking a snapshot of oneself with the video camera which resulted in automatic creation of a corresponding user icon. Afterwards, the first expert explained the task and the basic functionality of the virtual office remotely via the video connection. These instructions allowed the visitor to locate the second expert in the virtual office, to move to his room, to start a cooperative application, and to jointly edit the musical score. The task included loosely coupled sections, with the visitor and the expert composing a second and a third voice in parallel, and a tightly coupled section were the results were reviewed. Manipulating the musical score consisted mainly in copying and rearranging predefined parts of the document. It turned out that almost all visitors had no problem understanding the basic concepts of the virtual office and in accomplishing the task. They were able to perform more complex operations like copying or moving a range of musical scores after receiving remote instructions. These operations, while designed as easy-to-use drag-and-drop operations, were still sufficiently complicated to need explanation before users could employ them. Awareness support-the video conference in conjunction with its Similar Approaches 25 telepointing capabilities and the command redisplay features-allowed users to learn these operations even without the physical presence of an instructor. Additional help from the booth personnel was only required for people who had difficulties working with a mouse, i.e. which had no previous experience with a graphical user interface at all. While the results of this experiment are only of limited general applicability, it still suggests the validity of the basic design premises. It appears that users do find the interface simple and intuitive, and that awareness cues in fact enhance the cooperation process. 2.9 Similar Approaches Several other systems bear similarities to aspects of DIVA. The Xerox Rooms system (Henderson and Card, 1986) uses virtual rooms to organize the work of individual users. CoDesk (Tollmar et al., 1994; Tollmar and Sundblad, 1995) is based on the same design approach as DIVA: it also extends the standard desktop metaphor to include groupware functionality and to allow awareness of others' activities. The system's user interface closely resembles the usual graphical desktop. It stresses a functional and graphical duality between new (multi-user) and old (single-user) objects: users correspond to documents (representing formal and informal knowledge); groups correspond to folders (structuring of users or documents); rooms correspond to tools or applications (working with users or documents). The MILAN system (Hämmäinen and Conden, 1991) is also based on a room metaphor, displaying the room contents in a pseudo-3D fashion. The authors compare the spatial metaphor of MILAN with a form-based approach of a similar system, concluding that the spatial approach is more suited for informal, unstructured cooperation and open-natured tasks. Madsen (1992) describes a hypertext-based implementation of the virtual office metaphor. Rooms are realized as configurable hypertext nodes. Communication is supported by text-based message systems. Users cooperate by working on shared hypertext information. Regarding awareness, the system supports graphical doors to indicate user availability for communication, and a "new links" node that contains information that is new to a user. The VOODOO system (Li and Mantei, 1992), a prototype virtual open office environment, provides persistent audio and video connections such as exist in DIVA virtual rooms. The DIVE system (Fahlén et al., 1993 , cf. Section 6.5) models aspects of the real office in a virtual world, but is based on a virtual reality approach. ClearBoard focuses on the integration of communication and cooperation over a shared drawing tool (Ishii et al., 1992). Here the integration is deep, resulting in a seamless integration of the inter-personal (communication) space and the shared work space. DIVA, in contrast focuses on a broad integration of multiple CSCW aspects. The cooperative Sepia system (Haake and Wilson, 1992; Haake and Haake, 1993) provides some supports for both communication (audio) and cooperation, but is limited to a single application. Several media spaces target synchronous communication, and some include facilities to support informal communication (Mantei et al., 1991; Cool et al., 1992; Gaver et al., 1992). 26 Introductory Example: DIVA Polyscope provides background awareness in a work group by periodically distributing low resolution frame-grabbed snapshots of participants' offices to other people's workstations (Borning and Travers, 1991). Portholes extends Polyscope to distributed work groups, using the internet to transfer the images (Dourish and Bly, 1992). These systems convey more information about activities occurring in the physical office space (e.g. Co-worker is on the phone, in a meeting, or alone.) than does DIVA, but provide fewer clues as to activities occurring amongst distributed collaborating groups (e.g. who is working with whom and on what). Vrooms (Borning and Travers, 1991) is similar to DIVA in that it uses the metaphor of the virtual room and what it means for two or more people to be in the same room-they can see and hear one another. The difference between DIVA and Vrooms is that in Vrooms when two users occupy the same virtual room they share a slow-scan video only connection while in DIVA the connection is by default full-motion video with audio. In Vrooms, a full bandwidth connection is made by moving the two room occupants close together, while in DIVA this action results in the establishment of a private conversation. 2.10 Benefits and Shortcomings In summary, DIVA does successfully manifest our two main design themes. First, it smoothly integrates communication, collaboration, and awareness in both the synchronous and asynchronous modes. Second, it does so almost entirely within the unifying model of the virtual office so that the elements and operations of the interface are easily understood. Nevertheless, although DIVA succeeded in this respect, it failed in some other ways. Its main shortcomings are related to three factors: 1. Due to its centralized, monolithic architecture, the implementation of DIVA would not scale well to a large number of users. Broader usage would require additional mechanisms to manage user directory services, to select users for collaboration, or to remove them from the environment, which were not part of the design and implementation of DIVA. However, given the premise that users select a restricted set of cooperation partners from a large number of potential collaborators, the main interface concepts are still fully applicable. 2. DIVA does not support standards. It was implemented as a research prototype, based on unusual hardware and software, without any support for standard applications. It is unsuited to accomplish "real" work because the applications provided with DIVA are just demonstrators showing potential functionality, but lacking any sophisticated features. 3. The design of DIVA ignores some aspects that are essential in an actual working environment. This includes privacy issues and the adherence to legal and organizational regulations. Conclusions 27 4. The interface design, and in particular the design of the awareness functionality, though a primary design goal, incorporates some unverified design solutions that were not grounded on sound empirical or theoretical considerations. In the following chapters, we will discuss the theoretical background of many issues raised during the discussion of the DIVA system. This includes the concepts of multi-user environments, awareness, and perceptualization. Furthermore, in Chapter 7 we discuss design and implementation of a system that addresses the problems listed above, while adopting and adapting many of the basic design choices of DIVA. 2.11 Conclusions We have discussed design and implementation of the DIVA virtual office environment as an example for awareness and perceptualization services. Its two basic design goals, the integration of different groupware functionality on the one hand, and the orientation on the standard graphical user interface desktop on the other hand, makes it an excellent candidate for this purpose. It demonstrates both how awareness features are interrelated with standard groupware functionality supporting collaboration, communication, and coordination of users, and how standard graphical interfaces can be augmented to meet the awareness needs of cooperating groups. DIVA extends the metaphor of an individual desktop to that of an office building shared by multiple users. Rooms are the central organizing element of the virtual office. People in the same room share a video conference and can jointly work on documents. Desks are provided as a metaphor to support shared editing with different levels of intensity. The more coupled a session is, the more awareness information is provided. Awareness is supported by a variety of mechanisms. Users' status and availability is shown both globally in the virtual office and locally in shared applications. Documents provide status information, detailed command feedback, and a browseable history. An-albeit simplistic-evaluation of the system showed the feasibility of the approach: the employed metaphors are easily understandable, collaboration on shared tasks is smooth and easy, and a set of simple awareness mechanisms increases cooperation efficiency without hindering normal work. Throughout the rest of the thesis, we will refer to the basic concepts, design solutions, and awareness mechanisms discussed in this introductory chapter to exemplify theoretical considerations. . 3 Multi-User Environments "The focus of CSCW will shift to user interface issues to minimize the disruption and additional work required of any user of the application." J. Grudin The age of multi-user environments is dawning. The ongoing trends to connect previously isolated workstations by ever-increasing networks makes the notion of a "personal" computer obsolete. It is substituted by a technical group infrastructure that fits the needs of distributed organizations. Besides supporting individual work, multi-user environments support the interaction of users. Their programming demands are more sophisticated than those of single- user applications (Patterson, 1991). In particular, they require a new quality of user interfaces: multi-user interfaces. In this chapter, we discuss multi-user environments and their interfaces. In the first section, we describe multi-user systems, focusing on their most important and 30 Multi-User Environments prominent incarnation: groupware applications. In the following section, we discuss corresponding user interfaces. We elaborate on the fundamental differences between single- user and multi-user interfaces. Furthermore, we discuss how different interface approaches- WIMP, WWW, VR-are applicable for multi-user environments. 3.1 Multi-User Systems and CSCW A multi-user environment is any computer system where some form of interaction between users is intended. This definition includes systems not primarily intended to support groups or group work. However, some systems designed to support multiple users are excluded, in particular time sharing or database systems that conceptually try to hide the existence of other users working on the same machine (Rodden et al., 1992). From a user interface point of view, these systems are equivalent to single user systems. Examples for multi-user environments are games (e.g., MUDs4), operating systems (e.g., UNIX), or the Internet. Consider the UNIX operating system: while aimed at supporting single users, it still offers functionality to access the status of others (e.g., with the ps, who, or finger commands) or to communicate with them (e.g., with the mail or talk commands). As another example, the World Wide Web (WWW) on the Internet can be viewed as an information source for single users. Still, there are lots of users involved in creating the information, and there are limited possibilities of interaction between them. Interaction between users can take much more complex forms. In particular, it includes cooperation of users. Systems supporting cooperative work are therefore an important subgroup of multi-user environments. We will focus on these systems because they are most demanding from a user interface design point of view. Work situations where several persons work simultaneously on the same object represented within the computer are of special interest because it is crucial to visualize changes to and activities on this shared object. Results can be transferred directly to any system with fewer requirements. We define groupware as being any software supporting the cooperation of several users through the computer medium. We use the terms groupware, groupware system, groupware application, CSCW system or CSCW application synonymously. Note that these definitions are by no means generally agreed upon in CSCW literature. There is a multitude of different definitions with subtle differences. In particular, many authors differentiate between CSCW on the one hand and groupware on the other, with the former referring to research focused on understanding the nature of cooperative work and its implications for information systems, and the latter focusing on the concrete design of systems (Schmidt and Bannon, 1992). 4 Multi-User Dungeons. Multi-User Systems and CSCW 31 0XOWL08VHU#(QYLURQPHQWV XQLFDWLRQ &ROODER &RPPRQ D U P $UWHIDFWV R L W P R Q & &RRUGLQDWLRQ Figure 3-1. Multi-user environments and groupware functionality5 Groupware can be classified in many ways, and in fact many classification schemes have been devised. We will base our discussion on functional aspects. Groupware applications can support three areas of group interaction: communication, coordination, and collaboration (Ellis et al., 1991). This distinction mirrors the description of the functional aspects of DIVA, and it will be repeated in the discussion on awareness functionality in Chapter 4. The different areas overlap each other (Figure 3-1), and there is almost no system supporting only one of the three aspects. DIVA, for example, addresses all of them. However, the classification is useful to isolate associated functionality. Note that we will not give an exhaustive description of existing systems, but rather highlight some basic concepts and ideas. For a more comprehensive overview of CSCW applications and approaches, see for example (Schwabe and Krcmar, 1996) or the unofficial yellow pages of CSCW compiled in (Malm, 1994). 3.1.1 Collaboration Collaboration relies on people sharing information (Ellis, Gibbs et al., 1991). The sharing of resources between several users therefore is a central functionality of groupware systems. Sharing may be synchronous, with several users accessing the same resource at the same time, or asynchronous, with different users accessing the same resource at different times. Asynchronous sharing is mainly a question of access: any system allowing users to access documents from different physical locations (i.e., from different workstations) supports asynchronous sharing. Almost any modern operating system offers corresponding network functionality. However, asynchronous sharing may be supported further. For example, changes of users may be flagged, or users may annotate parts of a document for future users. Synchronous sharing is more demanding: it can be transparent to applications (collaboration- transparent applications), or it can be supported explicitly by collaboration-aware applications. In the former case, what is actually shared are windows of single-user applications. All users see the same copy of the document, and they work on the same copy which is kept locally on the computer of one participant. Consistency is guaranteed by multiplexing input and output events of the windowing system to all participating sites (Lauwers and Lantz, 1990). This 5 Adapted from (Lotus Development Corporation, 1995). 32 Multi-User Environments approach either requires a modification of the underlying windowing system, or a special application acting as an event distribution interface between the window system and the actual applications to be shared. These applications themselves remain unchanged. By using this approach, any single-user application can be used for cooperation. However, there are some drawbacks since single-user applications do not provide any support for multiple users working on the same document. The windowing system may provide some generic multi-user support- e.g., showing the position of others' editing by colored mouse pointers-but there is no way to provide any multi-user support based on application semantics. For cooperation-aware applications, synchronous sharing may also be implemented at the application level. In this case, the application is specifically designed to support cooperation, and sharing operations are based on document semantics. For example, locking can be performed based on the objects defined by the application: in a text editor, the whole paragraph where a user is editing can be marked as read-only for others. Popular examples of this type of application are shared drawing tools (e.g., GroupDesign: Beaudouin-Lafon, 1990; CaveDraw: Lu and Mantei, 1991) and shared text editors (e.g., Grove: Ellis, Gibbs et al., 1991; ShrEdit: Dourish and Bellotti, 1992). Shared drawing tools usually provide a drawing area where all participants can draw simultaneously. This is especially useful for brainstorming sessions or design meetings where participants can jointly sketch ideas on the shared drawing area. Shared text editors can be used for the same purpose. Olson et al. (1992) report that the mere usage of a shared text editor to structure the design process increases the quality of the results of a design meeting. A second distinction between systems supporting sharing is whether they are centralized or replicated. A centralized system keeps all the data in a central location. This makes synchronization easy, but has negative effects on response time and availability. A replicated system keeps local copies of the data that are synchronized through communication protocols. Such a system has a high availability and a short (local) response time, but is difficult to synchronize. Most systems today are hybrid, i.e. they use both mechanisms for different components. Another factor concerns the differences between the locations. Sometimes it is desirable to have exactly the same appearance at all sites (WYSIWIS-What You See Is What I See), sometimes a looser coupling is desired. Coupling can be specified on a per-object basis (Dewan, 1991) or on a per-operation basis (Berlage and Spenke, 1992). Furthermore, there may be intrinsic differences between systems, such as different screen sizes and resolutions. In this case, it makes a difference whether actions and events are communicated in a concrete way (device-specific coding) or in an abstract way (e.g. as commands in terms of abstract objects). Conflicts arise when two actors start incompatible operations at the same time. Solutions for this problem range from pessimistic techniques such as turn-taking, locking and voting to optimistic techniques (Ellis and Gibbs, 1989; Beaudouin-Lafon and Karsenty, 1992). Optimistic techniques take into account that users are also able to resolve conflicts through direct conversation. Multi-User Systems and CSCW 33 A variety of specialized toolkits (e.g., Liza: Gibbs, 1989; GroupKit: Roseman and Greenberg, 1992; GINA: Berlage and Genau, 1993b) have been developed that facilitate the implementation of groupware applications by providing these basic sharing mechanisms. 3.1.2 Communication Another functional aspect of groupware systems is the support of communication between two or more human participants. Communication includes text messages, spoken interactions, or non-verbal exchanges like gestures in a video conference. Communication may take place asynchronously (different participants communicate at different times) or synchronously (participants communicate at the same time). The most prominent example of a system supporting asynchronous communication is email. While it was not initially conceived as a groupware application, it is nevertheless used most successfully as such. The simple text-based approach used by standard email systems-its simplicity arguably being the main reason for its success-has seen several extensions. Audio mail and video mail have been integrated to accommodate additional media. Filtering of email has been a major topic to categorize incoming messages and facilitate further processing. Other well-known examples for systems supporting asynchronous communication are electronic bulletin boards or news systems. The most important example for synchronous communication tools are video conferencing systems6. Corresponding products are marketed as natural extensions of the telephone. However, video conferencing still is deficient in many ways: direct eye contact is difficult because of the parallaxes between the camera and a users' view direction; resolution and transmission speed is low on standard network connections; video images do not convey enough visual context. In essence, video conferences fail to convey a sense of presence of the communication partners. 3.1.3 Coordination Coordination is an important aspect of any cooperative activity. It entails the combination and sequencing of otherwise independent work toward the accomplishment of a larger goal (Schäl and Zeller, 1990). Systems can support coordination in different ways. A formal approach to support coordination is based on modeling informal communication, e.g. by using speech act theory (e.g. The Coordinator: Winograd, 1988). Another approach is to present the activities of the participants in the context of the overall goal. This is one of the main aspects of awareness support that will be discussed in detail in the next chapter. Alternatively, systems may track task status, deadlines, resource usage, working results, or other critical process parameters. Workflow management systems (e.g. DOMINO: Kreifelts et al., 1991) focus on the routing of documents through an organization, based on a model of the procedures involved in working on the documents. They permit the coordination of work processes by modeling task, roles, work resources, and task sequencing. Working material is 6 Note that the telephone, while being the most widely used synchronous communication technique besides actual face-to-face conversations, is excluded by our definition of groupware. At least conceptually, there is no computer mediating the communication. 34 Multi-User Environments automatically routed from one working station to the next until task completion. Project management systems (Kreifelts et al., 1993) structure the cooperation process by allowing the explicit assignment of users and other resources to well-defined tasks. In a similar way, shared calendars manage appointments of a whole group of users. 3.1.4 Common Artefacts The concept of a common artefact (Robinson, 1993a; Robinson, 1993b; Berlage and Sohlenkamp, 1995) is an intriguing metaphor for the design of CSCW systems. Common artefacts combine aspects of the three functional areas discussed before. Robinson (Robinson, 1993a) list the following features as being essential for a common artefact. * Predictability and functionality: The functions to accomplish the intended tasks have to provided. * Peripheral awareness: The status of the cooperation has to be perceivable at a glance. * Implicit communication: Users should be able to communicate through the state of the artefact. * Double level language: Besides implicit communication, explicit communication has to be supported as well. * Overview: The artefact should afford an enduring record and overview on the work environment. Robinson gives a simple example for a non-computerized common artefact: the keyrack in a hotel reception. DIVA is an example for a computer-mediated common artefact. Common artefacts are the most sophisticated multi-user environments. They are also most interesting from an user interface point of view because they integrate all the different aspects discussed before. For the remainder of the thesis, we will use the term "common artefact" to refer to any shared computer system allowing the integration of awareness and notification support. 3.2 Multi-User Interfaces Grudin (1990a) identifies five stages in the evolution of user interface7 research and development. During the first stage (1950s), the computer hardware itself was the user interface; the computer was manipulated by engineers dealing with registers and memory locations. The second stage (1960s-1970s) saw the introduction of programming environments to increase programmer efficiency. The third stage (1970s-1990s) had the terminal as user interface. For the first time, the "end user" was a target of user interface development, and 7 As Grudin (1990b) points out, the term "user interface" is misleading. Computer user interfaces actually are concerned with interfaces to the computer applications rather than to the user-the term "computer interface" would be more appropriate. This misnomer becomes even more apparent with "multi-user interfaces" which are not interfaces to multiple users but rather an interface for a single user to interact with a computer application allowing the interaction of multiple users. Nevertheless, we will use the generally accepted terms "(single-) user interface" and "multi-user interface" throughout the rest of the thesis. Multi-User Interfaces 35 human factors began to be accepted as a design criterion. The fourth stage (1980s-present) improves on support for the end-user by broadening the research base user interface design can draw upon. Finally, the fifth stage (1990s-present)-the one that is most relevant for our discussion-is concerned with multi-user interfaces: interfaces supporting groups of end-users cooperating through the computer medium. Each of these steps builds on the research results of the previous ones. This does not imply that research on a previous stage has to be completed to work on the next one. However, it implies that the research base and corresponding results are less mature at higher stages. The last two stages are currently focus of HCI and CSCW research efforts. Malone (1985) refers to the final transition from stage four to stage five as the shift from user interfaces to organizational interfaces. "Software supporting an entire group or organization will encounter individuals with a wide range of roles, skills, backgrounds, and preferences. Social, motivational, economic, and political factors arise that do not affect single-user applications" (Grudin, p. 264). Users' perception of these different factors changes with their working situation (Bowers and Rodden, 1993). Multi-user interfaces, being interfaces supporting the interaction of users through the computer, have different affordances compared to single-user interfaces. They are more difficult to design and implement (Dewan and Choudhary, 1991). A central difference is the necessity to present the dynamics of the environment. The system state can change anytime as a result of others' activities, and the user interface has to reflect these changes accordingly. This is what awareness support at the user interface is concerned with. In the following sections, we will briefly discuss three popular interface approaches regarding their suitability as multi-user interface. The standard WIMP (windows, icons, menus, pointer) approach is the current de- facto standard for graphical user interfaces. Interfaces based on the World Wide Web (WWW) and its protocols are interesting because the web already provides the basic connectivity needed for multi-user interfaces. Finally, virtual reality (VR) approaches offer great potential for innovative presentation and interaction techniques. 3.2.1 Graphical User Interfaces Most current multi-user interfaces are based on the WIMP approach, providing overlapping windows, mouse input, and menus for operation selection. This is not a consequence of this approach being the best for this purpose, but rather it results from the fact that this type of interface is most prominent for single-user applications as well. In the terms of the five-stage model discussed above, well-known techniques from the fourth stage are transferred to the fifth stage. In fact, these standard interfaces offer ample room for improvement to accommodate the additional features needed by multi-user interfaces. DIVA is an example for this approach. The POLITeam system that will be discussed in Chapter 7 is another example, which also provides evidence that radically different interface approaches are highly difficult to introduce in actual working environments. 3.2.2 Web-based approaches Bentley et al. (1997b) state that the World Wide Web, "with a lightweight and extensible client-server architecture, client implementations for all popular computing platforms, and an 36 Multi-User Environments existing user base numbered in millions", forms an excellent basis for the realization of CSCW systems. In particular, the fact that web protocols and applications are increasingly used by organizations to manage internal distribution of information encourages their extension to groupware functionality. In contrast to many CSCW systems which do not go beyond the research prototype stage, web browsers are actually used in real-world domains. An increasing number of CSCW applications based on Web technology is therefore being developed, both by augmenting the web with cooperation functionality (e.g., Bentley et al., 1997a; cf. Section 6.4 for a more detailed description) or by providing web interfaces to existing groupware applications (e.g., Freund, 1996). Unfortunately, the World Wide Web is not the general solution of all groupware problems. In particular, its limited options for user interface design are a major drawback. Web applications are based on HTML, which was intended to be a page layout language. Therefore, its possibilities to design interactive user interfaces are very limited. Advanced interface techniques like direct manipulation, detailed feedback, and drag and drop operations, are all impossible to implement in this language. Moreover, the WWW protocol is based on a request system: clients send a request to a WWW server and receive information (usually a Web page) in response. There is no standard way for servers to automatically update the information that is displayed by clients. However, awareness support requires exactly this, in the form of presentation updates as the result of others' actions. On the other hand, these limitations also have a positive aspect: web pages present a cross-platform, uniform, simple, and intuitive interface defined by the browser. Moreover, most of these limitations may be overcome by using universal programming languages designed for Web usage like Java. As Bentley et al. (1997b) note, "the topic of awareness is only one of several issues which might be included in a research agenda for CSCW with respect to augmenting the basic Web architecture, protocols and technologies". 3.2.3 Virtual Reality Virtual reality increasingly is seen as an interesting option for CSCW systems to support real- life oriented cooperation (e.g., Takemura and Kishino, 1992; Fahlén, Brown et al., 1993; Greenhalgh and Benford, 1995; cf. also Section 6.5). In fact, corresponding user interfaces have some advantages in comparison to conventional interfaces as described before. These advantages are related to two major aspects: intuitive usage and enhanced visualization possibilities. 1. Intuitive usage: Virtual reality approaches try to mimic reality. Therefore, they may provide users with exactly the same objects they know from real-life cooperation. Virtual reality objects may correspond to their real-life counterparts, both in appearance and in their interaction capabilities. In contrast, the standard desktop interface is only loosely based on well-known objects. 2. The third dimension: Since virtual reality systems are based on three dimensional models of the world, there is more (virtual) space to display additional information. Moreover, this information may be presented in a fashion that is familiar to the user. Virtual reality Conclusions 37 environments stress a spatial layout of objects and are therefore ideally suited for spatial metaphors. Unfortunately, these benefits are accompanied by some drawbacks. Realistically modeled objects may restrict users by limiting the computer system to the possibilities of the real objects. They include many shortcomings and drawbacks that make both the design as well as the use of the virtual world unnecessarily complex. For example, a realistically modeled telephone would still need a number to be dialed to make a call. There are clearly much better ways to realize this on a computer network. However, while systems do not have to abide to these limitations, extending object functionality in unnatural ways breaks the metaphor and may make users' understanding of the system more difficult. Also, the improved visualization possibilities of virtual reality environments do not come for free. Navigation in the virtual world may be non-trivial (Mullet et al., 1995), and overview on the virtual world may be poor due to the well-known limitations of screen space. Two- dimensional visualization of data is preferable to three-dimensional renderings in many cases (Levy et al., 1996). The integration of existing standard applications into the virtual world is difficult because they are usually based on two-dimensional approaches. In fact, many of the tasks supported by these standard applications (for example, text processing or drawing) are inherently two-dimensional. This does by no means imply, however, that the virtual reality approach is unsuited for CSCW systems in general or awareness support in particular. In fact, three dimensional displays can provide a compact visualization of information (cf. Section 5.4.4), e.g. an object history. However, it suggests that the "reality" part from the virtual reality should not be taken too far: in general, it is not useful to model all features of the real world indiscriminately. 3.3 Conclusions Computer environments supporting the interaction of multiple users become increasingly important. These environments encompass a wide variety of different systems. Groupware or CSCW systems supporting the cooperation of users are of particular interest: they are most demanding from a design and implementational point of view. Computer-supported cooperation is covered by three functional areas: communication, collaboration, and coordination. Available systems address different aspects of this spectrum, varying according to their intended purpose. To integrate all different aspects into a single system, the metaphor of a common artefact is a useful approach. Common artefacts thereby are the most sophisticated form of a multi-user environment. Multi-user environments require a new quality of interfaces: multi-user interfaces. This is a natural evolution step in the development of user interface design, going beyond and running in parallel to the improvement of interfaces for single users. Support for user awareness-the presentation of the shared activity to coordinate one's own actions-is the major difference between single and multi-user interfaces. Several current interface approaches are of special interest for multi-user extensions: the standard graphical interface because of its ubiqutousity, 38 Multi-User Environments WWW based solution due to the increasing popularity of internet-based solutions, and virtual reality approaches because of their suggestive metaphors. While all these approaches are generally suited to support awareness, they nevertheless have specific drawbacks and problems associated with them. In the following chapters, we will discuss theoretical considerations for the design of awareness services of common artefacts, and we will analyze how systems employing the aforementioned interface strategies actually realize awareness functionality. 4 Awareness "Knowledge of group and individual activity, and coordination are central to successful cooperation. These factors are clearly critical concerns in the design of computer systems [...]." P. Dourish & V. Bellotti Awareness has been a topic in CSCW literature for quite a while (e.g., Lauwers and Lantz, 1990; Beaudouin-Lafon and Karsenty, 1992; Pankoke-Babatz, 1994). Awareness support in multi-user applications becomes an increasingly important and accepted topic both in CSCW and HCI research, as evidenced by an increasing number of related publications and dedicated tracks or workshops in major scientific conferences (e.g., CSCW'96 or CHI'97). Although a systematic survey of the associated phenomena, functionality, and requirements is still not 40 Awareness available, it seems to be evident that awareness of co-workers' activities is a central aspect of successful cooperation and therefore for the successful introduction and use of groupware systems (Dourish and Bellotti, 1992). In this chapter we analyze the role of awareness in supporting cooperation. We describe the different aspects of collaboration that are affected by awareness. We define the term "awareness", discuss the process of creating awareness in computer-mediated cooperation, and classify the information awareness should be provided about. Furthermore, we analyze the requirements that have to be considered to design systems supporting awareness. This discussion leads to the proposal of a design approach-the awareness pipeline model-that may be used both as a implementation guideline and as an analysis framework for existing systems. 4.1 Definition Before we discuss our definition of "awareness"8, we will investigate how the term has been used and defined in CSCW literature. Interestingly enough, many authors discussing awareness issues rely on an intuitive notion of the term, without giving any precise definition. Where definitions are given, they usually are subtly different from those of other authors. In the following, we will examine some of these definitions to analyze what they have in common and where they differ. Probably the best-known definition for awareness in CSCW literature is given by Dourish and Bellotti in their seminal paper on awareness and coordination in shared workspaces (1992, p. 107). They define awareness as being "an understanding of the activities of others which provides a context for your own activity". Other definitions from literature include9: "[Awareness means] to be aware of the presence of