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 other users and their access to the shared objects" (Tollmar and Sundblad, 1995, p. 181); "By this [awareness] we mean that each user should be aware of what the others are doing, to facilitate coordination [...]" (Beaudouin-Lafon and Karsenty, 1992, p. 171); "The use of implicitly existing information channels with the goal to capture past and present activities of co-operation partners in the current working context" (Rauschenbach, 1996); "Low-effort, informal communication which allows people to stay aware of the activities of their colleagues and coworkers and provides the `context' for work- related activities" (Smith, 1996, p. 59). Greenberg and Gutwin (1996) even distinguish between four forms of awareness-informal awareness, group-structural awareness, social awareness and workspace awareness-which in combination form group awareness. For our discussion, mainly their definitions of informal awareness ("Basic knowledge of who is around in general") and workspace awareness ("Up-to- 8 The term "awareness" literally implies a broader meaning than actually intended by most related publications in CSCW literature. What is usually meant is "group awareness" or "cooperation awareness", being knowledge about the state of a cooperative effort of a group of people. While this form of awareness is the primary focus of this thesis as well, we provide a broader definition of the term. This definition, in conjunction with the generally accepted usage of the term in literature, justifies the usage of the word "awareness" without qualifying attributes throughout the thesis. 9 All these definitions are taken from papers that either have the word "awareness" in their title, or have a dedicated section on it. Therefore, author presumably considered their definitions seriously. Awareness and Cooperative Work 41 the minute knowledge a person requires about another group member's interaction with a shared workspace if they are to collaborate effectively") are relevant. The two other forms include knowledge on users' roles and emotional state. There are three common elements to all these definitions: they all imply that awareness is a state of mind of a user ("understanding", "knowledge", "be aware of"), that it involves the activities of others, and that it provides a backdrop ("context") for own activities. However, we feel that these definition are lacking in one respect: they fail to explicitly include the computer, or even more importantly, the user himself, as an object to provide awareness about. Users may be heavily interested in re-inspecting their own activities to re-establish the context of their activities. Moreover, the state of a computer-mediated cooperation may be influenced not only by the human participants, but also by the machine itself, which may be seen as another actor to provide awareness about. Therefore, we give a broader definition of awareness. For our discussion, awareness means an understanding of the state of a system, including past activities, present status, and future options. This definition obviously depends on the explanation of the term "system". In the case of computer-supported cooperation, the system is the common artefact the cooperation partners work on, which includes in particular a representation of the users themselves (Berlage and Sohlenkamp, 1995). The term therefore is not restricted to a pure technical meaning, but rather includes social and organizational aspects as well. Note that it is not important who initiated a state change. Activities of all users are included as well as computer induced changes. However, this definition still incorporates the three basic elements discussed before. It is worth noting the difference between awareness on one side and awareness mechanisms on the other side. Awareness is a state of mind of a user, while awareness mechanisms are techniques employed by a system to achieve this state of mind. Some authors do not differentiate between these two concepts. As an example, Matsuura et al. (1996) define awareness as "a mechanism to provide information about others' activities and to support interactions among them". By using this type of definition, it becomes possible to build systems that effectively provide awareness (i.e., a mechanism). However, if awareness is defined as being a mental state of the user, it becomes impossible to design systems that actually provide it-in the same way that it is impossible to build systems that guarantee satisfaction or happiness. Systems can only support the corresponding processes. What can be provided, however, is the necessary information to stimulate these processes. 4.2 Awareness and Cooperative Work A central problem of many groupware systems is that they fail to consider actual work practices. Designers simply implement the functionality they deem useful for cooperation without integrating the seemingly minor and irrelevant aspects of everyday work. Awareness of co-workers' is one of these aspects. Awareness related functionality is often addressed in an ad- hoc manner or neglected at all (Ackerman and Starr, 1995). This is one aspect that may have contributed to the less than optimal acceptance rate of early groupware systems in actual 42 Awareness working environments (on the failure of groupware introduction, see e.g. Grudin, 1988; Orlikowski, 1992). In this section, we will discuss why awareness is so important for cooperative work. We will highlight how it contributes to all three functional areas of CSCW systems described before. Since awareness support is not completely unproblematic, we will also elaborate on the different problems it is invariably associated with. 4.2.1 Benefits of Providing Awareness The growing interest in awareness related topics results from the fact that awareness support is increasingly being identified as a crucial aspect of successful cooperation. It forms an essential and integral part of cooperative work. Gaver (1991) discusses a simple model of shared work. The model identifies three forms of increasingly focused cooperation: serendipitous communication, division of labor, and focused collaboration. "Awareness is necessary for all collaborative work, but the degree to which its focus is shared varies" (p. 295). Less focused collaboration also requires less awareness, but some awareness support is required in all cases. Moreover, awareness is also necessary to facilitate transitions between the different modes of work. Perceiving, recognizing, and understanding the activities of others is a basic requirement for human interaction and communication in general. Adequate human behavior requires awareness of the overall situation of the involved persons and work objects. For this reason, when dealing with complex machinery, instruments try to convey a picture of the situation- thereby providing awareness. Control rooms or head-up-displays in aircraft cockpits are good examples: most of the instruments are not absolutely necessary to solve the basic task at hand-run a machine or fly an aircraft-but provide awareness about the general situation. Early groupware applications tended to be technical solutions supporting the explicit mechanisms of human cooperation: explicit communication with others, explicit coordination of activities, or explicit collaboration by allowing shared access to work objects. These applications provided a technological base for cooperation by giving users the basic tools needed to accomplish shared work. Development was mainly driven by technology and not so much by considering how people actually work together10. However, this approach widely ignores the implicit aspects of human cooperation: implicit communication based on non-verbal cues (Heath, 1991; Robinson, 1993a), implicit coordination by a common sensorial reference to a shared object (cf. Rogers, 1993; Whittaker and Schwarz, 1995), and the implicit establishment of conventions for groupware usage (Mark et al., 1997). The difference between explicit and implicit communication (Watzlawick et al., 1967) is crucial: explicit communication consists of all forms of structured communication acts, either verbal speech (face to face or mediated by technical means), written documents, or message passing. However, a significant amount of communication is performed implicitly, mediated by a variety of different channels. Examples are unstructured speech acts such as utterances, gestures, or suggestive fragments. Implicit communication often is mediated 10 This parallels the development of computer applications (and arguably of any complex system) in general: issues of user-friendliness only gain interest after the technological background is well established. Awareness and Cooperative Work 43 indirectly by the work artefacts. In this case, the state of the objects of work provides implicit means for communication between the group members. These interrelated, implicit cues allow the flexibility that is inherent and essential to most cooperation processes. Basically, it is these cues that form awareness information. As far as computer applications are concerned, awareness is an important concept not only in the CSCW domain. In single-user environments it is important to understand the reason of system state changes as well. Since these changes are in most cases induced by the users themselves, awareness is present inherently and created without having the need of explicit mechanisms. Note, however, that this depends on the responsiveness of the user interface: operations that do not complete immediately should provide users' with some feedback about the system activities, e.g. an hourglass cursor or a progress bar. This way, the system provides awareness information about its own internal state. For computer-supported cooperation, there is a major difference: activities of the cooperation partners have direct consequences for the system state as well, without users being able to deduce the reasons for these changes. Furthermore, computer support for awareness of others' activities may be important for systems seemingly targeted at single users as well. Heath et al. (1993) argue that even for single-user application the traditional notion of a user task has to be reconsidered since it fails to integrate the interdependencies and interrelations between different workers. For example, Parikh and Lohse (1995) describe the low acceptance of a system supporting the futures market at the Chicago stock exchange. While the system offered functionality to trade futures electronically, it overlooked the social dynamics of the real stock exchange. In the trading pit, people are aware of the actions of other traders, which greatly influences their own decisions. This form of feedback on the entire market was not modeled in the system, because the associated information was deemed to be unnecessary for seemingly individual financial transactions. The authors argue that systems should support both "quantitative information" (the trade options) and "qualitative information" (psychological factors, i.e. awareness information). Consequently, they propose an improved design for the trading system that incorporates some simple awareness mechanisms, like a graphical overview of the trading pit with icons representing the traders and their bids. 4.2.1.1 Support for Coordination "Experts do not work in isolation, they must coordinate with each other" (Gerson and Star, 1986, p. 265). Heath and Luff (1992; 1993) describe the working situation in a (essentially non- computerized) London underground control room. While the operators seem to be engaged in apparently individual tasks, there is nevertheless a strong interdependency between them. Their work not only depends on the overall situation of the shared artefact-consisting of the different trains, their positions, movements, and status-but also on the current actions of their colleagues. Operators constantly monitor and overhear each others' activities and adapt their actions accordingly without the necessity to engage in explicit communication. Implicit communication is furthermore supported by a shared display of the train positions. In fact, even the gaze direction of a colleague onto this display provides important cues for the actual situation. 44 Awareness Hughes et al. (1992) report similar results in a study on UK air traffic control. The main instrument used by the operators is a rack of flight strips. Each flight strip is a paper card containing flight information which is updated anytime flight data changes. An individual strip therefore serves as a shared, commonly accessible history of the particular flight. The whole rack affords a shared overview on the current situation. Operators implicitly coordinate their work through the use of these mechanisms. Again, awareness of co-workers' is essential, even for seemingly individual tasks. Similar studies showing essentially the same results were conducted for other domains as well: examples include stock exchange (Heath, Jirotka et al., 1993; Parikh and Lohse, 1995), civil engineering (Rogers, 1993), and health care (Heath and Luff, 1996). In all these cases, cooperative work is implicitly coordinated by observing activities of others or the status of shared artefacts. Providing awareness information is therefore necessary to support this form of coordination in computer-supported cooperation. Aytes (1996) compares the results of design groups using a commonly visible, physical whiteboard with those using a shared drawing tool. He states that those groups working with the whiteboard produced better results, and attributes this fact to the reduced awareness of others' in the groups using the shared drawing editor. Increased awareness, resulting from the visibility of any action on the whiteboard, effectively changes the form of cooperation of the group. For the whiteboard groups, "visual awareness of others' contributions leads to higher levels of interaction", while participants in the computer-supported teams tended to have prolonged phases of parallel, individual work. Moreover, the persistent record of awareness information also serves as "group memory" or, on a larger scale, as "organizational memory". It allows access not only to documents and data (which are commonly stored for later retrieval), but also to the context in which they were created (Conklin, 1992). Group memory has been identified as a highly important aspect of cooperative editing (Posner and Baecker, 1992). Organizational memory, being "organizational knowledge with persistence" (Ackerman, 1994, p. 243), is increasingly becoming an important topic because it is "thoroughly lacking in contemporary organizations" (Conklin, 1992, p. 133), while being necessary to re-establish the reasoning leading to decisions, solutions, or artefacts such as documents. 4.2.1.2 Support for Informal Communication Another well researched area of cooperation is the joint production of documents in academia.11 A key concept in this domain has been found to be physical proximity, because this allows informal communication (Kraut et al., 1988). Informal communication means the opportunistic, spontaneous, and unplanned interaction between people. Whittaker et al. (1994) report that informal communication makes up 25% to 70% of face-to-face communication. Informal communication builds and relies on a common context. This shared background is again based on mutual awareness of co-located workers. Without technical support, awareness can only be achieved by proximity. 11 Probably this form of cooperation is a popular field of research because the research subjects are readily available. Awareness and Cooperative Work 45 Examples how systems can support informal communication by showing others' availability status for communication are the DIVA blinds, or the similar doors metaphor (e.g., Madsen, 1992; Harrison et al., 1994). In the latter case, a graphical door with different states (open, ajar, closed) indicates a user's status. Tang and Rua (1994) use the term "teleproximity" for their Montage system which combines a video conferencing tool with a facility to glance at colleagues before establishing a connection, akin to walking past an open office door in real hallways. This establishes a lightweight mechanism to provide awareness information about users' availability for communication. Another lightweight approach to support informal communication is the use of existing, low-bandwidth network protocols to visualize users' status (Peepholes: Greenberg, 1996). The Cruiser System (Root, 1988) supported an interesting feature to allow informal communication without needing corresponding awareness information. The system modeled a virtual hallway. When users moved through the hallway, the system randomly established communication channels (a video conference) to other users, trying to mimic the unplanned interactions taking place in real hallways. However, Fish et al. (1992) report that this feature was disliked by users. Automatic connections were considered to be intrusive because the subtle social cues preceding real hallways meetings were missing. 4.2.1.3 Support for Conventions Conventions are arrangements established in a group to allow effective interaction. "Often unconsciously, our actions are guided by social conventions and by our awareness of the personalities and priorities of people around us" (Grudin, 1994). Conventions are not established formally, but rather evolve over time and are used implicitly. They change over time, and their violation is only mildly sanctioned by the group. Beck and Bellotti (1993) describe the use of conventions in teams writing joint reports. In particular, they note that the flexibility of conventions is a key issue. Their violation is not necessarily contra-productive, but rather allows flexible adaptation to changing circumstances. They call this phenomenon "informed opportunism". Tuckman and Jensen (1977; discussed in Cole and Nast-Cole, 1992) identify five invariable stages of group evolution: forming, storming, norming, performing, and adjourning. During the forming phase, the group is established, and the storming phase settles problems of group authority, power, and control. The norming phase is needed to establish common norms and conventions that are essential to perform the actual tasks the group was established for (performing phase). Finally, the adjourning phase is concerned with the dissolving of the group. Therefore, the establishment of conventions is an essential part of any group development process. To support the norming phase, groupware systems have to allow the establishing of conventions. Conventions are also essential for the use of CSCW systems to allow efficient usage of shared system resources. Mark and Prinz (1997) and Mark et al. (1997) report on the role of conventions that had to be established to allow efficient work with a groupware tool in a German ministry (see Chapter 7 for a more detailed description of the application domain and the employed groupware system). Different users had different perspectives on the shared work objects that had to be reconciled by creating new or re-establishing real-world conventions to 46 Awareness be used with the system. It took some time for users to discover their need for conventions, though. Users had to get acquainted to the basic functionality of the system before. Even after this initial phase, workshops with the participation of system designers were necessary to help users in establishing appropriate conventions. At least partly, this was due to the limited awareness support provided by the system. Awareness allows the establishment and maintenance of conventions for the usage of the system through usage of the system, by allowing observation of how others work with it. There are several ways systems can technically support the establishment and the maintenance of conventions. Conventions can be enforced-violations are prevented by the system-or reinforced by showing recurring patterns of cooperation. These two basic approaches can be used exclusively or in combination. The former approach requires the system to have explicit knowledge of the conventions that are used, while the latter does not. However, providing systems with information about conventions results in some major problems: first, explicit formulation of a convention is against its implicit nature, transforming it into a rule (though its violation may still be possible). Second, a convention may involve any objects, conditions, or operations available in the system. Formulating a convention requires a formal language with the expressability of a standard programming language, including constructs like conditional branches and control loops. This either requires that the designers implement the convention, or that the users learn and use programming techniques. Third, conventions change over time- their inherent flexibility is based on their implicit definition. Explicitly formulating conventions hurts this flexibility: it requires conventions to be programmed, to be updated, and to be maintained. This way, the coded conventions can easily deviate from those actually used. Alternatively, a system can provide awareness information, which is required to maintain conventions via social protocols and norms. The system does not perform any checks for convention violations in this case. These checks have to be applied by the users themselves. This doubles exactly how conventions are established and maintained in real-world cooperation: they are not established explicitly, but evolve implicitly and are applied using the knowledge of how others perform their work. The enforcement of conventions is left subject to individual responsibility aided by additional awareness about the activities of the group as a whole. 4.2.2 Problems of Providing Awareness We have discussed the beneficial and necessary effects of awareness for cooperative work in the previous sections. These benefits, however, do not come for free. Even if disregarding the technical overhead that is necessary to support awareness in computer-supported cooperation, there are two basic problems that are invariably associated with the provision of awareness information: privacy violations and user disruption. On the one hand, users' privacy may be violated by making details of their activities available that should have been kept privately. Every piece of information about a user that is made available to others is a potential privacy violation. On the other hand, users may be disrupted from their work because unneeded information about others distracts them. To a large extent, information about the activities of others is irrelevant in the current working context and only hinders work. There is a fundamental design tradeoff between awareness support on the one side and privacy and Awareness and Cooperative Work 47 disruption aspects on the other side (Hudson and Smith, 1996). Thereby, awareness support results in problems both for the originator of information (privacy) as well as for the receiver (disruption). It should be noted that even if disregarding these problems, an increased awareness of others' activities is not always beneficial. For example, Weisband (1994) discusses how computer- supported group decisions are influenced by the mutual awareness of the participants. Increased awareness benefits those that would also be opinion leaders in face-to-face discussions, while anonymity helps less dominant participants. Depending on the situation, this may or may not be an desired effect. This shows again that awareness support is a complex problem that has to be considered with great care. 4.2.2.1 Privacy Violations The aspect of privacy is very important in an environment designed to present one's actions to other people. Obviously, people do not necessarily want all details about what they are doing to be revealed. The difficulty is to find a balance between privacy of users on the one hand, and the necessity to provide information that is useful for an ongoing cooperation on the other hand. Thus providing awareness information introduces a certain ambivalence. Clement (1994, p. 87) remarks: "It is an intrinsic feature of all CSCW applications that detailed information about personal behavior is made available to others. [...] The fine grained information about individuals' activities useful for cooperation and optimizing collective performance, also may become a threatening resource in the hands of others." While awareness is a positive, necessary feature to make coordinated work possible, exactly the same mechanisms can also be used to monitor and control others. However, we believe that this problem cannot be solved by simply adapting the functionality of a system. Instead, systems should rely on the establishing of social protocols and conventions analogous to those used in real-world collaborations to allow flexible cooperation and to prevent misuse. We agree with Dourish (1993), who concluded from a study of several media space systems that privacy issues cannot be settled by technical means alone, because they necessarily involve social interactions that are beyond technical control. The real world imposes both physical constraints which cannot be violated and social constraints which people are free to violate under the risk of social sanctions. Systems should do the same: physical constraints are defined by the possible operations of the system, while social constraints should not be encoded but rather be subject to social protocols as in real life. The problem of privacy violations is such an issue that should mainly be addressed by social control. While the use of social protocols may solve technical problems this way, technical means may still be employed to facilitate and enhance their usage (O'Day et al., 1996). Interestingly enough, the establishment of adequate social protocols and conventions is itself dependent on a sufficient level of awareness of others' activities (cf. Section 4.2.1.3). While increased awareness usually implies decreased privacy, it should be noted that the absence of awareness information may lead to privacy violations as well. For example, this 48 Awareness may be the case if a user establishes a video connection without being able to check the callee's status before (Bellotti and Sellen, 1993). 4.2.2.2 Disruption Information overload is a general problem in an electronic environment with an ever increasing information density. As Furnas and Bederson (1995, p. 234) put it, "big information worlds cause big problems for interfaces. There is too much to see." If too much information is presented, it becomes difficult for users to concentrate on the essential aspects of their work. The addition of awareness information to the presentation of a document may increase dramatically the total amount of available information. Moreover, the presentation of awareness information introduces an additional problem: not only is there too much information, but it may also appear unexpectedly, seemingly without any explicit user request. Unexpected changes in the information presentation may easily distract users from their work. This may be a desired effect, for example if a user is to be alerted to a specific fact. However, a basic reason for awareness support is to allow smooth cooperation. Any disruption has exactly the opposite effect: the cooperation is interrupted and delayed. This disruptive effect is especially noticeable if there is no clear connection between a presentation change and the work object (Gutwin et al., 1996c). 4.3 The Process of Creating Awareness Creating awareness in computer-mediated cooperation is a complex process. It consists of several indispensable steps that have to be considered. Becoming aware of something involves cognitive processes on the user's side which have to be adequately supported by corresponding systems. In contrast to current practices of co-located cooperative work, computer-mediated cooperation has to rely on a single communication medium: the computer. Although the computer as a medium has several advantages (huge storage capacity, retrieval capability, easy geographical distribution of data), the interface between human and computer represents a major bottleneck of current technology. Many interface problems are not specific to CSCW, but one is crucial for cooperative work: the presentation of other people's activities to provide awareness about their work. 4.3.1 Three Stages in the Provision of Awareness Information Technically, the provision of awareness information consists of three separated, indispensable steps (Figure 4-1). First, information has to be collected. Second, the collected information has to be distributed. Third, the distributed information has to be presented. The whole process of providing awareness information fails altogether if any of these steps is omitted. The Process of Creating Awareness 49 User Collection ... of Information Presentation User User Collection of Information Presentation Distribution Presentation Collection of Information User Collection Presentation of Information ... Figure 4-1. Three steps of providing awareness information It must be noted that all three steps may also work as an information filter in the sense that they modify the information available in the previous step. Not all information that is available has to be collected, distributed, or presented. This filtering may be due to technical reasons, e.g. if there is more information available than can be collected, but it may also be a deliberate choice to reduce or adjust the information. This thesis is concerned mainly with the third step: the presentation of awareness information. However, it should be noted that an awareness service necessarily has to provide adequate solutions for the other two steps as well. 4.3.2 Abstract Process Model Understanding the activities of others requires 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 (Figure 4-2). Available information about one user's activities must be communicated and must be processed by the other users. This process is initiated by some user action, resulting in a state change of the shared artefact. The state change is propagated as an event to all user sites. The final step is the perceptualization, the act of presenting the information contained in the event for a certain user. Perceptualization is a necessary but not sufficient precondition for perception. It does not occur for all events nor all information contained in them at the same time. Perceptualization can be omitted, delayed, or synthesized. Perceiving the presentation of an event makes users aware of the originating action. Note that this process constitutes a feedback cycle: awareness of others' activities influences future actions of a user on the common artefact. 50 Awareness User A Distribut e ed Com C p o u rfac m ter m Sy on A stem rtef / act Goal er InteUs results in results in Plan Action influences creates causes affects State Change describes Event State shows shows triggers Perception Perceptualization allows allows Awareness e rfac er Inte Us Us er B Figure 4-2. Creating awareness in computer supported cooperation This description refines the three-step model described before. Necessary information about the computer-supported work must be present as a computer model to be distributed to all participants. Perceptualization to present the information must be performed in the right way and at the right time, depending on the current situation of each participant. 4.4 Classification of Awareness Information Systems supporting awareness have to provide and store large amounts of information. Traditional single-user systems have to handle document contents and meta-information on the documents, such as names or structuring information. The former are the actual work objects, while the latter is necessary for document management. To support awareness, multi-user systems additionally have to deal with information on the cooperation context, i.e. awareness information (Figure 4-3). Classification of Awareness Information 51 ity Quant tion Informa Awareness Document Management Single-User Work Document Contents Document Meta-Information Context & Awareness Information Figure 4-3. Extension of the information space Systems must be designed in a way that the necessary information is present in the computer system. Awareness information can be classified by the type of question it answers. One can ask: * who is doing something (the originator of an event); * where does he do it (location); * what is he doing (action); * how does he do it (invocation); * why did he do it (motivation); * when did he do it (time). The last question actually defines a second dimension, because it is perfectly possible to extend the other questions to the past: who did something before? Extending them to the future as well ("What will be done next?") would raise interesting questions, but is usually simply impossible. Information concerning future events ("Mail will arrive tomorrow.") in fact only reflects some other people's past actions. The following examples illustrate how perceptualization concerning these different questions can be realized. Different colors or cursors can be used to identify individual users. An animated replay of the steps that were necessary to invoke a mouse operation (Berlage and Spenke, 1992) can show how a certain effect was achieved. Time stamps and annotations can be used to indicate when and why an action took place. A certain perceptualization mechanism often answers more than one question at once because there is a strong relation between those questions. As another example, background video images answer the "who", "what" and "when" questions, but regarding real-life activities of users. The previous examples were concerned with their computer activities. This leads to a third categorization distinguishing between activities in the real and the virtual world. Note that the distinction between a "real" and a 52 Awareness "virtual" world is a difficult one: a document in a computer system may be considered to be a real object consisting of a physical sequence of binary values. For our discussion, "virtual" refers to all objects and operations that are existent in a computer system only, while those having a representation outside a computer are "real". estionsQu W ho W here H ow W hat W hy O rigin Virtual R eal Time (When) Figure 4-4. Three dimensions of awareness information Figure 4-4 shows the relation between these three categories. The primary focus of our discussion is described by the shaded part of the diagram. We exclude future events, because predicting the future is obviously impossible in general and misleading at best. While most of the discussion applies to real-life events as well, it should be noted that special hardware is needed to adequately support these events. For example, active badges (Want and Hopper, 1992) are small electronic devices worn by users that constantly transmit their position. In combination with corresponding software, movements and locations of users in the real world can easily be tracked. Another example is the "Extra Eyes" System (Yamaashi et al., 1996), which incorporates a series of sensors (referred to as "sensory surrogate") into a video conferencing system to alert users to real-world events, e.g. somebody opening the remote office door. 4.5 Design Requirements for Awareness Support The importance of providing awareness in computer supported cooperation has been discussed in the previous sections. It is important to note that almost any groupware system supports some form of awareness mechanism; a consequence of the fact that awareness is a basic requirement that is essential for effective cooperation. However, as discussed before, many systems seem to support awareness in an ad hoc fashion. System designers are not aware they actually support awareness. Awareness facilities are Design Requirements for Awareness Support 53 realized merely as a by-product of some other groupware functionality. The many different aspects that have to be considered in the design of an adequate awareness support are frequently overlooked, neglected, or ignored altogether. A more sensible approach would be to consider the problems related to the awareness facilities as a central design issue in a systematical way. This means that all the different factors that influence and guide the design have to be taken into account. Human Capabilities Technical Possibilities Functionality Design Social Aspects Organizational Aspects fluence In ltural Legal Constraints Cu Figure 4-5. Design Factors of the Awareness Service Figure 4-5 shows the six main design factors (Fuchs et al., 1996; Sohlenkamp et al., 1997a): * Social aspects: How does social interaction influence the design requirements? * Legal considerations: Which regulations are relevant in the context of the awareness service? * Organizational issues: How is the organizational structure reflected in the design? * Technical possibilities and constraints: Which solutions are practicable using current technology? * Human capabilities: Which techniques and mechanisms are well suited to meet human possibilities? * The envisaged functionality: What is the general purpose of the system? The first three aspects dealing with social questions are heavily intertwined. Furthermore, they are strongly influenced by the cultural background of the intended users. The different design goals may conflict, e.g., a demanded functionality might be prohibited by law. While the same general design aspects are applicable for the development of most interactive groupware systems, there are special considerations for the design of the awareness service. Therefore, we will discuss the different design factors below. A design that fails to consider all these criteria in an adequate way usually results in poor suitability of the system to support actual work practice and poor acceptance rates of the intended users. 4.5.1 Social Aspects In single-user systems, social aspects are of minor importance. This is not the case for applications supporting the cooperation of multiple users. In particular, social aspects have to be considered for the provision of awareness information at the user interface. These aspects include group and individual working styles, social conventions and protocols, etiquette and 54 Awareness unwritten rules of the working place, group dynamics, etc. For example, it might be considered impolite to observe how others accomplish their work, although this would be fairly easy to realize technically. As discussed before, systems should rely on the establishing of social protocols and conventions analogous to those used in real-world cooperation. The important issue for the design of the user interface is to make this kind of social protocols possible. For example, it is possible to ensure that everyone who observes someone else's activities can be observed as well (or at least his observation activity is logged and can be inspected later). By supporting this kind of social symmetry, using the awareness information for control purposes becomes much more difficult. 4.5.1.1 Legal Constraints Any groupware system (in fact, any computer system) that is to be used in real-life working situations has to consider several legal issues that influence the way information can be processed and used. Legislation varies heavily from country to country, depending on the cultural background. As an example, we will discuss the relevant German regulations. These are similar to those of most western European countries. In general, they tend to be more restrictive than the corresponding North American or Asian regulations. First of all, data protection laws have to be considered: they prescribe what data may be collected, for which purposes, and in what way it may be processed. This has severe consequences for the awareness service. For example, working profiles of employees, e.g. their working time, their working style, and their efficiency, could easily be produced systematically in theory. In practice, the system has to ensure that this is impossible. In 1983, the German Constitutional Court recognized the "right of informational self determination". Basically, it defines that people themselves decide what information about them is made available to others. Obviously, this has strong implications for the design of the information service: users must be able to maintain privacy by controlling outgoing information. Finally, work procedures themselves may be regulated. For example, in Germany administrative ministerial work is prescribed in the GGO (joint set of procedures for ministries). It prescribes every detail of the ministerial workflow (Mambrey and Robinson, 1994). Obviously, any system designed to be used in such a working environment therefore has to conform to those rules. 4.5.1.2 Organizational Issues The structure of the organization to be supported is another factor that influences the design of the awareness service. There is usually less necessity to be informed about others' activities in organizations structured according to a strict hierarchical model. This is due to the fact that this structure favors the division of labor, where people have their own limited field of work that is not influenced by others. Modern organizational theory, however, tends to favor flat structures with few hierarchical levels, providing more flexibility of the overall working process. Since Design Model 55 these organizational forms rely on a high degree of transparency, the need for awareness increases dramatically. In addition to legal considerations discussed before, organizational handbooks, guidelines, and regulations have to be considered and integrated into the system. Also, the strong position of pressure groups in an organization, e.g. labor unions or the board of shop stewards, has to be considered, for instance by integrating them in the design process. 4.5.2 Technical Aspects The technical possibilities of the electronic medium form a two-edged sword. On the one hand, computer support offers possibilities going far beyond those available in cooperation without electronic support (Hollan and Stornetta, 1992). This concerns in particular the enormous data storage capabilities, the ease of information retrieval, and support for innovative presentation and visualization techniques. On the other hand, computers are restricted in many ways. Computer input and output devices only support a small part of the human sensorial system. Screen space-by far the most important information output medium-is a very limited resource. This makes it difficult to convey the same amount of information that is available during real-life, same place cooperation. Therefore, alternative perceptualization techniques making better use of the available resources have to be developed. An important concept regarding this problem is the use of distortion. By distorting the display, information can be focused on the actual interest of the user while peripheral context remains visible. Distortion can be applied both to space and to time (cf. Section 5.2). 4.5.2.1 Human Capabilities The problem of human cognitive abilities and sensorial capabilities is related to the technical possibilities discussed before. Humans cannot process an arbitrary amount of information, nor can they focus on more than one spot of attention. Because of the former, information overload has to be avoided, such that users do not become distracted from their work by a flood of information that is useless or misleading in the current working context. The latter has the consequence that the information should be integrated into the working context as much as possible, considering the current focus of interest, to avoid distracting users from their actual work. Also, human memory capabilities have to be taken into account. The difficulty to memorize all relevant aspects of a cooperation creates the need for a history service that displays past events even if the users have already seen them before. 4.6 Design Model Based on the requirements described before, this section presents a design model for awareness services that takes the different influencing factors into account (Sohlenkamp, Fuchs et al., 56 Awareness 1997a). This model is not meant to describe the only possible way to implement awareness functionality; other models are certainly possible as well. Nevertheless, it serves two important purposes. On one hand, it may be used as an implementation guideline, providing designers with a clear notion of crucial design elements. On the other hand, the model may also be used to analyze the awareness features of existing groupware systems. In this function, it provides a framework that allows a categorization of the different functional components of an awareness service. 4.6.1 The Awareness Information Pipeline An implementation of awareness facilities requires a flow of information as illustrated in Figure 4-6. Note the correspondence between this figure and the abstract model of awareness information flow discussed before (Figure 4-2). In the following discussion, numbers in brackets refer to the corresponding parts of Figure 4-6. U ser Interface: 1 C ollection G lobal F ilter: 3 Allowed Events E Individual Filter: 4 ve O utgoing E vents nt ation er Con en s G u 5 mpt nt Transport 2 ve M echanism i E on Individual Filter: 6 Incoming Events U ser Interface: 7 Presentation Figure 4-6. The awareness information pipeline Awareness mechanisms may be viewed as an information pipeline, where event information resulting from work activities of users is collected and subsequently sent to other users who receive this information in some way. This pipeline has to be augmented with several functional components that provide the necessary functionality to take care of the specific factors in the cooperative setting and allow to take into account the different aspects which have been introduced in the preceding sections. The pipeline model is unidirectional by intention. Awareness information flows in one direction only: from the originator to the recipient. This eases identification and subsequent implementation of the involved components. However, in many situations it is important that users are aware of the awareness level of their cooperation partners as well. This can be especially important for users to coordinate their activities based on a common understanding of individual knowledge of the status of the cooperation process. Design Model 57 The model provides no direct back channel to signal the receipt of an information or to acknowledge its reception in these cases. However, the presentation part at the end of the pipeline may enforce users to acknowledge an information (e.g. by having them press a button to confirm a message box). Moreover, the model implies that an individual awareness pipeline exists between all participants of a cooperation. Therefore, the reaction of a user to an incoming awareness information presentation may itself result in the generation of an event that is transferred back to the originator of the original message. Obviously, this requires the explicit modeling of these meta-events into the system. While more elaborate schemes could be devised and integrated into the model, this is beyond the scope of this thesis. 4.6.2 Components of the Awareness Information Pipeline The awareness information pipeline identifies seven major components of the awareness service: 1. the originator's user interface collecting information; 2. a transport and distribution mechanism; 3. a global configuration filter; 4. an individual privacy filter; 5. a persistent history storage; 6. an individual interest filter; 7. the receiver's user interface presenting information. In most systems supporting awareness, not all of these components are actually present. Collection, transport, and the user interface presentation have to be available for any form of awareness support (cf. Section 4.3.1). Otherwise, users would either not receive any information related to others, or they would not be able to perceive it. A persistent history and individual interest configuration are not strictly necessary, but are usually supported at least in a rudimentary way. The global configuration and the privacy filter, however, are far less prominent with system designers. Partly, this may be due to the fact that the aspects covered by these components are only relevant if the system is used in real-world application domains; they are negligible in a research context. The different components will be described in more detail below. Moreover, the presentation component will be discussed in great detail in the next chapter. In Chapter 7, we will introduce the awareness service of the POLITeam system which was implemented using this model as a basis. 4.6.2.1 Collection Most awareness information is associated with some user action. Therefore, the user interface at the originating site is the appropriate place to gather this information. All user actions are related to activities at the user interface which can easily be used to collect the corresponding information. Note that this applies both to activities regarding the computer artefact, which may 58 Awareness be modified by input devices like mouse or keyboard, and to real life activities, which may be collected using special hardware. 4.6.2.2 Transport and Distribution Awareness information has to be stored and distributed. Therefore, systems need both a transportable representation of events, a transport mechanism, and a transport medium. The later may consist of any form of computer network and will not be discussed further. The transport mechanism defines the distribution algorithm: which events are to be transported to which site respectively to which user. 4.6.2.3 Global Configuration Global configuration of the awareness service has two main aspects. First, on a technical side, it defines functional details, like persistence, for specific event classes. Second and more important, it enforces organizational rules and constraints. Most features of the awareness service can potentially be used-besides their main purpose to allow efficient cooperation-to monitor and control others. This problem depends heavily on the actual working environment. Therefore, the decision of which awareness information to provide in a certain situation should not be hard-coded in the system, but rather be configurable and made visible in a flexible way. This configuration may take place prior to system installation or during system usage. To prevent misuse of the system, it should be subject to organizational agreements. Moreover, since the global configuration reflects organizational and legal constraints, only privileged users (i.e., the system administrator or the system designers) should be able to modify it. 4.6.2.4 Privacy To protect users' privacy, a mechanism filtering events at the originating site should be provided. This filter may be configurable both by the users themselves, as well as support automatic configuration based on the system state and the current work context. In any case, the global configuration filter supersedes any instructions given in the privacy filter. This way, the effect that users simply disable transmission of any personal information by means of the privacy filter can be avoided. For example, the global configuration may define that events happening in a shared workspace must not be suppressed, thereby facilitating cooperation by using shared workspaces. Note that in this case, users are aware of the fact that events in a shared workspace are transmitted because the settings of the global configuration are (potentially) known by all users. However, this introduces the problem of adequately visualizing filter settings to users. The same mechanism of filtering events is also used on the consumption side of the information pipeline to prevent information overload. By having an analogous model both to specify interest in events and privacy concerns, users do not have to deal with different concepts. 4.6.2.5 Event History The possibility to access the history of past events becomes important for several reasons: Design Model 59 * As an indication of past activities. Users can quickly spot where activities took place. History provides additional context for past activities. * For rehearsal. Users can reconstruct their own or other people's past actions to understand the current state of the artefact. * For accountability. The history can be used as a legal proof of which user was responsible for a certain action. * For catch-up. Users are not available at all times. Therefore, users that were absent from the cooperation (from minutes up to months) can scan what has happened during their absence. * Resolution of version conflicts. Individual changes can be kept to decide in case of conflict which of two conflicting actions to keep and let the system offer some support for the construction of new versions. While most of these topics are not essential to ensure a working system, the accountability aspect may be mandatory in some working environments where it must be possible to track responsibilities (Prinz and Kolvenbach, 1996). 4.6.2.6 Individual Interest In the same way as the privacy filters, events should also be filtered depending on user interest. The reason to provide these filters is to prevent information overload and disruption. Note that for both types of filter-privacy and interest-users themselves directly profit from the additional work they invest in configuring them. Besides user-defined filters, filters can also be defined by the system, either as default for specific objects or automatically adapted to changing work contexts. For user-defined filters, users should be able to define interest for classes of objects (e.g. for all text files or all shared workspaces), for specific instances of objects (e.g. a text written jointly by a group of people), and for objects that meet specific criteria (e.g. all objects that were modified by a certain user). Furthermore, users should be able to define the intensity used for presenting an event. This way, users can ensure not to miss certain events while others may be monitored peripherally. 4.6.2.7 User Interface To present the dynamics of an ongoing cooperation, thereby providing awareness, state changes have to be visualized adequately. The main reason for providing awareness is to help users coordinate their tasks without interrupting their work. Therefore, it is important to present the information in a way that is as unobtrusive as possible, yet allowing the signaling of different degrees of importance and giving users the chance to get an overview of activities at a glance. Different techniques must be provided that support different levels of notification in accordance with the relevance of an event. The user interface serves as a final filter for the awareness information flow: ideally, only those events that are actually relevant in a given situation are made visible to the user. The interface has to support different mechanisms to adequately present events to other users. It should provide an overview, employ temporal and spatial distortion, include a user 60 Awareness representation, allow active and passive forms of information generation and consumption, and fit into the metaphors employed by the overall interface. These aspects will be discussed in detail in the next chapter. 4.7 Conclusions Awareness can be defined as an understanding of the state of a (socio-technical) system. It is necessary for all forms of cooperation: it is needed to coordinate and fine-tune cooperative work, to allow informal communication, and to establish conventions on the usage of shared material. Despite all these facts, awareness support is often neglected in CSCW systems, or it is treated in an ad-hoc manner. Providing awareness information is a complex problem involving technical, organizational, social, and legal questions. The process of creating awareness involves several steps: information has to be collected, distributed, and presented. To become aware of others' activities, the right type of information has to be available: information answering the who, when, why, where, and what questions regarding state changes. Invariably associated with user awareness are the problems of user privacy and user disruption. The awareness pipeline model, identifying seven major components of an awareness service- event collection, transport mechanism, global configuration filter, individual privacy filter, persistent history storage, individual interest filter, and user interface presentation-addresses all these aspects. It constitutes a guideline to analyze and design systems supporting user awareness. In the following chapters, we will complete this discussion by providing a detailed analysis of the user interface aspects of the model, and by describing a concrete implementation based on it. . 5 Perceptualization "Awareness are all things we see in a CSCW environment that we would not see in a single- user application." P. Dewan In the preceding chapter, we have discussed the general importance of awareness, and developed a design model for awareness support in computer applications. This model identified the user interface as a crucial element in the information pipeline. Collecting awareness information is pointless if is not presented in some way to the user. From a user interface point of view, this provision of additional information is one major difference of multi-user systems from single user applications. As discussed before, awareness information is any kind of meta-information on the state of the system: any information related 62 Perceptualization to the who, why, when, where, and what questions discussed in Section 4.4. We have shown that this information is necessary to support efficient cooperation in the multi-user case. The fundamental interface mechanisms to present the shared activity are the static presentation of awareness information and the dynamic notification of state changes. We call their combination perceptualization: the act of making others' activities perceivable. There are two aspects that have to be considered: the information to present has to be selected, and the actual presentation has to be performed. This continuous process of making the current system state perceivable to provide awareness will be discussed below, describing the different interface issues that a system designer has to consider. We will start with a general description of the perceptualization process. This is followed by an elaboration on the use of distortion as an essential perceptualization concept. Finally, we discuss the details of the selection and presentation steps that constitute this process. This discussion forms a framework describing in detail the different aspects of perceptualization. Again, this framework can be used both to analyze existing designs (cf. Chapter 6) or to synthesize new ones (cf. Chapter 7). In the former case, its application can provide valuable insights on shortcomings of the awareness service that is examined, while in the latter case it provides a guideline for the successful design of perceptualization functionality. 5.1 The Perceptualization Process Perceptualization is a necessary precondition to become aware of others' activity. However, not all forms it can take are equally well suited to stimulate this process. On the one hand, enough information to make awareness possible must be conveyed, while on the other hand information overload and user disruption should be prevented. Event Pool Dynamic Storage Selection Static Selection Presentation Figure 5-1. The perceptualization process There are two aspects that have to be considered (Figure 5-1, cf. also Berlage and Sohlenkamp, 1995; Gutwin and Greenberg, 1996): * Perceptualization is a selective process which depends on user preferences and the requirements of the current working situation. Depending on the situation, not all events are of relevance to a user, nor are all the details contained in an event. Therefore, the pool of all events has to be processed to filter the relevant information. The filter needs both mechanisms to estimate the relative importance of an event for a user as well as techniques to select details according to their relevance. This may involve omitting, aggregating, or The Perceptualization Process 63 otherwise modifying the information contained in an event. An important aspect is that this can be a recurring process: the same event may be processed several times, each time using different forms of presentation because the working situation of the user has changed. * The actual presentation based on the selected events has to be produced. Presentation has a dynamic and a static phase. The former highlights state changes for a limited amount of time, while the latter shows the current state of the artefact permanently. Further important factors in the presentation context are the medium to use-optical and acoustical signals being the most prominent options-and the general mechanisms best suited in a specific situation. In particular, we have to deal with the problem of making maximum use of the limited computer resources, e.g. restricted screen space. Additionally, specialized aspects of the information have to be represented adequately. Finally, the problem of user interaction with the presentation has to be considered. In the following sections, we will develop the two stages of the framework, analyzing the relevant factors of this process. The framework covers aspects of information origin, time, relevance metrics, visibility, fidelity, information medium, temporal and spatial distortion, integration into existing interfaces, representation of additional information, invocation, and reception. Table 5-1 summarizes these different aspects and shows their relation to the different steps of the perceptualization process shown in Figure 5-1. Each of them will be elaborated in detail below. Again, we will use our DIVA system as an example. However, we will also refer to other existing systems that employ similar or alternative perceptualization strategies. Table 5-1. Aspects of the perceptualization process Aspect Description Origin How is awareness information created and collected? Storage Event Pool Time To which time does the information relate: past or present? S Relevance How can the relevance of an event for a user be estimated? electio Visibility Which information should be made perceivable? n Fidelity How can awareness information be modified to meet user's needs? Medium Which information medium is best suited for a presentation? Dy Time Distortion Which temporal distortion techniques should be used? namic Stati c Space Distortion Which spatial distortion techniques should be used? Integration How are presentation techniques integrated in the overall interface? Representation How is additional awareness information represented? Invocation How is the perceptualization process started and influenced? Reception How can perception be influenced? Not all the aspects covered by the framework are innovative concepts by themselves. However, the framework integrates them into an overall perspective on the whole perceptualization process, thereby providing insights that would not be available otherwise. Combination and sequencing of the different design factors is another important aspect that would not be addressed by a discussion of the different factors in isolation. 64 Perceptualization 5.2 Distortion Distortion is a key concept for perceptualization. Technically, distortion is a modification of an input signal to create an adapted output signal. For the perceptualization process, the input signal is the sequence of awareness information over time (describing user activities). The output signal consists of the user interface output to present awareness information. If no distortion is applied, the presentation of awareness information to other users corresponds exactly to the user interface feedback of the original action at the originating site. This form of strict WYSIWIS (What You See Is What I See) is only of limited use, because it does not consider individual requirements and restricts users in their work (Stefik et al., 1987). Generally, presentation of awareness information has to be distorted to adapt to differing and changing user needs. It is an important concept to deal with the two major problems of providing awareness information: disruption and privacy violations. For the former, distortion allows compression of information, showing important details while retaining necessary context, thereby reducing cognitive load of the user. Regarding the latter, distortion of the information may be used to hide private information details, thereby anonymizing data. There are two different forms of distortion to consider: temporal and spatial distortion. Temporal distortion means that the temporal sequence or time information of the input signal is modified. This is the case if information is presented asynchronously (e.g., a history presentation), or if the presentation takes a longer or shorter time than the original action (e.g., a synthesized animation). Since temporal distortion is not a persistent effect (persistence implies stability over time), it is necessarily a dynamic effect. Spatial distortion is a modification of the awareness information space. Since this is an abstract space, spatial distortion is not limited to changes to the actual spatial layout of objects on the screen; it does also include techniques like changes of the presentation medium or the omission of information (i.e., it includes "semantical distortion"). Therefore, spatial distortion may be applied both in the selection and the presentation phase of the perceptualization process. Both forms of distortion can also be combined by modifying the awareness information space and the temporal arrangement simultaneously. 5.3 Selection of Awareness Information The first steps in the perceptualization process regard the selection of the information others are actually notified about: what information from the available event pool should be presented, and when is the appropriate moment of doing so? Of course, these two questions are strongly related, because the amount of information to display changes over time, together with the working situation of the user. Selection of Awareness Information 65 5.3.1 Information Origin Awareness information has to be created and collected. The main issue regarding the perceptualization process is the amount of work users have to invest to generate the information. Active and passive forms are possible. In the case of active creation of awareness information (with "active" referring to the user and not the system), users have to provide information explicitly (or actively), for example by typing in notes or sending an email, i.e. they use an explicit communication channel. If a deictic connection between the common artefact and the awareness information is needed, it must be specified explicitly by the user, e.g. by writing a note and attaching it to a specific object. Explicit annotations on the artefact are another technique used by many systems like Quilt (Leland et al., 1988) or Mate (Hardock et al., 1993). In contrast, passive awareness information is collected by the system as a side effect of user actions. Passively collected information can easily be displayed in the same space as the common artefact itself. An example is shared feedback for mouse operations as used by DIVA. Clearly, the passive approach offers many benefits. Users are not enforced to provide necessary information themselves. The well-known problem that users are reluctant to invest work if they do not directly benefit from it (Grudin, 1988) is avoided. Additionally, the problem that different people have different ideas of what is to be considered important is eliminated as well. The modification of awareness information as described below is more useful for passively collected awareness information. In the active case, it is difficult for the system to modify the information in a meaningful way because of an insufficient semantic background. For these reasons, any reasonable awareness service should incorporate a passive information collection mechanism. Nevertheless, active awareness information can be important as an addition to provide information unavailable otherwise; for example to signal the intentions of a user. In this case it is important that the user interface supports an easy, non-disrupting way to enter the information to ensure that this feature is accepted by users. 5.3.2 Time Aspects Once collected, awareness information may be presented synchronously to the users. However, it may also be stored to be presented asynchronously using temporal distortion. Two forms of presentation have to be considered. The first is synchronous presentation: the presentation is created at the same moment the corresponding user action takes place. In contrast, asynchronous presentation is related to user actions that happened in the past. In the synchronous case, the presentation mainly aims at supporting the coordination of the ongoing working process. The necessity of an asynchronous presentation of awareness information has been discussed in Section 4.6.2.5: it provides an indication of past activities and is important for rehearsal, accountability, catch-up, and the resolution of version conflicts. For example, DIVA supports both the synchronous and asynchronous form. Shared command feedback, the animated movement of objects, and audio cues are the main techniques in the synchronous case. For asynchronous presentation, DIVA offers a command history, allowing 66 Perceptualization users to get an animated replay of past actions on the common artefact. The GroupDesign system (Beaudouin-Lafon and Karsenty, 1992) uses the same approach. The Alliance system (Decouchant et al., 1995), a structured text editor with groupware functionality, uses a special form of asynchronous presentation: users explicitly commit their changes for the system to make them visible to others. Stone et al. (1994) describe the use of a visible filter tool as a history mechanism. Once applied to a part of a document, it shows a previous document state and allows interaction with the objects that were existent at that point in time. A similar approach is discussed by Genau and Kramer (1995) who use superimposed semi-transparent layers to display different historical stages of a document. Due to the transparent nature of the history layers, object changes can easily be tracked. By changing the stacking order of the layers, interaction with old document versions becomes possible. Regarding the selection of information, the synchronous and asynchronous approaches have different requirements. In the synchronous case, there is a defined time slot where an event can be presented. Information needs to be less detailed (Rhyne and Wolf, 1992). Since a synchronous presentation is inevitably created by the system without an explicit user request (users cannot predict when other users' actions will happen), the aspect of preventing user disruption and distraction from their work becomes the most important issue. In contrast, asynchronous presentation is frequently expected by the user, either because it was invoked actively or because it is related to certain user actions (e.g., automatic catch-up after opening an application). In these cases, the main aspect is to provide concise information while preventing information overload. While the same basic techniques can be used, the amount of information actually used will usually be larger. Of course, it can be reduced substantially by techniques unavailable for synchronous presentation, like aggregating related events. 5.3.3 Estimating Relevance Selecting events for presentation depends on one crucial issue: estimating how relevant an information currently is for a particular user. Ideally, only information needed in the current working context should be presented. The relevance of an information depends on the individual user and changes dynamically in accordance with his working situation. Therefore, determining the importance of information is a very difficult task. Again, active and passive approaches are possible. Users can explicitly register their interest in certain events, possibly in relation to specific work situations (Fuchs et al., 1995), e.g. by selecting from a list of possible events related to specific objects. While this permits a fine- grained selection of information, it does not adapt well to changing working situations without user intervention. Furthermore, the process of defining which events are important is often a tedious and difficult task for the user. Alternatively, systems can automatically derive an estimate from different factors related to the event. Examples are the type of an event, its originator, or its spatial location. This allows the system to decide dynamically which form of presentation should be used, depending on the current situation. However, automatic selection usually fails to consider the individual requirements of users. Therefore, a combination of both approaches, providing the ease of use Selection of Awareness Information 67 of automatic selection and the flexibility of user-defined filtering, is necessary to provide an adequate mechanism to decide if an information is important for a user. DIVA, for example, supports both approaches. It allows users to explicitly select a coupling mode for a given cooperation. This defines the types of events other users are notified about: in the case of a loosely coupled session, only events describing an actual state change are considered. In a tightly coupled session, also events describing changes of the view on the shared artefact, like the scrolling of windows or the selection of objects and menu entries, are visualized. As another example, the Flexible Diff system (Neuwirth et al., 1992) allows users to specify the granularity of events to be reported. Fuchs (Fuchs, Pankoke-Babatz et al., 1995) describes an elaborate mechanism allowing users to specify interest in events based on objects and their current working situation. For automatic filtering, DIVA-like many other systems-uses the simple approach that all events affecting areas currently visible on a user's screen are made visible to that user, while other events are not considered. This simple approach can be expanded to allow more sophisticated approximations of the relevance of an event. For example, the distance between a location associated with the event and a location associated with the user can be evaluated. In other words, an "interest area" is assigned both to events and to users. If the interest area of an event and that of a user overlap, the corresponding information is presented to the user. Furthermore, the form of the presentation can depend on how "close" event and user are located. As for the first question, a useful definition would be to As for the first question, a useful definition would be to As for the first question, a useful definition would be to use the semantic superstructure of the element that is use the semantic superstructure of the element that is use the semantic superstructure of the element that is actually referenced by a command. Of course, if there actually referenced by a command. Of course, if there actually referenced by a command. Of course, if there t - d is no such structure - either because there is no useful is no such structure - either because there is no useful is no such structure - either because there is no useful structuring for the document contents or because it is structuring for the document contents or because it is structuring for the document contents or because it is Change not implemented in the application - , it is the element not implemented in the application - , it is the element not implemented in the application - , it is the element itself. The result of this definition is, for example, that if itself. The result of this definition is, for example, that if itself. The result of this definition is, for example, that if a user changes a word in a text, the whole paragraph is a user changes a word in a text, the whole paragraph is a user changes a word in a text, the whole paragraph is included in his aura. included in his aura. included in his aura. If the user explicitly registers interest in a part of a If the user explicitly registers interest in a part of a If the user explicitly registers interest in a part of a document, he can specify in what kind of semantic document, he can specify in what kind of semantic document, he can specify in what kind of semantic superstructure he is actually interested: for example, if superstructure he is actually interested: for example, if superstructure he is actually interested: for example, if he selects a word and registers interest, he could choose he selects a word and registers interest, he could choose he selects a word and registers interest, he could choose from the structure hierarchy word / sentence / from the structure hierarchy word / sentence / from the structure hierarchy word / sentence / paragraph / chapter / document, which should be made paragraph / chapter / document, which should be made paragraph / chapter / document, which should be made visible at the interface (e.g. by presenting an visible at the interface (e.g. by presenting an visible at the interface (e.g. by presenting an appropriate submenu for a register interest" menu appropriate submenu for a register interest" menu appropriate submenu for a register interest" menu entry). This is not possible for the dynamic parts of the entry). This is not possible for the dynamic parts of the entry). This is not possible for the dynamic parts of the aura; in these aura; in these aura; in these cases the system has to choose a best" superstructure. cases the system has to choose a best" superstructure. cases the system has to choose a best" superstructure. User Interest Area Of course, this could also be defined and changed by Of course, this could also be defined and changed by Of course, this could also be defined and changed by the user as a global application setting. The problem the user as a global application setting. The problem the user as a global application setting. The problem with this approach is that application programmers with this approach is that application programmers with this approach is that application programmers t t have to provide a semantic structure for their have to provide a semantic structure for their have to provide a semantic structure for their documents which is not necessarily easy. Furthermore, documents which is not necessarily easy. Furthermore, documents which is not necessarily easy. Furthermore, many documents do not even have a semantic many documents do not even have a semantic many documents do not even have a semantic structure. However, the approach remains valid for structure. However, the approach remains valid for structure. However, the approach remains valid for documents without such a structure by including any documents without such a structure by including any documents without such a structure by including any object itself in the list of its superstructures. object itself in the list of its superstructures. object itself in the list of its superstructures. As for the parts of the document he last worked on", As for the parts of the document he last worked on", As for the parts of the document he last worked on", there should be a time treshold defining how long those there should be a time treshold defining how long those there should be a time treshold defining how long those parts remain included in the aura. Alternatively to parts remain included in the aura. Alternatively to parts remain included in the aura. Alternatively to removing it completly from the aura after that time removing it completly from the aura after that time removing it completly from the aura after that time period, it could also be reduced gradually to its period, it could also be reduced gradually to its period, it could also be reduced gradually to its semantic substructure, resulting in a more dynamic semantic substructure, resulting in a more dynamic semantic substructure, resulting in a more dynamic inclusion of that object in the aura. inclusion of that object in the aura. inclusion of that object in the aura. Note that the simple approach used by many systems Note that the simple approach used by many systems Note that the simple approach used by many systems where all commands are visualized and the users just where all commands are visualized and the users just where all commands are visualized and the users just sees those that happen to be visible in that part of the sees those that happen to be visible in that part of the sees those that happen to be visible in that part of the document visible in his application window is a special document visible in his application window is a special document visible in his application window is a special case of the concept described before. In this case, the case of the concept described before. In this case, the case of the concept described before. In this case, the aura of the user is simply the rectangular area of the aura of the user is simply the rectangular area of the aura of the user is simply the rectangular area of the window showing the part of the document he is window showing the part of the document he is window showing the part of the document he is interested in; he did not register interest in any parts of interested in; he did not register interest in any parts of interested in; he did not register interest in any parts of the document and the time treshold for including the the document and the time treshold for including the the document and the time treshold for including the last edited parts of the document is set to zero. Again last edited parts of the document is set to zero. Again last edited parts of the document is set to zero. Again the aura of the command is the document area that is the aura of the command is the document area that is the aura of the command is the document area that is affected in some way by the command visualization. If affected in some way by the command visualization. If affected in some way by the command visualization. If these two areas happen to overlap, the user can see at these two areas happen to overlap, the user can see at these two areas happen to overlap, the user can see at least a part of the command visualization. Additionally, least a part of the command visualization. Additionally, least a part of the command visualization. Additionally, he sees more of it if it is closer to the center of his he sees more of it if it is closer to the center of his he sees more of it if it is closer to the center of his interests: the middle of his application window. interests: the middle of his application window. interests: the middle of his application window. Of course, this simple approach is not enough to support Of course, this simple approach is not enough to support Of course, this simple approach is not enough to support more complex models of awareness of co-workers more complex models of awareness of co-workers more complex models of awareness of co-workers activities. Consider the example described before: an activities. Consider the example described before: an activities. Consider the example described before: an user wants to be alerted to changes in his part of the user wants to be alerted to changes in his part of the user wants to be alerted to changes in his part of the t + 2d document even if he is not actively looking at it. That document even if he is not actively looking at it. That document even if he is not actively looking at it. That could be accomplished by establishing that the aura of could be accomplished by establishing that the aura of could be accomplished by establishing that the aura of a command consists of the area occupied by its a command consists of the area occupied by its a command consists of the area occupied by its semantic superstructure, for example a paragraph in semantic superstructure, for example a paragraph in semantic superstructure, for example a paragraph in the case of a text editor. Therefore, changes to a the case of a text editor. Therefore, changes to a the case of a text editor. Therefore, changes to a paragraph would be made visible to any user who is paragraph would be made visible to any user who is paragraph would be made visible to any user who is looking at any part of that paragraph, regardless looking at any part of that paragraph, regardless looking at any part of that paragraph, regardless whether the changing part is actually visible on the whether the changing part is actually visible on the whether the changing part is actually visible on the screen. F screen. F screen. F or extremly important operations, the aura could be or extremly important operations, the aura could be or extremly important operations, the aura could be defined to be the whole document (or even the whole defined to be the whole document (or even the whole defined to be the whole document (or even the whole screen), thereby forcing users to see a change in any screen), thereby forcing users to see a change in any screen), thereby forcing users to see a change in any case if they are working on some part of the document case if they are working on some part of the document case if they are working on some part of the document Current Window (or even if they are not working on it). To display (or even if they are not working on it). To display (or even if they are not working on it). To display information that is outside the part of the documents the information that is outside the part of the documents the information that is outside the part of the documents the user is currently working on, additional windows (or user is currently working on, additional windows (or user is currently working on, additional windows (or information planes) may be opened. On the other hand, information planes) may be opened. On the other hand, information planes) may be opened. On the other hand, changes occuring because a command without a aura changes occuring because a command without a aura changes occuring because a command without a aura (or more precisely, with a null aura) is executed only (or more precisely, with a null aura) is executed only (or more precisely, with a null aura) is executed only become visible if an user actually looks at the state become visible if an user actually looks at the state become visible if an user actually looks at the state change. change. change. Note that the aura can both be defined automatically - Note that the aura can both be defined automatically - Note that the aura can both be defined automatically - as in the text editor example where every character as in the text editor example where every character as in the text editor example where every character belongs to a paragraph - but it can also be defined by belongs to a paragraph - but it can also be defined by belongs to a paragraph - but it can also be defined by the user to add special points of interest (e.g. by the use the user to add special points of interest (e.g. by the use the user to add special points of interest (e.g. by the use of a special menu entry Add Interest"). of a special menu entry Add Interest"). of a special menu entry Add Interest"). Static Interest t t + d t + 2d Figure 5-2. Interest area of a user This concept relies on both events and users having a spatial location and expansion. Displaying only those events whose location is visible anyway is just a special case of the model: a user's interest area is the set of visible regions and the interest area of an event is 68 Perceptualization defined as the regions that are affected by the corresponding state change. Compared to this simple case, a better approximation is possible if the interest areas can be determined more accurately. For an event, it can be a defined area around the point in the common artefact where changes become visible or where a visualization or animation would take place. The definition for the interest area of a user has to be more complicated to include both static interest in certain parts of a document and the user's current working situation. To achieve this effect, the interest area of a user can be defined as being the sum of different areas (cf. Figure 5-2): the portion of the common artefact that is currently visible in his active application windows; the parts of a common artefact the user has explicitly stated interest in; and the parts of a common artefact the user has recently worked on (the recent history of working points). A time threshold defines how long those last parts remain included. Using spatial relations to automatically determine the relevance of information is popular with system designers. The User Centered Video system (Yamaashi et al., 1995) automatically adapts the transmission bandwidth of displayed video images. It uses a spatial relevance notion based on the distance of the video window from the window the user is actively working in. The DIVE system (Fahlén, Brown et al., 1993) uses a more complex approach which is also based on a spatial model. It uses object auras-subspaces bound to objects-to model proximity and therefore relevance. The model is augmented by the concept of focus and nimbus (Benford et al., 1994). These are again subspaces associated with objects, representing their level of attention and presence, respectively. If object auras overlap, the awareness level between these objects is a function of their foci and nimbi. Rodden (1996) describes a formal model that maps the spatial notions of focus and nimbus as used by the DIVE system onto non-spatial definitions. The model regards users, users' foci, and users' nimbi as different subsets of application objects. Users' awareness can be calculated as a function of these subsets. Since these definitions rely on set inclusion rather than spatial location, the model is applicable to a wide range of applications, even those without any spatial interpretation at all. In a similar way, Mariani and Prinz (1993) provide a formal model to describe awareness phenomena. They discuss a set of mathematical formulae to calculate numerical values for the "awareness factor" between users and working objects. Parameters that are included in the calculation are an object weight, an access operation weight, and the relative distance between objects (the latter requiring a spatial metrics to be defined on objects and users). With special hardware, real life activities of users can be used to estimate interest as well. For example, "eye movements and fixations can be valid clues to inferring an observers interest" (Starker and Bolt, 1990). 5.3.4 Visibility Not all events have to be made visible (or more precisely: perceivable) to all users. There are several reasons why perceptualization can be omitted altogether in certain circumstances: if the information related to the event is considered to be unimportant for the user, or if a notification is considered to be too disrupting in the current working context. Note that the omission of information is a spatial distortion. Selection of Awareness Information 69 Obviously, this approach relies on some metrics allowing the system to estimate the importance of an event related to a specific work situation for a given user, as discussed in the previous section. For example, people are potentially interested in seeing every action other users are performing during actual cooperative work. They do not want the same level of detail if not actively engaged in a cooperative session; the most important factor here would be to signal communication and cooperation willingness and availability to others (Gaver, Moran et al., 1992). If the focus is on a global level, information about the general activities of other people (for example in the same building, organization, or project) should be displayed, while the detailed activities of coworkers should not. Presentation of the detailed activities should be restricted to the case of local focus. Global activities are those that concern the participants of a cooperation and the shared background, while local activities concern document contents and individual tools. The information visibility can be restricted to certain parts of the common artefact to achieve the desired effect. Greenberg et al. (1996) make the same distinction by using different terms for the two focal modes: in their terminology, "informal awareness" describes general knowledge of people's location and availability, while "workspace awareness" is used for knowledge about their actions on a shared document (cf. Section 4.1). Consider the case of a report being jointly edited by a group. If certain persons were assigned to write certain chapters (e. g. by personal communication), the person responsible for a chapter certainly would like to be informed of any external changes. On the other hand, changes are much less interesting if they concern parts that others are responsible for, where only the final version will be of interest. DIVA, for example, uses the virtual office windows to display events on a global level, while events on a local level are displayed in the application windows. Another example are video connections that offer a great amount of global awareness. Several systems like Cruiser (Root, 1988), RAVE (Gaver, Moran et al., 1992), Polyscope (Borning and Travers, 1991), and Portholes (Dourish and Bly, 1992) implement media spaces in which long-time, low-resolution background video images of co-workers are distributed and can be observed passively, giving a good impression of the real-life activities of others. Additionally, perceptualization can also be suppressed for information that can easily be deduced without needing a special visualization. In this case, awareness information is conveyed implicitly, without presenting it directly. Information about others can be concluded by implicit knowledge of roles or restrictions enforced by the system (Dourish and Bellotti, 1992). For example, Heath and Luff (1996) discuss an example from health care where much information on a patient's history can be deduced implicitly by sequencing, omissions, and gestalt of his (non-computerized) medical record. Obviously, such cases appear only infrequently and are difficult to formulate as a general design principle. 5.3.5 Fidelity Instead of omitting the perceptualization of an event altogether, another spatial distortion approach is the modification of the information an event contains. Systems can choose to faithfully present other people's activities, meaning that an "exact" copy of their original 70 Perceptualization actions is shown (WYSIWIS). For example, shared feedback of mouse actions or direct video connections strive to be faithful to the original. On the other hand, it can be necessary to change or synthesize an event to show facts that would not be visible otherwise, or to arrange the information into a format that better suits users' needs. Furthermore, in many cases it is not the exact event itself that is of interest, but the tendency it shows. Several different approaches are possible. First, a system can omit minor or unimportant details of the interaction history to avoid distracting the user from the more important facts. Reducing the amount of information has two benefits: users have less information to browse, and the system has less information to transmit. For example, DIVA transforms position information for particular events to adapt the presentation to differing views of different users. The animated movement of actors is calculated based only on the start and end point; the information about the real movement path is discarded because it is useless if users have different layouts for their virtual office. In a similar way, the movement of the mouse cursor is approximated as a straight line for command animation. The Flexible Diff system (Neuwirth, Chandhok et al., 1992) merges changes that are closely located to increase readability of the change report. Second, a system can add additional steps to make things clearer, e.g. by showing a direct manipulative way of performing an operation instead of the keyboard shortcut that was used in reality. GroupDesign (Beaudouin-Lafon and Karsenty, 1992), for example, uses synthesized command animation to visualize user actions. Finally, it is perfectly possible to present completely synthetic information, i.e. that is not based on a particular event. As an example, a system could display an image of a user on the phone while he is busy. Presentation of synthetic information is clearly difficult to implement, since the system has to "guess" to some extent the intentions and actions of a user. Furthermore, there is the risk that users get misleading information about what others are doing, running contrary to the primary reason of providing awareness. The previous discussion is applicable both to synchronous and asynchronous presentation of awareness information. However, the asynchronous case offers additional possibilities. In this case, events can optionally be rearranged. They can be regrouped into a structure-oriented order that is closely related to the common artefact. For example, all modifications in a text editor can be shown in their textual order, regardless of their original sequence (rearranging of the command history). In the same way, ordering events by users focuses awareness on specific persons. These approaches are synthetic in the sense that they change the temporal order of events, not the information itself. 5.4 Presentation of Awareness Information Following information selection, the actual presentation of the information is the second and most important step of the perceptualization process. As for the selection phase, there are also Presentation of Awareness Information 71 several different aspects that have to be considered for presentation. In the following sections, we will discuss these requirements in more detail. 5.4.1 Static and Dynamic Aspects For our analysis, we distinguish between static and dynamic aspects of awareness information presentation. On one hand, static presentation is the presentation of the state of the common artefact at any given time to provide awareness information, both implicitly and explicitly. This presentation is static insofar as it remains stable as long as the artefact remains unchanged. On the other hand, a dynamic notification12 can be used to highlight the dynamics of the cooperation process. Notification is the presentation of a state change for a limited amount of time; for instance an animation or a pop-up message window. These two basic techniques are strongly related: any change in the static state presentation implies that a notification has taken place before. The intensity of the notification may vary considerably, though; it may simply consist of the undecorated presentation change. For example, the color of document icons in DIVA indicates the document status (e.g., green means "modified by others"); clearly this is a state presentation. However, the actual color change itself is a notification. Although the change is performed instantaneously, the resulting motion on the screen may still capture the user's interest. Moreover, this notification could easily be made more intensive, for example by using an animated transition or by associating it with a sound sample. In contrast, notification does not necessarily imply a subsequent change in the state presentation; it can show information that is simply not available in the state presentation. For example, if a user is notified about incoming mail by a sound clip, the state presentation remains unchanged if the mail inbox is not represented at the user interface. The aims of the two techniques are different: static presentation allows the perception of awareness information on the fly, during normal work on the common artefact. The main issue here is fast and unobtrusive information transfer while preventing information overload. Notification, in contrast, alerts users to specific activities, the main problem being the adaptation of the intensity level to ensure proper reception while preventing user disruption. Both techniques also differ regarding their design requirements. Static presentation basically requires adequate information visualization mechanisms (non-visual presentation is usually not well suited to convey static information). Many different approaches for information visualization have been proposed in literature: examples are windowing systems, hypermedia, 3D-environments, scenic interfaces, or distortion mechanisms. All these techniques have been developed to visualize a large amount of information contained in a document (e.g. large database files or geographic maps). In contrast, awareness information is meta-information that is not intrinsic to the document. Therefore, as discussed before, selection of the information to present becomes an important issue: while normally information in a computer document cannot simply be omitted or modified, this is perfectly possible for awareness information. Important design issues are the integration of the presentation into the overall interface design, 12 As usual, this term is not used uniformly in literature. Some authors (e.g., Graham et al., 1996) use the same term to denote internal system update messages used to synchronize state between replicated applications. 72 Perceptualization its metaphors and interaction techniques, and the use of spatial distortion mechanisms to adapt the information to limited screen space. In contrast, a notification is usually more complex to design than its static counterpart, because it offers more possibilities and problems due to its dynamic nature. A notification is perceivable only for a limited amount of time. Its design has to take several specific factors into account. These include particularly the choice of the presentation medium, the use of adequate temporal distortion techniques, and the transition into a static presentation. 5.4.2 Medium The impact of a perceptualization depends heavily on the selection of the presentation medium. While the human sensorial system accepts several forms of input, only two of them are actually relevant for the presentation of awareness information: visual and audio signals. Seeing and hearing are the primary distance senses (Gaver, 1991), i.e. they allow perception of events taking place at a distance. The other forms-gustatory, olfactory, and tactile information13- have a variety of associated problems making them inappropriate as a presentation medium. First, they convey only little information in comparison to optical and audio input. Second, they are generally not used for real-life cooperation as well. Finally, their use is either not supported by current computer hardware, or corresponding solutions are inadequate for perceptualization purposes. For example, tactile output devices (Braille terminals) are commonly used for visually impaired users. However, they are expensive and are less useful to attract a user's attention (Mynatt and Edwards, 1992). Since the human perceptive system is optimized for optical input, and since computers are designed to present most of their information in visual form (the latter being a consequence of the former), visualization techniques are the most important and common approach. Of course, this does not rule out that occasionally the use of audio signals can be extremely useful (Gaver, 1993), in particular because they do not require the visual attention of the user. As Brown et al. (1989) state, "the ever-increasing rate at which computers can generate information may soon make it impossible for users to absorb the flood of data being presented to their visual systems". Audio signals have the advantage that they can be perceived even if the user is not actively attending to the main focus of computer work, the screen (Gaver, 1991). Furthermore, the synchronous usage of two different output media increases user efficiency in contrast to the usage of a single (visual) medium applied to two different tasks simultaneously (Brown, Newsome et al., 1989). This gives evidence that a combination of visual and acoustic output may be extremely useful. However, it should also be noted that it is difficult to convey complex information through audio signals only, and that sound tends to be more disrupting than equivalent visual information. Therefore, all systems that are relevant for our discussion use the screen as their main perceptualization medium. However, many of them, including DIVA, use audio signals to transmit additional cues, e.g. when a person joins a conference. GroupDesign (Beaudouin- Lafon and Karsenty, 1992) additionally uses sound to notify users of events taking place in 13 The five basic senses we mention were already enumerated by Aristotle. While there are others, e.g. the sense of equilibrium, these are irrelevant for our discussion. Presentation of Awareness Information 73 parts of the artefact that are currently not visible on the screen. The EAR system (Environmental Audio Reminders, Gaver, 1991) uses stereotypic sound samples called audio icons to alert users to specific events. For example, meetings that are about to take place are signaled by a growing sound of murmuring voices. Gaver reports these sounds to be unobtrusive yet effective announcements of events in the workspace because they are non- disruptive and intuitively understandable. 5.4.3 Temporal Distortion As described before, many temporal distortion mechanisms are related to the selection of information. However, it is also relevant for information presentation. The main temporal distortion mechanism in this regard is animation. Because it is usually synthesized, its presentation actually has a longer duration than the originating action. Animation is especially well suited to convey state changes to the user because the human visual system is optimized to notify motion (Chang and Ungar, 1993). Animation is not instantaneous, it provides a sense of continuity, and can easily be integrated with the state presentation. Mackinlay et al. (1995 p. 71) point out that "animated transitions let the human perceptual system track user interface changes with much less cognitive effort" because the user's processing load is shifted from the cognitive to the perceptive system (Thomas and Calder, 1995). Since the early days of the Apple Macintosh (which pioneered the use of animation for state transitions) the use of these techniques has not increased much. One reason is that it is a lot of effort for an application programmer to implement an animation for the various state transitions. Furthermore, for self-induced changes, animation is not a drastic improvement, while for changes induced by others it is almost a necessity. Temporal distortion-like any notification mechanism-can be used as a stand-alone technique to make state changes perceivable. However, it works best if it is integrated into the background structure presentation. Therefore, the transition from the dynamic presentation into the stable state presentation has to be considered. In the stand-alone case (e.g. a sound signal), the design of a notification is completely independent from that of the state presentation. This is not the case for the integrated approach. The design of an temporal distortion mechanism in these cases has to take the overall presentation metaphors and techniques into account. 5.4.4 Spatial Distortion Spatial distortion can be used as a selection mechanism as described before. In a narrower sense (referring to screen space instead of the abstract information space), it is also a technique that addresses the "screen real estate" problem. Screen space is a very limited resource, which moreover is also needed to transmit other information that is crucial in a cooperation, in particular the contents of the common artefact. Therefore, information density on a given area has to be increased. Spatial distortion mechanisms can be used to focus user attention on specific parts of the common artefact while still providing context information, for example to highlight areas where work took place. An example for the usage of distortion to explicitly present awareness information is edit wear and read wear (Hill et al., 1992). The scrollbar of a text editor-a 74 Perceptualization representation of the whole document- is used to display change indicators. Other distortion techniques for the presentation of information are legion; they include overlapping windows, transparency, fisheye techniques, or 3D presentations, which are described in more detail below. For a more comprehensive overview see for example (Leung and Apperley, 1994). * Windows: For windowing systems, a natural approach is to open a dedicated window to display awareness information. However, this approach has the severe drawback that the information in other windows may become obscured because it is overlapped by the additional window. This can be particularly disturbing because these windows usually display the common artefact and users do not want to lose their visual connection to it. Furthermore, this approach provides no direct connection between the awareness information and the artefact contents. * Semi-transparent information layers: An extension of the windowing approach is the use of semi-transparent windows serving as an information layer (Harrison et al., 1995). This increases visibility of the artefact, at the cost of distracting users from their work. Due to its special visual appearance, the information display is easily distinguishable from the rest of the common artefact; the information layer can be regarded as a visual indicator for an information filter. By changing the degree of transparency, the display can be adapted to the current working situation of a user. For example, Genau and Kramer (1995) describe a system that uses transparent layers to display the history of an artefact. Figure 5-3. Semi-transparent layers in DIVA Figure 5-3 shows an experimental semi-transparent information layer in DIVA: the virtual office is superimposed on the application and room windows, allowing users to spot activity in the virtual office while working normally on the document. The head-up radar view described by Gutwin et al. (1996b) is based on a similar approach. A normal application window is superimposed on a miniature view of the entire document. This way, users can work on details while observing overall activities without having to move their head to Presentation of Awareness Information 75 switch between windows or displays. However, the basic problem of these approaches is also mentioned: whether people can easily separate the different layers of the display. * Fisheye views: Another solution is to use a distorted (fisheye) view (Furnas, 1986) on the common artefact. Similar to the semi-transparent information layers described before, this approach permits more information to be displayed on a given screen area as would be the case using the normal window display. Of course, there is a drawback associated with both approaches: while more information is displayed, it also becomes more difficult to consume and understand the information. The general idea of the fisheye view is to gradually decrease the amount of information that is displayed, depending on the distance from the focal point of the view. Therefore, while only the focal part of an image remains unchanged, other parts still remain visible, although heavily distorted. This has an obvious benefit for common artefacts: the parts that are of interest in a given situation are highly visible, while unfocused parts are still noticeable by the user. Peripheral vision allows users to notice actions in regions they are not focusing at, giving an idea of the overall activities at a glance. * Three-dimensional information presentation: Another popular distortion technique is the use of the third dimension to take advantage of the human capability to easily interpret 3D depth information. For example, the perspective wall (Mackinlay et al., 1991) maps a linear information structure to a detailed center panel and two perspectively distorted panels for context. Carpendale et al. (1995) discuss an approach allowing multiple focal points by underlying the original, two-dimensional information display with a three-dimensional Gaussian curve. Users can smoothly change between focus and context by manipulating the pliable 3D-surface. Cone trees (Robertson et al., 1991) render a hierarchical structure to a three-dimensional tree display. Interesting nodes can be rotated to the foreground for details, while the context remains visible in the background. While all these techniques can potentially be used to present awareness information, there are two associated problems (cf. Section 3.2.3): they require powerful hardware for the necessary calculations, and a three- dimensional awareness information display can be difficult to integrate with inherently two- dimensional working objects without breaking the basic metaphors of the system. 5.4.5 Presentation Model The presentation of awareness information has to be integrated and combined with the rest of the common artefact. It is perfectly possible to present awareness information independently from existing application data, e.g. by showing a dedicated awareness information window. However, in most cases a better approach is to integrate the additional information directly into the general presentation of the common artefact (Dourish and Bellotti, 1992). This prevents users from having to switch their attention focus between different information sources. However, this approach is only feasible if the interface allows a smooth and seamless integration of the additional information, without breaking existing metaphors. For example, user information is more easily integrated into a room metaphor (as used by DIVA) than into the standard desktop metaphor. After all, people happen to be present in rooms, while they usually do not sit on others' desks. 76 Perceptualization The choice of an adequate presentation model in particular involves the selection of appropriate metaphors. Ideally, it has to fit with the metaphors used throughout the rest of the system, while allowing users to interpret awareness information in an intuitive way. In particular, the users of the system have to be integrated into the metaphor, because they constitute an integral part of any multi-user environment. Moreover, the presentation model may also afford an overview on the system state. Gutwin et al. (1996c) not only report on the usefulness of providing an overview tool for awareness purposes, but also how increased awareness of one's own position provided by the overview turned out to be beneficial for individual work as well. 5.4.5.1 Metaphors A metaphor is a mapping from a user interface element to a similar, presumably user-known, concept14. Metaphors influence the mental model users have of a system. Not only do they influence how users perceive functionality, but also if they perceive it at all (Condon and Keuneke, 1994). Ideally, metaphors allow the transfer of knowledge and skills acquired from real-life work to the computer application. Real world should be mimicked where appropriate to allow users intuitive use of a system. Of course, the interface should deviate from this approach where the computer offers possibilities that go beyond those of the real world (Hollan and Stornetta, 1992). The standard desktop interface is a good example of this approach for single user environments: it is based on real world metaphors, yet sufficiently abstract to allow the full flexibility of computer applications. Interfaces providing awareness should follow the same approach. They must include metaphors that support the most important factors of real world cooperation. The choice of adequate metaphors is important to increase the acceptance and usefulness of the resulting system. They should support both single user and multi-user work-the interface should not change with the number of participants in a cooperation, and transitions between different modes of work should be easy and smooth. Furthermore, the metaphors should support the visualization of information in the shared workspace and the integration of asynchronous awareness information. Spatial metaphors have been successfully used in several systems such as DIVA or DIVE. Visualizing the structure of a common artefact as a spatial model has a number of advantages. It supports spatial imagination, helping the user maintain a mental model of the artefact (spatial memory). It facilitates referral in conversations ("to the left"), because people are very familiar with spatial relations. And finally, it provides overview if the model is compact. A compact spatial arrangement can be perceived as a whole and provides the necessary background for awareness about changes. 5.4.5.2 User Representation User representation is an important part of any perceptualization service. Buxton (1993) argues for the integration of user information, e.g. video images, into shared task spaces. Benford et 14 As Gaver (1995) points out, a metaphor is actually a linguistic device mapping a particular word to a different yet similar meaning. Therefore, applying the term "metaphor" to a user interface element is a metaphor in itself. Presentation of Awareness Information 77 al. (1995) use the term "user embodiment", referring to the provision of a virtual body, for the representation of users in cooperative environments: "The inhabitants of collaborative virtual environments (and other kinds of collaborative systems) ought to be directly visible to themselves and to others through a process of direct and sufficiently rich embodiment" (p. 242). They provide a framework discussing important factors for user representation at the user interface, including aspects of presence and availability, location, identity, activity and history of activity, voluntary and involuntary non-verbal expressions, and truthfulness. Most of these design aspects relate directly to the provision of awareness information. Showing a visual actor performing a user's tasks allows others to spot easily who is working where and what they are doing exactly. In DIVA, every user is represented by an icon displaying his image and name. Additionally, users are associated with colors, and these colors are used in the animation of commands invoked by the corresponding user. Finally, temporary flashing lines connect the live video image of a user with the cursor position during command execution, providing an additional link between actors and actions. Media spaces use live video images as actors. DIVE supports a flexible form of user representation, allowing users to design their own 3D-actor using a geometry description language (Benford, Bowers et al., 1995). Far more complex models are possible and needed to convey information about a user while at the same time visualizing the user's actions. As an example, little animated persons that can be identified with users could be shown moving about the document and performing actions related to the commands their associated user is issuing. If the user is typing text in a word processor, the related actor would walk to the corresponding paragraph and insert the letters as necessary, therefore showing who is doing what and where. Furthermore, by clicking on this synthetic person, further information about the user could be given, or the reason behind a certain command could be determined (e.g. by establishing a video conference to that person). Ideally, the actor representing a user would be synthesized from his live video image, therefore conveying additional information about his real-life activities. This could make explicit video connections unnecessary because the relevant information about cooperation partners is transmitted during the actual cooperation. The actor representation can also be used to signal the importance of an event for a user, for example by displaying the associated actor in different sizes. For events considered to be unimportant, the actor could be invisibly small; only the changes to the document state could be noted. For extremely important events, the image of the actor could be enlarged, therefore visualizing the importance of the event and drawing attention to it. Additionally, a large image makes interaction with the associated user easier, which might be intended for a particular important change. Certain system services could be visualized in the same way, e.g. software agents performing a user specified task. This provides a consistent user interface, and furthermore blurs the differences between human co-workers and system components, which might be an interesting (though potentially dangerous) effect. 78 Perceptualization 5.4.6 Interaction Users may have to interact with the information presentation for several reasons. First, they must have the possibility to reset it, i.e. to acknowledge the perception of the information. Second, it can be useful to modify the standard behavior of the presentation. For example, a user may choose that a particular information should remain visible for a specified amount of time, or should reappear after some time interval. This allows users to establish remainders for specific events. Finally, users should also be able to modify the displayed information to meet their needs. This can be used for various purposes: users can tone down a presentation, and they can also construct their own notification to alert themselves to specific facts later. While awareness information can be collected and presented passively without any user intervention, special interaction techniques have to be provided for these complex operations. Note, however, that these special techniques are not absolutely necessary: a presentation can automatically be reset after a time threshold, or if the standard selection mechanism is used on the effected object. A related question is how the presentation of awareness information is started. User invocation of this presentation can also be divided into passive and active forms. In the active case, users have to take an explicit action to receive the information; e.g. by opening an annotation window. In the passive case, information is displayed in the background without any user interaction. The active approach has the benefit that it allows users to explicitly specify the type of information they are interested in. It is particularly important for asynchronous awareness, because it is difficult for a system to deduce the moment a user wants to be informed on the past activities of others (note, however, that it is possible: an example would be an automatic catch-up facility after opening a document). A drawback of the active approach is that users have to invest work to initiate a presentation. In contrast, a constant stream of information is presented without explicit invocation in the passive case. A benefit of this approach is that users' work is minimized since there is no need for intervention. However, the selection which information to present is impossible this way. Combinations of both approaches are possible as well: for example, the details of information to be presented continuously could be selected actively. We discussed several forms of presentation with different characteristics and different impact on the user before. Systems should provide a variety of presentation mechanisms to support different levels of presentation intensity. Mechanisms that are less intrusive also increase the possibility that the user simply misses an information (Figure 5-4). Therefore, user reception of a presentation is an important issue. Reception can again be divided into passive and active forms. In the active case, users have to take an explicit action to consume the information; e.g. by opening an annotation window, or by acknowledging the information by pressing a button in a modal dialog box. Design Recommendations 79 uptionisr er dus modal dialog box non-modal window background animation background status indication no notification ive reception active pass possibility of perception Figure 5-4. Perception vs. disruption In the passive case, the information is displayed on the screen without user intervention; users are free to consume or ignore it. State presentation is always passive, while notification can take both forms. The passive approach offers some advantages: systems can provide a constant stream of information, and users can perceive the information using peripheral vision, without being unnecessarily disrupted from their work. Peripheral vision is a feature of the human optical system. High resolution, detailed vision is provided by a small area of the eye (the fovea), while the surrounding regions provide lower resolution (see for example Anderson, 1994). The former is used for focused viewing, while the latter provides stimuli (e.g., motion) to redirect attention and focus (Yamaashi, Cooperstock et al., 1996). Therefore, the optical system is optimized to notify changes in the periphery that are not actively attended to. Of course, there are cases where the active approach is preferable, in particular to transport information that others should note in any case, regardless of whether they are looking at the screen at a certain moment. 5.5 Design Recommendations We have discussed different aspects that have to be considered to support the perceptualization process in the previous sections. Each of these aspects has to be considered carefully for the design of systems supporting awareness. Failure of doing so may result in inadequate perceptualization mechanisms, leading to inappropriate awareness support, ineffective cooperation, and user dissatisfaction. 80 Perceptualization Aspect Design Recommendation Origin Extensive support for passively collected information Means to create awareness information actively Time Support for asynchronous presentation For applications supporting synchronous work and to support informal communication: support for synchronous presentation Relevance Support for both user-defined and automatic forms of determining information relevance Visibility Suppression of unnecessary information Fidelity Aggregation of related events Medium Primary use of visual cues, use of audio cues as secondary medium Temporal Distortion Use of information recording and replay Use of animation Spatial Distortion Use of distortion technique to provide overview on workspace Integration Consistent use of metaphors and interaction techniques Representation Explicit user representation Invocation Support both for active and passive forms of information retrieval Reception Extensive support for passive presentation Means to ensure information reception Table 5-2. Design recommendations for a perceptualization service For each of the topics covered by the framework, we have discussed potential benefits and drawbacks, possible approaches, and design solutions. We also described how these aspects may be covered by systems to provide adequate awareness support. Table 5-2 summarizes these design recommendations. Note that it is not sensible to give more detailed instructions on the implementation of perceptualization mechanisms. Rather, their concrete realization depends on various external factors, like the application domain, the hard- and software environment, and the intended functionality of the groupware system. Therefore, we only provide a set of high-level design recommendations applying to all cases. In summary, there a few essential factors that an adequate design of an awareness and perceptualization service should consider. First, the passive forms of generating and consuming information should be prevalent. This ensures availability of information and minimizes user disruption. However, a simple mechanism to actively generate or acknowledge information should be provided as well, because the passive approaches do not cover all relevant cases. In the same way, users should be able to define their interest in specific events actively, while the system should also support a mechanism to adapt presentation intensity automatically. Distortion, both temporal and spatial, should be applied as a means to structure and rearrange information. Finally, the presentation of awareness information should be integrated with the metaphors and interface mechanisms of the rest of the system, including in particular a form of user representation. Observance of these simple rules leads to effective support of user awareness in CSCW systems and thereby increases cooperation quality. Conclusions 81 5.6 Conclusions The design of user interfaces supporting awareness is a difficult task. The basic interface concept in this respect is the perceptualization of awareness information. Perceptualization consists of two indispensable steps: selection and presentation. The selection phase is concerned with choosing the information to present in a given situation, while the presentation phase actually shows this information. Several aspects have to be considered carefully to design systems supporting proper perceptualization. These include information origin, time, relevance, visibility, and fidelity for the selection phase. For the presentation, static and dynamic aspects, information medium, the presentation model including metaphors and user representation, and interaction with the presentation have to considered. Moreover, distortion is a key concept for perceptualization: applied to time, it supports asynchronous presentation of awareness information; applied to space, it supports overview and peripheral vision. This framework of perceptualization design aspects can be used both to analyze existing systems and to design new ones. The systematic discussion of these different aspects, and their embedding in a common context greatly facilitates the task of analyzing or developing awareness services. Not only any single aspect, but also their combination is of importance and has to be considered carefully. In the next two chapters, we will demonstrate both the analytical and the constructive possibilities of the framework. . 6 Application of the Framework "In general, CSCW systems need to convey an indication of their social world. User interfaces for groupware or CSCW must therefore convey this social information [...]. While many CSCW systems are partially aware of this requirement, [...] the need to reflect general activity is less understood." M. S. Ackerman & B. Starr In this chapter, we will use the framework developed in the previous chapters to analyze a variety of systems supporting awareness. The systems have been chosen for their diversity. They illustrate the use of the different general interface concepts described in Chapter 3. We will examine four different systems. DIVA will be used as an example of the WIMP approach 84 Application of the Framework and the popular two-dimensional spatial metaphor. LinkWorksTM, while based on a similar approach, exemplifies a commercially available groupware product. The BSCW system serves as an illustration of the WWW approach, while DIVE is an example of a virtual reality system. We have discussed theoretical aspects of these different approaches before. Evaluation by the framework can provide practical confirmation of these theoretical results. In addition to the four CSCW systems listed above, we will actually discuss a fifth approach: face-to-face cooperation. While the framework was designed to analyze computer systems, applying it to "real" cooperation nevertheless produces interesting results. 6.1 Face-to-Face Cooperation The framework developed in the preceding chapters was not designed to analyze awareness in non computer-supported cooperation. However, doing so nevertheless results in some highly interesting insights on the shortcomings of face-to-face cooperation. We agree with Hollan and Stornetta (1992): simply imitating real life is not enough for computer applications. Given the choice, users will always prefer "the real thing". Therefore, to be successful, computer-support has to go beyond the capabilities of real-life. For computer- supported cooperative work in general, it does so already by bridging space, time, and social constraints. However, the same argument is equally valid for awareness support: systems should go beyond the level of awareness that is present and perpetuated in real-life cooperation. This is the real strength of computer-supported cooperative work: allowing users to do and see things that they would be unable to do or see in real life. Aspect Support Origin Passive: Multitude of subtle cues Active: explicit verbal communication combined with deictic object references Time Synchronous only Relevance - Visibility Global and local focus Fidelity - Medium All media used effectively Temporal Distortion - Spatial Distortion - Integration n/a15 Representation n/a Invocation n/a Reception Passive: Background activity can be monitored peripherally and overheard Active: Communication protocol can be used to ensure reception of a message Table 6-1. Perceptualization in face-to-face cooperation 15 The corresponding category is not applicable. DIVA 85 Applying the framework to real-life cooperation therefore reveals aspects where computer support for awareness can excel even beyond the capabilities of face-to-face cooperation. It also shows where awareness about others' activities is lacking in such cooperation forms (Table 6-1). In face-to-face cooperation, one main element of the awareness information pipeline is missing: the persistent storage of events. This reveals the first major benefit of computer support for awareness: its storage and retrieval capacities. Note that the other elements are present. In particular, the different privacy and interest filters, while not identifiable as separate entities, still exist in the form of subtle mechanisms (closing a door, overhearing a conversation, etc.) that are unavailable on the computer. The lack of persistent storage leads to another shortcoming: temporal and spatial distortion is unavailable. It is impossible to replay information asynchronously. Consequently, it also impossible to modify, aggregate, or synthesize information. This discussion is not to suggest, however, that awareness in face-to-face cooperation is highly deficient. In fact, it excels in all other aspects of the framework. Active and passive forms of information generation and reception are fully available. All information media are effectively used. Metaphors are not even needed, and users are excellently represented in the workspace (namely by themselves). 6.2 DIVA We have described the features of DIVA throughout this thesis. Nevertheless, application of the framework reveals some aspects that have not been discussed. We will not reiterate the different mechanisms that DIVA offers to support awareness, nor will we discuss how they fit into the framework. This has been done in the previous chapters. We did not discuss, however, the shortcomings of DIVA regarding awareness support. Privacy and global configuration filters are not supported at all. These aspects were deliberately neglected because they were not research goals of the project. The interest model, based on coupling modes of shared applications and window layout, is simple, yet sufficient for its intended purpose. Perceptualization, while adequate in most respects, is also lacking in some areas. Aspect Support Origin Passive: user virtual location and movement; command invocation and execution Active: notes on objects Time Synchronous: user virtual location and movement; command invocation and execution Asynchronous: Animated and navigable document history Relevance Selectable coupling modes Visibility Based on window layout; global and local focus Fidelity - Medium Mainly visual; audio used sparingly 86 Application of the Framework Temporal Distortion Animated command feedback and animated history Spatial Distortion - Integration Extension of standard desktop metaphor Representation Users: icons, colors, video images with implicit pointing capability Invocation Passive only Reception Passive: Background activity can be monitored peripherally Active: - Table 6-2. Perceptualization in DIVA Table 6-2 summarizes this aspect of DIVA. It also highlights two shortcomings: first, DIVA does not support any form of spatial distortion. This results in a limited overview of the working environment. Second, there is no way to ensure that an important awareness information has actually received its recipient. A possible solution for the first problem, transparent layers, has been discussed in Section 5.4.4. The second problem could be addressed by introducing a special form of high-priority notes that automatically pop up on the screens of all users sharing the related object. 6.3 LinkWorks LinkWorksTM (Digital Equipment Corporation, 1995) is a groupware product from Digital. It is interesting for several reasons. First, in contrast to the other systems we discuss, it is a commercially available product. Second, it is the base system for the POLITeam project that will be discussed in detail in the next chapter. Third, its support for awareness is remarkably underdeveloped. LinkWorks is a client/server system. Documents are kept on a central server and can be retrieved and edited using local clients. These clients closely resemble the standard graphical user interface desktop. Additionally, the system supports document versioning, email, and workflow management. For awareness purposes, users can register interest in specific objects, and are alerted to changes to the object by means of a modeless16 pop-up dialog box showing a textual description of the event. The same dialog can also be invoked by the user to display an objects' past history. Figure 6-1 shows a typical LinkWorks desktop in combination with the event dialog. The only other form of awareness support is a simple dialog box displaying a list of currently logged in users. LinkWorks awareness support is very rudimentary and insufficient. There is no notion of privacy and global awareness configuration. However, this is not much of a problem because of the very limited and not very detailed amount of awareness information that is available in the system. The interest model is also very simple, allowing either all or nor events regarding a specific object to be reported. Event aggregation or modification is not supported. 16 Ironically, this dialog box is designed in a way that most users do not perceive it as being modeless. They rather think of it as being a modal dialog. This error has been perpetuated by literature discussing the LinkWorks system (e.g, Klöckner, Mambrey et al., 1995; Rauschenbach, 1995). LinkWorks 87 Figure 6-1. The LinkWorks system Perceptualization is also highly limited (Table 6-3). Only one notification mechanism is available, which moreover is highly distracting, occupies a fairly large amount of screen space, does not allow peripheral perception, has to be acknowledged actively, and provides neither a direct connection to the affected objects nor an adequate representation of the user involved. Aspect Support Origin Passive: Document-related activities Active: - Time Synchronous: Pop-up event dialog Asynchronous: Event record Relevance Interest on individual objects Visibility - Fidelity - Medium Visual Temporal Distortion Event record Spatial Distortion - Integration Extension of standard desktop metaphor Representation - Invocation Passive and active (event log) Reception Passive: - Active: Pop-up event dialog Table 6-3. Perceptualization in LinkWorks 88 Application of the Framework These problems are alleviated somewhat by the fact that LinkWorks is best suited to support asynchronous work, were some of these missing features are not strictly necessary. However, the missing object link and user representation are hindrances for the effective usage of the event history as well. In Chapter 7, we will describe in detail how the LinkWorks system can be augmented to provide adequate awareness support. 6.4 BSCW The BSCW17 Shared Workspace system (Bentley, Appelt et al., 1997a; Bentley, Horstmann et al., 1997b) is an interesting candidate for examination by the framework for two reasons. First, it is based on the increasingly popular WWW protocol, which, while having many drawbacks and limitations, is the path for many future user interface developments (cf. Section 3.2.2). Second, one aspect of the system's design was to enable users to "obtain information on the previous activities of other users to coordinate their own work", i.e. to support awareness. The BSCW system supports cooperation of users through shared workspaces. Workspaces are accessible by selected users that can up- and download documents and work on them. Document versioning, change indication, and threaded discussions are supported as well. The system is based on the WWW protocol. Workspaces can be accessed by using any WWW browser, documents are edited by opening a corresponding helper application. This way, the interface is restricted to the options common to all WWW browsers. On the other hand, this approach ensures usability of the system on a wide variety of hard- and software platforms. The system is publicly available, and more than 1500 registered users have worked with it on different servers. This way, the current version of the system has been informed by the feedback of people that use it to accomplish real cooperative work. From the seven components of the awareness information pipeline, neither of the three filters is supported. This may result in acceptance problems for larger organizations or more inhomogeneous groups. In fact, the designers incorporated a more detailed access control model in later versions of the system because users reported to have problems with the flat model allowing all members of a workspace access to all its objects. In the same way, a more elaborate mechanism might also be necessary for the distribution of awareness information. On the privacy side, users are not able to suppress any events other than removing an object from the workspace to work on it privately (obviously, this action would be logged too). On the other hand, users cannot specify individual interest in specific objects as well: events are reported for all objects in the workspace; the only option is for users to suppress the presentation at the user interface. The designers of the system apparently recognized this shortcoming: for future versions the event mechanism is to be extended by supporting "registered user interests" (Bentley, Appelt et al., 1997a). 17 Basic Support for Cooperative Work. BSCW 89 Figure 6-2. The BSCW web-browser based interface18 Presentation of the awareness information is necessarily based on the possibilities of the HTML language. The output medium is the screen only. The organizing metaphor is the shared workspace. Objects contained in the workspace are displayed list-wise (Figure 6-2). Object- related events are grouped by categories; an icon is assigned to each category and is displayed besides an object's icon to indicate that one or more events of that type occurred since the last catch-up of the user. Selecting an event icon displays a detailed list of all events of that type relating to the object. Catch-up is triggered by a corresponding button, it may be performed either for single objects or complete folder hierarchies. While users are represented as icons, this representation is not integrated with the event display, where users are represented by their name only. Spatial distortion is not supported for awareness purposes. There is no way to ensure the reception of an event, though the designers plan to implement a corresponding service in future versions by sending notifications by email. 18 Screendump from (Bentley, Appelt et al., 1997a). 90 Application of the Framework Aspect Support Origin Passive: Workspace document related activities Active: - Time Synchronous: - Asynchronous: Event record Relevance - Visibility Based on visible workspaces Fidelity - Medium Visual Temporal Distortion Event record Spatial Distortion - Integration WWW-Browser with helper applications Representation Users: textual representation with hyperlink functionality Invocation Passive only Reception Passive: Past activity can be observed Active: - Table 6-4. Perceptualization in the BSCW system The shortcomings of the BSCW awareness service very much reflect the shortcomings of its WWW background (cf. Table 6-4). Active entering of information, sound support, specialized animation, or synchronous reaction to events are all difficult to implement in this medium and are therefore not supported. 6.5 DIVE DIVE19 (Fahlén, Brown et al., 1993; Benford, Bowers et al., 1994; Benford, Bowers et al., 1995) is a CSCW system employing a virtual reality approach. The cooperative environment, user, tools, and work objects are modeled as 3D objects. The system is based on a strong spatial metaphor: objects are located in space, and interaction between them depends on their spatial relation. This is also true for the awareness model of the system. Each object is equipped with an aura, a focus, and a nimbus. Each of this subobjects defines an invisible subspace that is used to calculate awareness levels between objects. If the auras of two objects overlap, the level of awareness between them (i.e., the amount of awareness information that is presented) is calculated as a function of the objects foci (representing attention) and nimbi (representing presence). This model not only mimics real-world mechanisms of attention and presence, but also allows interesting extensions. For example, the form of the different subobjects may be chosen arbitrarily to allow for special effects, or amplifiers may be used to boost presence or attention of users. Like DIVA, but in contrast to the other approaches discussed in this chapter, DIVE is a pure research prototype. Moreover, it is still in development. Therefore, our discussion is based mainly on its general concepts and less on concrete interaction techniques. Also, due to its prototypical nature, privacy and global awareness filtering are not supported at all. 19 Distributed Interactive Virtual Environment. Conclusions 91 Aspect Support Origin Passive: user virtual location and movement Active: virtual gestures and body language20 Time Synchronous: user virtual location and movement Asynchronous: - Relevance Aura, focus, nimbus modeled as 3D spaces define awareness levels Visibility Based on aura model: information is visible if object auras overlap Fidelity Based on aura model: fidelity is based on function of objects' focus and nimbus Medium Visual and aural Temporal Distortion - Spatial Distortion - Integration Spatial, virtual reality metaphor; no integration with standard applications Representation Users: 3D body representation Invocation Passive only Reception Passive: Background activity can be monitored peripherally and overheared Active: - Table 6-5. Perceptualization in DIVE DIVE reproduces mainly the same drawbacks regarding awareness support that are present in non-computerized cooperation (see Table 6-5). This is not very surprising since it is modeled after this form of cooperation. In fact, it may be seen as an indication that its awareness model based on auras, foci, and nimbi succeeded in capturing the essentials of face-to-face cooperation. There is no support for asynchronous awareness, nor for temporal or spatial distortion. Possibilities for active generation of awareness information, as well as to ensure perception, are limited. However, since the system is actually computer-based, these services could be integrated into the system. Doing so would increase the potential of the system, from an application to support meetings and simple synchronous work to a system supporting the full spectrum of cooperation. Additionally, DIVE shares a problem of all virtual reality systems: it is difficult to integrate standard applications without breaking the metaphor. 6.6 Conclusions If applied to existing CSCW systems, the framework developed in the previous chapters reveals strengths and weaknesses of their awareness support, and may be used to indicate possible areas of improvement. Using this framework to analyze several groupware systems provides interesting insights into the benefits and drawbacks of different interface approaches as well as into the general problems of awareness support of typical CSCW systems. Moreover, applying the same framework to real-life cooperation shows where computer support can go beyond the possibilities available to groups cooperating without computer support. 20 Note the contrast to real body language, which is generated unvoluntarily and hence passively. 92 Application of the Framework Application of the framework to systems employing different interface approaches shows the validity of the theoretical discussion in the previous chapters. All approaches have their own idiosyncratic problems. However, the framework also reveals where and how the awareness service of a system could be improved. Simple changes and additions to the offered perceptualization mechanisms can add greatly to the awareness-supporting capabilities of a system, thereby also increasing its overall value to support cooperation. In the next chapter, we will show how the framework can be applied in a constructive rather than an analytic way as well. 7 The POLITeam Awareness Service "Things don't get much more `real-world' than the German Federal Government." Anonymous ECSCW'95 paper reviewer In the preceding chapters, we presented a framework developing the different aspects that have to be taken into account to design systems supporting awareness. In this chapter, we discuss design, implementation, and evaluation of the POLITeam awareness service as an application of these design requirements in a real-world setting. The POLITeam project is a research effort aimed at designing and introducing a groupware system into a German federal ministry to support the distributed government. Dedicated support for user awareness is a fundamental goal of the project. POLITeam is based on a participatory design approach, involving end-users in the design of the system from the very beginning. This approach allows investigation of user requirements in the application field, as well as evaluation of prototypical implementations 94 The POLITeam Awareness Service under real work conditions. This chapter is structured as follows: first, we describe the goals, the design approach, the application domain, and the base system of the POLITeam project. This discussion serves as background for the description of the POLITeam awareness facilities. Details on this awareness service form the central topic of this chapter. We discuss its general design goals, specific user requirements expressed by our pilot users, and design decisions resulting from a constructive application of the perceptualization framework. This is followed by a description of the actual realization of the awareness service, the POLITeam awareness client, discussing its user interface, implementation, and evaluation. We conclude with the description of some alternative interface implementations developed during the course of the project, including a virtual reality and a web-based approach. 7.1 The POLITeam System The POLITeam project was launched as a consequence of the decision of the German parliament to move the federal capital from Bonn to Berlin. Since not all federal agencies and ministries will move to Berlin, the government will be distributed between the new and the old capital. As a result, the German ministry for education, science, research, and technology initiated the POLIKOM research program (Hoschka et al., 1993), aiming at the development of the necessary telecooperation infrastructure and tools. POLITeam (Klöckner, Mambrey et al., 1995; Sohlenkamp et al., 1995) is one of the four projects embedded in the POLIKOM context. 7.1.1 Project Goals The POLITeam system is developed by a consortium consisting of an industrial partner (VW- Gedas) and research institutes (GMD and the University of Bonn) together with selected pilot users, which have been integrated into the design process from the very beginning. They consist of the German Federal Ministry of Family Affairs, Elderly People, Women, and Youth, the Ministry of Justice and Federal Affairs of the State of Mecklenburg-Western Pommerania, and the car manufacturer AUDI AG as an industrial application partner. The ministries are mainly interested in the support of administrative office work, while AUDI aims at the improvement of simultaneous engineering in distributed project teams. The main goal of POLITeam is the development and the introduction of a system supporting cooperation in large, geographically distributed organizations. In particular, workflows in administrative and industrial settings are to be supported, based on the metaphor of an electronic circulation folder. Additionally, shared document and task processing is to be supported by use of the metaphor of a shared electronic workspace. Both components are augmented by an event and notification service which allows users to become aware of the cooperative environment. Highly structured and bureaucratic organizations like public administration, by their very nature, are reluctant to technological changes (Shapiro and Traunmüller, 1993). Therefore, the basic approach of POLITeam is to support existing working processes instead of substituting them by new ones. The POLITeam System 95 7.1.2 Design Approach The POLITeam development strategy is based on a cyclic, user-centered (Floyd and Keil, 1983; Kyng, 1991; Kyng, 1994) design approach. Some basic methodological development ideas structure the development process. The constructive design philosophy includes a set of activities, methods, and tools characterized as follows: * Evaluation criteria of the system are its usage in existing organizations, how it assists users in their tasks, and how it helps users to meet their requirements for organizational goals and working life. * We apply an evolutionary system design cycle, in which it is easier to implement changes than in a structured top-down design approach. * We reshape existing functionality, and create new functionality, by intensive end-user involvement. The users are the experts of their group work. We apply interactive methods such as workshops, meetings, and group discussions during the whole development process, instead of a one-time theoretical requirement analysis at the beginning of the process. * Methods and tools that we use consider the users as partners and not research objects. The methods and tools must be transparent for the users and approved by them. * We design the cooperative development process as a mutual learning process for users and developers to exchange experiences of design and work practice, and to enhance people's cognitive access to the changes. * We integrate `user advocates' into the design process to integrate existing and anticipated future user requirements. We define our approach as cooperative because of the strong interaction with the users. Cooperative in our sense means that users, designers, and those members of the project's support team who act as user advocates are strongly interacting in the design process. By this, we want to integrate different perspectives into the design, e.g. existing user requirements, future user requirements, organizational requirements, and technological options. Moreover, this allows conciliation of the different perspectives on system design of the members of the interdisciplinary project team themselves (Mambrey et al., 1996), consisting of computer scientists, sociologists, and psychologists. Base System: Final POLITeam LinkWorks User/Designer Version Interaction De R s e i de gn si & e & tion gn Us ua Eval Figure 7-1. The cyclic model of cooperative evolutionary system design 96 The POLITeam Awareness Service The design approach is evolutionary as well, because it enables stepwise modification and development. The development process starts with an existing system with a sufficient basic functionality that is installed at the users workplace. Requirements are determined by means of the practical experiences and theoretical knowledge gained by using the system. The strategy of the project follows the cyclic model of cooperative evolutionary system design shown in Figure 7-1. 7.1.3 The Application Domain The requirements and experiences we report were gathered mainly with our pilot partners in the federal ministry. This is also where the evaluation field test took place. Therefore, if not noted otherwise, all explicit user quotes and reports are related to this application domain. However, data collected with the other pilot partners was considered for the general discussion as well. To judge user demands, requirements, observations, and remarks, it is necessary to have a basic understanding of the typical ministerial work processes to be supported by POLITeam. Two ministerial work units and the central writing office are equipped with the system. At the time of writing, this amounted to approximately 15 users working actively with the system, distributed over two floors of the ministries' headquarters located in Bonn. Additionally, two users are located in the Berlin branch of the ministry. The main tasks of the units are answering citizens' requests, budget planing, and doing tasks for the Minister, such as collaborative speech writing. Higher hierarchical levels are equipped with the system as well, including the head of the sub-department and the head of the department. The flow of documents in the ministry is highly regulated, based on explicit rules formulated in the GGO21 long before the introduction of computers or other electronic equipment. Fax or even telephones are not covered by these rules as well. They are handled as analogies to the existing prescriptions. The same approach is also feasible for computer support of ministerial work. Figure 7-2 shows the typical steps of a ministerial work process without groupware support. Throughout this process, all document transport within the ministry is performed by messengers circulating the office at regular intervals. All incoming mail concerning a specific department is collected in a special folder which is forwarded to the head of that department. He scans the documents, decides which unit should be in charge of it, and writes routing instructions and additional information on it. This process is repeated by the head of the appropriate sub-department. Everyone writing comments on a document does so using a special color defined by his role (e.g., green for the minister, red for the head of the department, brown for the head of the sub-department, and so on). Even people with the same role, using the same color, can sometimes by identified by the type of pen they use. The sub-department forwards the folder to the registry, where the documents are transformed into work processes: each is put in a circulation folder with appropriate routing information and is assigned a unique file code. 21 "Gemeinsame Geschäftsordnung der Ministerien", translating roughly to "joint set of office procedures for ministries", (Bundesminister des Inneren, 1974; cf. also Mambrey and Robinson, 1994). The POLITeam System 97 0DLO#,Q 0DLO#2XW# 'HSDUWPHQW 6XEGHSDUWPHQW POLI T Registry eam Su 8QLW Sha r p ed W port orks pac :ULWLQJ#2IILFH es Figure 7-2. A ministerial work process The circulation folders are sent to the head of the assigned unit. The unit leader assigns a responsible unit member that performs the actual work implied by the document. The task may involve cooperation with the unit leader or colleagues, which may be performed by communicating directly or using the telephone, by exchanging physical documents, or by forwarding the whole circulation folder. If the task involves document production, the text is drafted, e.g. by handwriting or by using a dictaphone, and forwarded to the central writing office where it is typeset. Several iterations between the unit member and the writing office may be necessary until the text has its final form. This may take considerable time caused by transport delays. Upon completion of the task, the whole process is reversed: the processed circulation folder is forwarded to the unit leader for approval, followed by the head of the sub-department and the head of the department. If the superiors do not agree with a document, this may result in another iteration loop. After final approval, a corresponding outgoing mail is produced and sent on its way. This (slightly simplified) description reveals great potential for computer support. In particular, transport times can be reduced. As discussed before, POLITeam offers two basic mechanisms to support these processes. Electronic circulation folders are the electronic equivalents of their paper counterparts. They support document flow between the different hierarchical levels. Shared workspaces allow the flexible sharing and exchange of documents. This is particularly useful on an inter-unit level, or for the cooperation between the unit and the writing office. Experiences with the system showed that usage of electronic circulation folders was limited, partly because the upper levels of the ministerial hierarchy were not included as pilot users from the beginning of the project, and partly because shared workspaces proved to be the more flexible and versatile tool. Shared workspaces are also more interesting from an awareness 98 The POLITeam Awareness Service point of view: the routing of a circulation folder usually implies that work on it is finished for that station and that there is no further interest on it. 7.1.4 The Base System The POLITeam design approach is based on the continuous, cyclic improvement of an existing groupware system. Therefore, an appropriate base platform had to be selected at the beginning of the project. This base system had to fulfill several basic requirements (Navarro et al., 1993): * Availability: The system had to be commercially available to guarantee a certain level of maturity (i.e., no research prototypes with limited functionality) and to ensure support for our pilot users even after the end of the project. * Functionality: The system had to provide sufficient base functionality to support our main design metaphors at least in a rudimentary way. * Flexibility: A wide range of different hardware and software platforms had to be supported by the base system because we could not expect our pilot users to change their existing hardware and standard applications-i.e., the way they work with computers-to be able to use POLITeam. * Extendibility: A very important requirement was that the system had to be extendible to allow the implementation of new functions and the modification and configuration of existing functionality. Based on these requirements, we chose LinkWorks (cf. Section 6.3) as our base system. LinkWorks is an object-oriented, client/server based groupware product developed by Digital. It is available for a wide variety of different hardware and software platforms. It allows the integration of any application running on these platforms. LinkWorks functionality can be configured to users' needs using a graphical administration interface. Additionally, it is possible to add new functionality using the APO interface (Applications Plus Objects), which allows to access the internal data structures of the system programmatically. The user interface of LinkWorks is object-oriented as well. It is based on the standard desktop metaphor. After logging in, every user is presented a personal desk. Hierarchical structuring of objects is supported by different types of container objects like cabinets, drawers, or folders. Special groupware functionality includes email support, workflow coordination, and provisions for sharing objects between several users. The workflow component allows the specification of arbitrary workflow paths which can be attached to any object in the system. Figure 7-3 shows a typical desk which is already configured for POLITeam. The two small windows show an opened circulation folder (to the right) and the corresponding workflow prescription (to the left). Object sharing allows work groups to access a common set of documents. While the system prevents simultaneous write access, reading of a document is possible anytime. Design Goals 99 Figure 7-3. An initial POLITeam desk Regarding awareness, LinkWorks provides only very rudimentary support (cf. Section 6.3). To become aware of changes in the working environment, users can register interest in specific objects by selecting them with the mouse and choosing the appropriate menu entry. This ensures that they get informed about all changes to that object by means of a dialog box displaying a textual description of the event. A global event log can opened asynchronously to redisplay all messages generated by this service. There is no further awareness support: no variety of notification mechanisms, no user representation, no event aggregation, no possibility to observe activities peripherally. However, even this very basic form of awareness support is far better than no support at all. The very first version of POLITeam installed in the ministry-practically pure LinkWorks with a few configuration changes-had this service disabled, because it was anticipated that users would have problems with possible privacy violations. However, it was re-introduced in the next system version, because users explicitly demanded awareness support (cf. Section 7.3). This change was greatly welcomed by users, who made extensive use of this feature. 7.2 Design Goals POLITeam pursued several design goals simultaneously. On the one hand, the project aimed at the development of a groupware system supporting mainly asynchronous cooperation in large, distributed organizations. On the other hand, strategies to involve end-users in the system design were to be employed and evaluated. An important issue was to ensure flexibility: the system should form a flexible medium for cooperation, instead of prescribing explicit collaboration mechanisms (Bentley and Dourish, 1995). An event and notification service was an integral part of the system from the very beginning to realize this goal. The project plan listed the following requirements for this service: 100 The POLITeam Awareness Service * Ergonomic user interface: Awareness information should be presented unobtrusively. The need to actively request awareness information should be minimized. * Individual configuration: To avoid information overload, users should be able to select which events are of interest to them. * Individual history: Past events should be recorded and available for retrieval. * Active information service: Users should be able to actively request awareness information if necessary * Access rights: Not all awareness information should be available to all users. Availability should depend on individual access rights. * Communication availability: The availability of other users for communication should be presented. * Transparency: Users should be able to identify inefficient work practices by observing work processes through the awareness service. In addition to these functional goals, user interface design of the awareness service was driven by another source: analogous to the design rationale of DIVA discussed in Chapter 2, existing skills and knowledge of users acquired in working with standard applications should be utilized. Even more than for DIVA, this was a highly important aspect. POLITeam was not installed into a hardware and software void. Pilot users worked with computers before, and continued using the same applications after the introduction of POLITeam. Therefore, not only the transfer of the skills was an issue, but also the consistent usage of interaction techniques across the various applications comprising the system. 7.3 Constructive Application of the Framework The awareness information pipeline model and the perceptualization framework developed in the preceding chapters were used as constructive guidelines in the design of the POLITeam awareness service. The former resulted in the integration of a sophisticated event distribution mechanism based on awareness profiles defined by working situations (cf. Section 7.5.7). This mechanism provides the individual interest filters suggested by the awareness pipeline model. It could easily be extended to incorporate privacy and global configuration filters as well, although the actual implementation only realizes them in a simplified way due to time constraints. The perceptualization framework was consulted regarding design recommendations for a system supporting mainly asynchronous work, running on low-end hardware with no sound support (cf. Section 7.5.1). This resulted in the following design decisions: * Wherever possible, awareness information should be collected and distributed passively, without user intervention. Nevertheless, a means to explicitly provide object-related awareness information should be integrated as well. User Requirements 101 * The relevance of an event for a user in a given situation should be definable a priori. Additionally, a simple mechanism to automatically estimate relevance should also be available. * Event presentation should be aggregated to suppress unnecessary information. * The screen should be used as sole presentation medium. * Spatial distortion should be available to provide overview, temporal distortion for information replay. * The presentation should be integrated with the desktop interface metaphor used in the system, supporting some form of user representation. * Passive background presentation should be prevalent, but a mechanism to ensure reception of an event should also be included. This set of design goals extracted from the perceptualization framework served as the basic guideline for the implementation of the user interface of the POLITeam awareness service. 7.4 User Requirements Extensive interviews were conducted with the pilot users prior to system installation and in preparation of an improved system version. These interviews aimed at analyzing users' work practice and system usage to gain requirements for future system versions. The results of the interviews were augmented by workshops that were held with the users, and requirements that resulted from user discussions with the system support staff. The interviews were conducted by 2-3 project members with each pilot user individually. Care was taken to ensure that every project member participated in the interviews, allowing all system designers to gain first-hand insights into the pilot users' work practice that would not be available by just reading an interview transcription. The interviews were semi-structured, i.e. they were based on pre-formulated questionnaires serving as a guideline for the questions to ask. Interviews lasted from 1 to 3 hours each. The first series of interviews was conducted prior to system installation. The main goal of these interviews was to develop an understanding of the work processes in the application field. Questions therefore focused on how users work without groupware support, and how they would imagine that computer support for cooperation could improve their work. No questions on specific functionality were asked because it was felt that users cannot effectively judge computer support if they have not experimented with the corresponding features. As Kyng (1994) states, "users are not able to bridge the gap between [...] dry descriptions and the professional knowledge and skills that form the basis for high quality user contributions". Therefore, users were not asked explicitly about their need for awareness support. Nevertheless, the interviews revealed the necessity for awareness both in real life as well as for computer support in the application field. 102 The POLITeam Awareness Service The second series of interviews took place after the installation of the second POLITeam version which incorporated many changes that were based on previously collected user requirements. Users had been working with the POLITeam system for over a year. This time, the interview included questions about specific system functionality, in particular about awareness features. Also, the use of conventions related to system usage was an important aspect of the interviews. Regarding the interviews, it is important to remember that user requirements regarding specific functions must be handled with care. Users tend to demand the same functionality they know from their day to day work practice, since they often cannot judge the benefits and the potential offered by computer support. Therefore, POLITeam takes the approach of letting the users experiment with the system in the field using prototypes of the functionality to be developed. For example, in the beginning of the project users considered electronic circulation folders to be extremely important-in correspondence to the paper folders they use every day. While working with the system, users realized that for many situations they really prefer the shared workspace, an object without equivalence in the real world (Klöckner, Mambrey et al., 1995). Another general effect could be observed during the interviews. Users seemed to be reluctant about introducing functionality into the system they did not know, demanding new features only if they seemed to be obviously necessary for their daily work. For example, they expressed to have no need for a more elaborate model of access rights, although the currently supported model is highly deficient. The answers suggesting the contrary therefore may result from the fact that users simply cannot imagine effective support for a given problem. As a result of these effects, users initially seemed to be less enthusiastic about awareness support than we expected. Some users even stated explicitly that they have no need for an awareness service at all. "Everything I need to know is contained in the circulation folder I am working on." 22 However, this was due to the fact that these users worked in isolation before introduction of the POLITeam system as well. In these cases, where awareness of co-workers' activities is neither needed nor wanted, there is obviously no need to support it electronically. One unit leader also stated not to need any awareness features, because his subordinates send him an email every time they change a document. This is an almost classical example of the mismatch between the users who profit from additional work and those who actually have to invest it (Grudin, 1988). While automatic collection and distribution of this information would reduce work of the unit members and increase reliability of the service, the unit leader fails to see a necessity for awareness features because he does not see any direct benefits for himself. Other users clearly stated their need to be aware of others' activities to coordinate their cooperation: "We produce paper and have no idea of its whereabouts." "Most of the time, one has no idea who is working on a process." 22 All user quotes were translated from their German original. User Requirements 103 "In some cases it would be nice to get a message: `ABC' worked on the document XYZ'." "I forward my draft ... and sometimes they change my text and give the changed documents [away] ... sometimes without me getting any notification. It would be good if I were able to see what they do." "Often, they would not reach us by phone after finishing writing a text, because we weren't sitting at our desks or were phoning ourselves ..." Users also remarked that different levels of intensity and priority should be supported: only highly important events should be reported directly, while "there should not be too much happening at once" in the workspace. There is strong evidence that users accept and use awareness features once they are introduced to them, even if they did not see the necessity before. For example, most users agreed that work can be performed much faster with POLITeam. This was attributed to the fact that correction loops between the ministry unit and the central writing pool were either eliminated altogether (because users type changes themselves) or greatly accelerated. Acceleration resulted from reduced transport times. Without POLITeam, corrected documents had to be transported by a messenger taking considerable time. With computer support, documents are simply exchanged through a shared workspace and available immediately. "It goes faster. We're [physically] separated from the unit, and naturally, that goes much, much faster. When we put something in the directory, they can pick it up at once. [...] So, for things that must be done in a hurry, we can do it really fast. Before, with a messenger, it could even last up to one day." However, the first version lacked an awareness mechanism to notify users that a corrected document has been produced. Therefore, the second version introduced a simple dialog box for this purpose, which, while rudimentary, was greatly welcome by the users: "... the text is written by the writing pool, and is put in my [electronic] closet, Then it shows ... that the closet has been changed." The other awareness feature introduced by this version-a color change of the mail inbox icon if there is pending mail-was also source of positive comments: "In particular, the red mail inbox is extremely helpful." The text processor integrated into the system flags text changes made by other users by showing them in different colors. This awareness feature is used extensively by some users: "Yes, the colors in the text help me a lot to see what was changed in certain documents." One user commented on the decrease of informal communication after installation of the system: "In personal conversation with X, I always get good ideas. His facial expression conveys a lot of information. This is lost somehow. [...] Since the introduction [of POLITeam] I talk less with my colleagues [...]. Sometimes important information is missed this way. Before, such information would be passed in a conversation. Now sometimes this does not happen." 104 The POLITeam Awareness Service This lack of informal communication was caused by the fact that the system allows documents to be exchanged by using shared workspaces, whereas without electronic support they had to be exchanged personally which led to informal conversations. As discussed in Section 4.2.1.2, this restriction may at least partly be overcome by an adequately designed awareness service. Conventions were identified as a central aspect for the success of the system (Mark, Fuchs et al., 1997). A dedicated workshop was conducted on this topic. Users expressed their need for conventions for a variety of work situations: "[A shared calendar tool] doesn't function yet, though, since we don't have conventions for it. Each one does something else." "There's always a certain openness of doing things and a certain stringency. These are the two poles. [...] Everyone arranges their desk in their own way, and that's their freedom. [...] The problem is that we are in an evolutionary process here-we need conventions for our normal contact with each other, our process. We need to find a balance between individual operations and conventions. [...] There are things that must be reproducible. [The system's] success depends on this." As discussed in Section 4.2.1.3, awareness functionality can help to establish and maintain this form of conventions on the use of shared resources. Almost all users stated that they have no interest in receiving synchronous notification about others activities. On one hand, this is a consequence of the highly structured work processes in the ministry which favor sequential work, putting less emphasis on synchronous collaboration. On the other hand, it is worth to note that one user that was particularly decisive about this functionality ("[This] would never be helpful.") admitted a few minutes later that he does in fact use the display of logged in users, which is about the only synchronous perceptualization mechanism supported by the original system. It is interesting to note that users very rarely expressed concerns regarding privacy violations. Only one user feared privacy violations by awareness features: "The circulation folders on my desk are nobody's business but mine." In contrast, another user explicitly welcomed the potential surveillance possibilities to control the work progress of superiors: "That this [awareness] allows the lower [hierarchical] levels to control the upper levels is a desired side effect." One user stated to be interested in reciprocity of the awareness service: "At least I want to be informed if someone is watching me." This relaxed view on privacy issues probably results from different factors. First, the pilot users are used to work closely together; there are few private areas in their non-computer supported work reducing the visibility of privacy problems. Furthermore, those privacy problems that may arise are simply solved by social protocols: for example, people see if others have searched their (physical) desk. It may be difficult for users to imagine that this form of social control PoliAwaC 105 needs not to be present at all in a computerized environment: a computer application possibly does not give any indication that private work spaces were violated. In summary, users explicitly demanded support for awareness. Special consideration should be given to the support of individual work and to the provision of different levels of perceptualization intensity. This is consistent with the findings of Bowers (Bowers, 1994, p. 291) from a study of a UK government agency: users also complained about being unaware of events in the employed groupware system, and demanded an awareness service with differing intensity levels to support informative notification. 7.5 PoliAwaC Based on the POLITeam design goals, the specific design goals for its awareness service, the user requirements, and the perceptualization framework discussed before, an alternative client application for the POLITeam system was developed to enhance mutual awareness of users and hence improve cooperation. In this section, we will describe the design of this alternative POLITeam client. For the following discussion, it is important to distinguish between three different systems we will refer to: LinkWorks is the unmodified, commercially available base system; POLITeam23 refers to the modified system as installed in the ministry, and PoliAwaC (POLITeam Awareness Client) is the name of the improved client. It is important to note that these systems have many aspects in common: all three systems rely on the same server to provide basic groupware functionality and as object repository. Regarding awareness functionality, LinkWorks and POLITeam are almost identical in their limited support. 7.5.1 Design for Real Use The design of PoliAwaC not only had to take into account the functional aspects discussed before, but it also had to consider the environment in which it was to be employed. The organizational and technical environment of the ministry imposed several design constraints. In contrast to many groupware systems that are realized merely as "proof of concept" research prototypes, the envisaged system had to be useable in a production environment. Prospective users of the system were not computer experts, their ability to adapt to modified interfaces and functionality without intensive training was limited. The new client had to co-exist with installed hardware and software. Main design aspects, therefore, were reliability, ease of use and learning, and integrability. Ease of use was achieved by deliberately basing the design of the prototype on standard desktop interfaces to build on existing skills of users in working with these interfaces (partly acquired from working with the first POLITeam versions). The interface should only deviate from existing standards where necessary to provide awareness information. This approach has 23 Actually, POLITeam is the name of the whole project, and the versions installed in the ministry were consecutively called POLITeam 1.0, POLITeam 1.1, and POLITeam 1.2. However, it should be clear from the context if the text refers to the project or to the installed version. 106 The POLITeam Awareness Service the additional benefit that it is easier to judge the effects of additional awareness information- if a completely different interface were used, it would be unclear if different working styles result from the modified general interface, the provision of additional awareness information, or a combination of both. Therefore, any discussion whether the standard graphical user interface is appropriate or actually constitutes a major hindrance for the development of improved interfaces (Buxton, 1994) is futile in this environment. A second reason for the orientation on standard interfaces was the installed software of the application domain. Most computer work in the ministry is done using standard word processor or spreadsheet applications. Therefore, POLITeam stressed easy integrability of these applications into the groupware system. In particular, this included the provision of a user interface consistent with these standard applications to avoid users having to learn different interface metaphors and interaction techniques. As Grudin (1990b, p. 275) puts it, "`new' interfaces are constrained by existing interfaces" because of users' "habits or expectations that cannot be ignored". The initial POLITeam implementation was only a slight extension of the usual desktop metaphor. While the integration of an adequate awareness service requires major changes to the interface because additional information has to be presented, the premise that it should be oriented on standard interfaces as much as possible is still valid. Finally, the technical infrastructure of the ministry (mainly low-end PCs) prevents the use of sophisticated visualization techniques (e.g. 3D rendering of the cooperative environment) altogether, because of their limited computing power. Additional hardware constraints were low-resolution monitor settings, limited main memory capacities, and limited network bandwidth. Furthermore, the use of audio signals to transmit awareness information was highly limited as well because the typical ministerial workstation was not equipped with a sound card. This constellation prevented the use of perceptualization mechanisms other than visualization from the start, while at the same time prohibiting the use of resource-intensive visualization techniques. The problem, therefore, consisted in designing a system incorporating the necessary awareness functionality while retaining the basic interface model of the base system and without overly compromising system's performance and resources. 7.5.2 General Concept PoliAwaC supports a variety of different perceptualization mechanisms covering the different aspects discussed in the perceptualization framework. The system is modular, each interface technique can be used on its own or in combination with other mechanisms. The mechanisms provide different levels of notification intensity. Ranging from lowest to highest intensity, the system supports the following levels: * no notification; * the indication of object status by color and form changes of its icon; * a textual event display in a tool bar; * the enlargement of an affected object's icon; PoliAwaC 107 * an event display in a pop-up dialog box. Users can select which events they are informed about by using an elaborate model based on awareness profiles. An awareness profile is defined by a set of objects, selected operations on these objects (e.g. create/edit/read), and a working situation in which awareness information should be made available (for example, always, if the object is selected, if the corresponding container object is opened, etc.). Additionally, each awareness profile is assigned an intensity level, which is a numerical value ranging from 0-4. These values are mapped to the basic techniques listed above. High intensity levels automatically include all lower intensity mechanisms as well. Additionally, the new client features an improved general user interface, and explicit support for conventions based on object enablers (Syri, 1997b). We will not go into details of the latter; design, implementation, and results are discussed in (Syri, 1997a). 7.5.3 A better LinkWorks than LinkWorks The POLITeam Awareness Client (PoliAwaC, Figure 7-4) was designed as a replacement for the standard LinkWorks client that is normally used within the POLITeam project (Figure 7-3). It provides most of the functionality offered by the standard client and integrates additional awareness features. Figure 7-4. The PoliAwaC client window24 24 All texts and messages of the original system are in German in accordance with its intended usage in a German ministry. However, some screendumps have been translated into English to facilitate understanding of the interface concepts. 108 The POLITeam Awareness Service PoliAwaC is based on a semi-replicated architecture (Graham, Urnes et al., 1996). While document data and attributes are still kept on a central server, object interface information displayed on the local client is replicated and constantly updated through corresponding update event messages. This is different from the approach chosen by LinkWorks, where screen updates are performed only on explicit user request. The LinkWorks solution, while much easier to implement, does not correctly reflect the dynamic nature of a cooperative environment. Even without considering awareness functionality, the new interface is an improvement because it is more closely oriented on user needs and general interface design guidelines. Besides minor enhancements like a more consistent menu layout and detachable tool bars, PoliAwaC provides a closer integration of objects and associated functionality. It provides a variety of general user interface improvements: * Facilitated navigation in the object hierarchy. A tree view displaying the hierarchical layout of a user's workspace is attached to every window. This allows easy navigation within the object hierarchy. To allow a better overview on the overall object structure, this view can be zoomed out, allowing a very dense display of information in the limited space. Furthermore, "Back" and "Forward" buttons similar to those supported by most Internet browsers allow users to easily revisit work spaces they have been working in before. * Improved views on the work objects. The currently selected container is displayed in two connected views. The first one displays large object icons and allows user to arrange the spatial object layout according to their needs. The second view displays a sorted list of objects showing additional attribute information. This approach ensures a high visibility of all relevant object information without users having to switch between different views. Both views may be synchronized. In this case, selection of an object in one view automatically selects the same object in the other view. * Direct-manipulative operations to create copies and shares of objects. LinkWorks only supports direct manipulation to move objects. In contrast, PoliAwaC allows users to create copies and object shares by the same mouse operations used in conjunction with keyboard modifiers. The actual operation is indicated by the form of the mouse cursor. Besides making essential operation much easier to accomplish, this facilitates usage of the share feature that is essential for the technical realization of shared workspaces (Mark and Prinz, 1997). * Drag-and-drop-operations between arbitrary windows. LinkWorks only supports a very limited drag-and-drop model: corresponding operations are only possible between specific windows. Besides being highly counter-intuitive, this effectively hinders users in performing even simple operations. PoliAwaC allows any object to be dragged to any window. * Context menus for all objects offering the most important functionality. Context menus offering object-related functionality are provided for all objects in all views. This allows users to access the most important features in a fast and easy way. These menus are opened by a right mouse click on an object, an operation that has no effect in the standard LinkWorks interface. PoliAwaC 109 * In-place editing of object attributes. LinkWorks displays object attributes (e.g. date of creation or owner) in the main view and provides a separate dialog window to edit these attributes. While PoliAwaC still supports this style of attribute modification, it also enhances users' notion of the connection between an object and its attributes by allowing direct editing of the attribute in the main view. This also allows easier and faster manipulation of object attributes while retaining the context in which the object is embedded. Note that all these improvements, while enhancing the user interface of the system, do not change its basic nature or interfere with its original design. They either complete existing functionality or are mapped to unused interaction mechanisms. Users may use the improved functionality, but they are also free to work with the system using the original LinkWorks style. However, the new interface elements also contribute to the additional awareness features that will be described below. It is important to note that in addition to all the enhancements described before, the prototype has some serious limitations in comparison to the original client as well. These deficiencies are not design flaws, but either results of the complex system architecture that was necessary to communicate with the LinkWorks server, or of the prototypical implementation that did not fully replicate all functionality of the standard system. The single major problem of the prototype is performance: all operations that involve communication with the server are much slower than their original counterparts. While this is unavoidable due to the way the LinkWorks programming interface is implemented (cf. Section 7.6 below), it is more than a nuisance to users and leads to decreased acceptance rates (cf. Section 7.7). Another problem that was underestimated was the relevance of specific functionality to users: the prototype does not support an object specific display of attributes, nor does it support proper object sorting based on these attributes. However, evaluation showed that these are critical features for our users. Finally, while the original client is available for a wide range of different operating systems, PoliAwaC only supports the one actually used by our pilot partners (Windows 95). 7.5.4 The Client Window PoliAwaC incorporates a series of interface mechanisms to support awareness. This includes enhanced object icons allowing peripheral perception of awareness information, user objects showing user location and availability, and extensive support for the asynchronous presentation of awareness information. The latter is especially important in the ministerial work environment where asynchronous work is the prevailing form of cooperation. A main design goal was to allow smooth transitions between single user and multi-user work. While working alone, multi-user features of the interface do not become apparent. All additional features only apply when multiple users work together. Therefore, users not engaged in a collaboration, or not interested in cooperating with others do not have to change their working style. Even in multi-user sessions, the interface does not change dramatically, but relies on existing interaction and presentation techniques. Since the amount of awareness information that is displayed can be adjusted individually, transitions between different working modes are in fact smooth. 110 The POLITeam Awareness Service 7.5.4.1 Metaphors The POLITeam system uses the central metaphors of the shared workspace and the electronic circulation folder (Prinz and Kolvenbach, 1996; Prinz and Syri, 1996), and so should the awareness service. However, since electronic circulation folders turned out to be rarely used in the application field25, the shared workspace became the single central organizing metaphor of the POLITeam awareness service. Workspaces are simply container objects containing other objects such as documents, tools, or other containers (Pankoke-Babatz and Syri, 1996). Workspaces may be private or public, depending on the users who have access to them. The iconic representation of shared workspaces is flagged by a special superimposed symbol to make them easily distinguishable from private workspaces. Workspaces have an owner, who is the only person allowed to invite new members or to remove current members. Ownership may be transferred to others by the owner. Since workspaces are normal objects, they may be manipulated (created, moved, copied, etc.) in the same way as all other objects. As far as the awareness service is concerned, a user is considered to be actively working in a workspace as long as the corresponding container remains open in the client. PoliAwaC provides three specialized views on workspaces (cf. Figure 7-4). The first displays a hierarchical overview of a user's workspaces, including the users that have access to it or are actively working in it. The other two views display the documents contained in the workspace currently selected in the hierarchical display. Since users may open several windows, they may be active in more than one workspace at the same time. This is a slight extension of the standard graphical user interface desktop metaphor. Workspaces are the equivalent of folders. However, the workspace metaphor explicitly visualizes the sharing of objects by representing the users in the display. Note that while rooms are not explicitly modeled, workspaces may be used as such. Since users that are active in a workspace are visible, grouping, work practice, and current activities can easily be observed. Unlike other approaches where users may only be active in one room (DIVA), PoliAwaC allows users to be active in as many workspaces as they see fit. As discussed before, activity is simply determined by opening the corresponding workspace, meaning that the user has visual access to it. In contrast to DIVA, this poses no problem since audio and video connections are not established automatically. 7.5.4.2 Enhanced Icons The original LinkWorks system uses icons to represent document types much like in the standard desktop metaphor. PoliAwaC uses the object icons to transport additional awareness information. Basically, there are two different ways to present additional information using object icons. The first is to change icon placement, the second is to change icon appearance. In the former case, information is transmitted by the position of the icon in relation to other interface elements. In the latter case, additional information is encoded by changing the form, color, or size of 25 Partly due to the fact that not all levels of the hierarchical organisation took part in the first test phases. PoliAwaC 111 individual icons. Some of these changes (size, in particular) may be used to represent a continuous set of values, while others (form, color) are best suited to represent discrete values. However, interfaces are not free to use or modify all these parameters because they are also used to convey information on the original object. For example, in the standard desktop metaphor as used by the Apple Macintosh, the form of an object icon represents the type of the corresponding document. Most current window systems as well as LinkWorks use color icons for the same purpose. The spatial layout of icons may usually be defined freely by the user to support individual configuration of workspaces. PoliAwaC uses four techniques of icon manipulation that take these problems into account: * Form: In some cases, the icon of an object is changed according to its status. In particular, this is done for the icons of the mail inbox to signal pending mail, and for the waste basket to indicate that it contains deleted objects. Note that this usage of icons is consistent with common window system practices (e.g., Macintosh or Windows 95). However, this technique is limited in its applicability because it requires users to differentiate between icon forms and map them to different object states. Therefore, it is sensible to restrict its usage to cases where the status of the object can visually be deduced from the changed icon, e.g. by displaying mail in the mailbox, or litter in the waste basket. * Color: Color is used to represent users. Objects that were manipulated by a user are superimposed by a transparent plane in the corresponding color. Note that a simple color substitution scheme would fail because the standard icons use colors themselves. The area of the colored plane reflects the time elapsed since the event was registered. For this purpose, the upper edge of the color plane serves as a gauge as indicated in Figure 7-526. Note that at least half of the area of the icon remains colored to allow identification of the originating user. Now 5 M inutes ago 1 Hour ago 1 Day ago 1 W eek ago 1 M onth ago Time Figure 7-5. Elapsed time indication on object icon * Overlay: To indicate the type of operation performed on an object, a second icon is overlaid on the original icon (Figure 7-6). In contrast to changing the icon altogether as described before, the combination of object icon and overlaid operation icon reduces cognitive load of the users. Only two series of icons have to be memorized: object types, and operation types. 26 This mechanism was originally designed to reflect the percentual amount of changes to a document. However, it turned out that the base system could not supply the corresponding values in a reliable way. 112 The POLITeam Awareness Service Since the operation icon goes beyond the area occupied by the object icon, it is easily recognizable as additional information. Figure 7-6. Overlay icons indicating operation type * Size: The most noticeable icon-based notification mechanism is icon enlargement. This mechanism is used for the icons both in the hierarchical view and in the workspace views. For the latter, icons of modified objects are enlarged to 140 percent of their original size, resulting in a noticeable but somewhat subtle effect. Note that a larger scaling factor would be problematic because it would require repositioning of other icons to avoid overlapping. In the hierarchical view, icons are enlarged to 200 percent of their original size, and events are propagated up the hierarchy (cf. Section 7.5.4.3). All these mechanisms do not hinder identification of the original icon. The different techniques are used in conjunction or exclusively, depending on the intensity level defined for a specific event. The mechanisms are listed from the lowest to the highest priority. Any presentation of a specific priority level automatically includes all forms of lower priority. All forms of icon modification are removed if the user selects the corresponding object, which implies that he has visually acknowledged the change information. There are two exceptions to this rule: first, the overlay icon indicating that an object is in use is removed automatically as soon as editing of the object is finished. Therefore, this overlay icon indicates a currently active process. Second, icons that changed their form are only changed back if the object status is reset to its prior status (i.e., mail in the inbox is read, or the waste basket is emptied). The object icons are omnipresent in the PoliAwaC system, thereby reinforcing the mental link between an object and its visual representation. Everywhere an object is represented, the corresponding icon is displayed as well: in the workspace views, in the event and history windows described below, and in all other dialog boxes presenting object information. All visible object icons include the change indicators described before. Resetting the changes in one view resets the corresponding icon in all other views as well. This provides an effective form of news control for awareness information. 7.5.4.3 Overview As discussed before, every client window shows an overview of a user's desk in a hierarchical tree display. Nodes of this tree may be individually expanded or collapsed, either showing or hiding the contents of the corresponding container object. Objects of interest (e.g. documents that contain changes) are enlarged, allowing users to spot activities at a glance. If such an object is hidden in a collapsed part of the tree view, the closest visible parent is enlarged instead (Figure 7-7). PoliAwaC 113 Figure 7-7. Event propagation in the object hierarchy This enables users to notify a change even if the corresponding object is not directly visible on the screen. Users can easily decide if an object itself was modified, or if the enlargement merely reflects a change in some subordinate object. In the former case, the object icon is colored as well and includes the operation overlay icon, while in the latter case it does not. These mechanisms, in conjunction with the other icon modification techniques described before, allow users to perceive events using peripheral vision. In particular, the enlargement of an object icon is easily noticeable even if the visual focus is directed somewhere else on the screen. Users are still free to navigate through their document structure as usual because the hierarchy and the relative positions of objects remains unchanged. The tree display also includes information about the organizational structure and the users of the system. 7.5.4.4 User Representation PoliAwaC uses two different mechanisms to represent users: icons and colors. Where appropriate, these techniques are used in combination. Icons are used to represent users in the workspace views (Figure 7-4)27. Every workspace that is shared by at least two users (i.e., that is not a private workspace), contains a pseudo-container "Users of ". This special container shows the iconic representation of the members of the workspace, and their organizational position. The organizational structure is shown only as far as it differs for the users of the workspace. For example, if all users of a shared workspace are part of the same organizational unit, the display omits any organizational information and simply displays a list of the users. This container does not represent an existing LinkWorks object, and it cannot be manipulated in the same way as other objects (e.g., the users of a workspace cannot be moved to another workspace; the semantics of such an operation would be unclear at best). Note that this does not introduce an interface inconsistency: the original system also disallowed certain operations depending on the type of the selected object. 27 Gutwin et al. (1996a) sketch a similar approach displaying both the symbolic structure of a shared workspace and user portraits to show their focus of activity. 114 The POLITeam Awareness Service Each user icon consists of a generic user symbol, drawn in the color corresponding to the user and labeled with the user's name. For users not actively working in the workspace, only an outline (still in the corresponding color) of the icon is displayed. This way, the users actively working in a workspace can easily be identified. The status line of the client window repeats the iconic part of the user list for the currently selected workspace, providing immediate visual access to membership information. The root element of the hierarchy is formed by a "POLITeam system" entry28. In analogy to other workspaces, its corresponding "Users" section displays the complete organization structure, as well as all potential and all logged in users. User's personal desks are located beneath their icon in the user section. The other basic mechanism to identify users is color. As discussed before, icons of documents that were manipulated in some way by a user are superimposed by a semi-transparent plane in the color corresponding to that user. Note that color is especially well suited to identify users in the POLITeam application field: German ministries already use an elaborate scheme for user identification by color (cf. Section 7.1.3). Of course, the number of distinguishable colors is much smaller than that of users in any large organization. Nevertheless, color may still show the class or role of a user (as in the ministry, where colors are assigned according to hierarchical positions). 7.5.5 Asynchronous Presentation of Awareness Information Asynchronous presentation of awareness information to support asynchronous work was a central design aspect of PoliAwaC. It provides three basic interface elements for this purpose: an event tool bar, an event dialog, and an object history dialog. The event bar (Figure 7-8) provides both event history, immediate notification, and the possibility to explicitly generate object-related awareness information. Basically, it consists of a drop-down text bar and a set of buttons. The text bar always shows the latest event that is of interest to a user, displayed in the color associated with the user that generated the event (appearing as shades of grey in the figure). The drop-down list of the event bar displays a chronological list of the latest events. Note that every event entry displays both a textual description of the event and the iconic representation of the object associated with the event. There is good reason to combine these two techniques: the iconic form allows peripheral perception of the related event (object type and event originator are readily accessible). In contrast, the textual form requires user attention but reveals the relevant details of the event. Users can enter text in the text field, which will be distributed as an event associated with the currently selected object to all other users. This allows users to actively provide awareness information that cannot be collected automatically by the system (e.g., the rationale behind document changes). Buttons are provided to select the objects associated with an event (providing a direct link between events and objects), and to open the object's history dialog. The event bar can be used as a stand-alone window (Figure 7-8) or attached to the client main window (as in Figure 7-4). PoliAwaC 115 As a stand-alone window, it can be used to monitor cooperative activity even while working with other applications (see below). Figure 7-8. Expanded event bar In addition to the event bar, the system offers an event dialog using exactly the same mechanisms, except that the history list is always expanded. This modeless dialog is used to display events with high priority. It is automatically popped up and stays in the foreground for such events. Users have the same facilities as described before to get additional event information or to react to the event. This dialog represents an improved form of the dialog that is supported by the basic version of LinkWorks. Figure 7-9. PoliAwaC history dialog Finally, PoliAwaC also supports a history window that displays the history of an object in textual form (Figure 7-9). This dialog has to be invoked actively by the user. Again, users are identified by the color in which the event description is shown. Events can be sorted and rearranged in several ways. Users can select additional event attributes to be displayed. The classes of events that are displayed can be selected as well, allowing individual history subsets. All events originating from work in private workspaces are collapsed to a single, anonymous entry. In contrast to other awareness functionality, the history window is a separate application that does not require a special client. It may be used both with PoliAwaC and the original POLITeam client. On one hand, this allows users of the standard system to benefit at least partially from the increased awareness functionality (note that the generation of events is 28 This feature was not implemented due to problems of the base system providing the necessary information. In the actual system, the root element of the hierarchy is a user's desk. 116 The POLITeam Awareness Service independent from any client: it is performed on the server29). On the other hand, this led to inconsistent usage of visualization and interaction techniques. The link between events and object icons as implemented by PoliAwaC is impossible to include in the history window because there is no efficient way for the independent applications to share the necessary information. 7.5.6 Integration with Standard Applications The POLITeam system enables users to cooperate electronically-it provides tools to share working material, to describe and execute working processes, and to communicate with each other. It does not provide, however, the actual tools to create and edit electronic documents- the artefacts ministerial work is mainly concerned with. For this purpose, POLITeam relies on standard applications that are integrated into the system. Any application running on the target system may be used this way. Documents are stored on the central server and retrieved if a user opens the document. Editing is performed on a local copy of the document. The copy on the server is locked for other users while editing takes place. This approach is highly flexible regarding the applications that may be integrated into the system. However, these applications (e.g., text processors or spreadsheets) are usually designed for single users and have no notion of cooperation at all. Since most productive work is performed using these tools (rather than the POLITeam desktop), the awareness service has to consider the integration of these applications. There are two aspects of this integration that have to be considered: 1. The granularity of the events. The fact that a document has been changed is reported by the awareness facilities described before. However, users may also be interested in a more detailed report, e.g. what was changed exactly in the document. To achieve this, the application would have to generate events, and ideally provide means to present awareness information on the document. However, this requires extensive extensions of the application that are rarely possible to implement. Even if a macro programming language is provided, the presentation of document information is usually beyond user control. Moreover, these modification would have to be performed for any application to be used with the system to ensure a consistent notification scheme. 2. The presentation of global awareness information while working with a standard application. Screen space is too limited to allow the PoliAwaC window to be displayed all the time. In particular, it will usually be in the background if users work on a document. This results in the problem that even the most elaborate visualization techniques will fail if the corresponding window is hidden. Therefore, additional techniques are needed that allow notification reception even if the main client window is inaccessible. As for the integration of application-generated events, a consistent solution is almost impossible due to the reasons described before. Moreover, the implementation overhead even for a single application and for limited functionality is prohibitively high. However, multi-user information provided by the application may be integrated into the system. For example, Microsoft Word is the single most used application in the test field (accounting for more than 29 Nevertheless, clients are free to generate events as well. PoliAwaC makes use of this feature for the user- generated event messages described before. PoliAwaC 117 95% of the documents). Word supports a change notification mechanism by displaying changes to a document in a color associated with the corresponding user. Since colors also identify users in the PoliAwaC system, both systems can easily be combined by matching the colors that are used30. PoliAwaC addresses the second problem directly, however. The event bar described before may be detached from the main window and may be instructed to stay on top of all other windows. This way, it remains visible regardless of the application the user is actually working with (Figure 7-10). Since it is only a very small window, the screen space it occupies is only a minor problem: as Wax (1996) observes, floating windows "most often [...] sit at the bottom of the screen, out of the way". Any events happening in the POLITeam system that are of interest to the user are immediately visible. The buttons provided allow easy inspection of the affected objects. Figure 7-10. The event bar and standard applications The hierarchical tree view supported by PoliAwaC provides another means to observe global activities while working with standard applications. For this purpose, the tree display may be decreased in size (up to 25 percent of its original size), allowing the complete object hierarchy to be displayed beneath an application window (Figure 7-11). In this zoomed out state, the tree only occupies very limited screen space. Since the usual enlarged and enhanced icon information is still available, users can monitor where relevant activities are taking place. While individual object information is barely recognizable in the scaled down display, areas of overall activity are easily identified. Furthermore, by moving the cursor over a specific item, the corresponding information is displayed in normal size. This also allows quick visual browsing through the object hierarchy. 30 While this sounds easy in theory, it turned out to be highly complicated in practise: Word does not support an arbitrary combination of colors and users. 118 The POLITeam Awareness Service Figure 7-11. The minimized tree view and standard applications 7.5.7 Event Distribution and Collection: Interest Contexts As discussed before, selection of the events that are presented to a user is a crucial issue for the awareness service. PoliAwaC uses a highly elaborate model to define and describe user interest in specific events. The complete model and the underlying mechanics are described in detail in (Fuchs, Pankoke-Babatz et al., 1995) and (Fuchs, 1997). We will only discuss those aspects related to the user interface and to perceptualization. The selection of awareness information is based on the metaphor of a "work situation" to allow users to specify awareness profiles. Work situation System provides awareness information "Working on the document" when the user opens the document "Accessing the parent container" when the user opens the folder containing the document "Accessing any parent container" when the user opens any higher-level folder containing the document "Immediately" immediately, regardless of the user's current activity "Working on the same process" when the user accesses another document that shares the same file code Table 7-1. Work situations Any object, such as a document, defines a number of activities as well as a variety of work situations in which it may be involved. These can be combined to tailor personal awareness preferences to individual work practice. Work situations are highly dynamic and need not be restricted on actions performed on the target object itself. Rather, they may include actions on PoliAwaC 119 objects that share certain relationships or similarities. Note that this model incorporates a simple form of the interest area as discussed in section 5.3.3. Objects are supposed to be related for awareness purposes if one object is contained in the other, or if they share some attributes. The details of awareness preferences can be defined using awareness profiles, which can be attached to single objects, collections of objects, or whole classes of objects. The system only informs about events in situations that conform to a user's subscribed set of profiles. Moreover, users can specify the intensity of the presentation for specific events. In this way, it is possible for users to set up their interest in awareness information in a natural way, in terms of domain specific work patterns, e. g.: "whenever I open any document I want to see what happens to other documents that belong to the same process". Figure 7-12 shows part of the dialog sequence used to define an awareness profile, in this case, the selection of a work situation. Figure 7-12. Defining interest based on work situations Note that awareness profiles are shared objects. Users can create new awareness profiles, or subscribe to existing ones. Therefore, jointly used awareness profiles may also be used to establish a reciprocal form of group awareness. 7.5.8 Awareness As demonstrated before, PoliAwaC provides extensive support for awareness on different levels and using different notification mechanisms. Figure 7-13 and Table 7-2 summarize the different strategies and interface techniques that are employed. 120 The POLITeam Awareness Service Change Indicator Activity Indicator Overview Share Information Propagated Change Indicator Current Workspace Active Workspace Users Detailed Event Information Current Workspace Membership Figure 7-13. Awareness cues in the PoliAwaC interface PoliAwaC successfully realizes the design goals of the POLITeam awareness service discussed before. Basic user requirements-support for individual as well as cooperative work, consideration of users' privacy, support for different levels of perceptualization intensity- were met by extending the standard desktop interface, providing a highly configurable model of specifying interest in events, and supporting a variety of perceptualization mechanisms, respectively. In Section 7.7 we will discuss actual experiences of users working with the system for an extended period of time under real-life conditions. Synchronous Asynchronous * Provides an overview of current activities * Signals past activities of others, such as documents (hierarchical view). changed by others and shared workspaces containing * Shows access, grouping, and current status of these. co-workers in shared workspaces (hierarchical * Provides a complete object history (history window). view). * Indicates originator, elapsed time, and event type on * Shows who is editing what (workspace view). object icons. * Supports different forms of notification and * Provides news control through consistent icon flexible selection of interesting events. display. * Permits users to control information transmitted to others. * Provides access points to establish a/v- connections to others. * Shows current activity, such as documents currently in-use and shared workspaces containing these. * Allows users to transmit object-related awareness information (event bar). Table 7-2. Awareness support in PoliAwaC The general design goals of the awareness service of the POLITeam system (cf. Section 7.2) were met as well. Different unobtrusive user interface techniques to present awareness Implementation 121 information minimize the need to actively request awareness information. The availability of other users for communication is presented by showing whether they are active in a shared workspace. To avoid information overload, users are able to select which events are of interest to them and how intensively they should be presented. Past events are recorded and available for retrieval. However, not all events are available to all users, availability depends on individual workspace membership. The only general design goal not directly realized is the idea of increasing cooperation efficiency by making inefficient work patterns visible. However, this goal is quite ambitious: awareness does not necessarily remove inefficiencies in face-to- face cooperation as well. Therefore, subtle effects in the long run are to be expected in this respect at best. Aspect Support Origin Passive: Virtual location of users; workspace related activities Active: Object-related messages Time Synchronous: Enhanced icons, event bar Asynchronous: Event record Relevance Sophisticated model based on work situations Visibility Depends on work situation Fidelity Aggregation of events in private workspaces Medium Visual, audio used sparingly Temporal Distortion Event record Spatial Distortion Object hierarchy display combined with icon enlargement Integration Extension of standard desktop metaphor Representation Users: Icons and colors Invocation Passive and active (event log) Reception Passive: Workspace activities can be perceived peripherally Active: Pop-up event dialog Table 7-3. Notification support in PoliAwaC Since the design of PoliAwaC is based on the perceptualization framework discussed before, it is not surprising that it meets most of its requirements (Table 7-3). Deficiencies apply mainly to two areas of the framework: support for sound is only rudimentary, and animation is not supported at all. These problems, however, were direct consequences of the limitations of the technical infrastructure in the ministry. 7.6 Implementation Due to the basic conception of the POLITeam project, the implementation of additional awareness functionality faced severe problems. These problems were related to the adopted base system, which turned out not to be as easily extendible as its designers claimed it to be. Its restrictions led to a rather bizarre system architecture. We will describe these problems in detail below, together with a discussion of the resulting software architecture and a brief sketch of the object model underlying the awareness service. 122 The POLITeam Awareness Service 7.6.1 Restrictions of the Base System The chosen base system turned out to be a major hindrance for the implementation of additional awareness functionality. The design approach of the POLITeam project to use a commercially available, well-established product as the base for its developments turned out to be highly successful in some respects, but it also failed in some other ways. In the starting phase of the project, it prevented the need to implement basic functionality. The system could be introduced and evaluated quickly. This avoided starting delays and produced results almost immediately. However, during the later phases of the project, the drawbacks of this concept became more visible. The implementation of functionality that deviates from the approach chosen by the base system turned out to be highly complicated. While configuration and simple changes of the base system are easy to realize, complex modifications are not. LinkWorks is supposed to be an open system, allowing integration of other applications, and full customization of its functionality. However, practice showed that the system is not nearly as extendible as it ought to be. Its openness is actually reduced to those functions that were deemed interesting modification or extension candidates by the LinkWorks designers. Where such interest was not expected, or where problems for the "system consistency" resulting from user changes were suspected, functionality can simply not be accessed or modified. The problems of the LinkWorks programming interface become apparent by examining two central aspects of awareness support: event distribution, and event presentation at the interface. LinkWorks already supports a rudimentary form of events. These are simple text strings. This form of event is completely insufficient for more advanced forms of perceptualization. LinkWorks does not support user-defined dynamic data structures, thereby preventing the definition of an adequate event type. It does not support subclassing of the existing event data structure to implement additional functionality as well. In fact, events as well as many other data structures are not modeled as objects at all. Finally, encoding additional information in the event string and providing a parser to access it is also impossible because LinkWork's support for string manipulation is much too limited. Extensions of the LinkWorks user interface suffer from the same problems: while the different dialog boxes can be invoked programmatically, the information they display is simply not available in other form. For example, LinkWorks provides a dialog box displaying a list of the users that are currently logged into the system. The programming interface provides a function to display this dialog. However, implementing a modified dialog would require access to the underlying data structure, which is not supported. This restriction applies for almost all information that is relevant to the awareness service. Therefore, an improved awareness service for LinkWorks either had to omit functionality, accepting the restrictions imposed by the insufficient programming interface, or substantial parts of LinkWorks functionality had to be re-implemented. For PoliAwaC, only the second approach was viable. This was the only way to meet the ambitious design goals specified before. However, this approach also has severe drawbacks: first of all, it contradicts the decision to choose LinkWorks as the base platform in the first place. Implementation costs Implementation 123 increase dramatically, and so does the communication overhead between different system components. System consistency is compromised by the need to replicate information. During the course of the project, an extensive exchange of ideas between the POLITeam designers and the LinkWorks designer group at Digital took place (cf. Section 7.7.8). The aforementioned problems of the LinkWorks API were discussed and acknowledged by the LinkWorks development team. In fact, future versions of LinkWorks will address most of these problems by extending or modifying the programming interface. However, while this is a positive development in the long term, it is of no value for the implementation of PoliAwaC, which is necessarily based on the current, insufficient version. 7.6.2 Architecture PoliAwaC is based on a centralized client/server concept as the underlying LinkWorks system. However, all components of the base system-client, server, and database- had to be duplicated. Not only had these additional components to be developed, but all of them, both the original versions and their new counterparts, had to interact at runtime to form a working system. This increased complexity and the resulting communication overhead had severe consequences for the software development and maintenance costs as well as for the runtime performance of the overall system. Cl Li lient nkW ie C n o aC r t ,3&#&RQQHFWLRQ Si w ks C oliA l d P ient e Netw ork Se PoliAwaC LinkW orks r Server v Server er Side Figure 7-14. PoliAwaC system architecture The new client, providing new awareness functionality, has to interact with a running old client to access any interface-related LinkWorks function. This is a result of the LinkWorks API that provides access to interface functionality through an interprocess communication protocol with the original client window. The necessity to run both clients in parallel had both a negative and a positive aspect. On the negative side, the additional client required additional resources, and two different client windows are confusing to users. This second problem was addressed by the new client controlling both its own windows and the windows of the old client. After startup, all windows of the old clients are automatically hidden from the user by minimizing them and 124 The POLITeam Awareness Service placing them beneath windows of the new client. On the positive side, the fact that the original client was running in the background provided a safety fallback in the case of a critical failure of the new client: users could quickly restore the original client window and resume work. The new server collects and distributes awareness information (see Fuchs, 1997 for details). It interacts both with the old server to access object information, and with the additional database storing events. Both clients have to interact with both servers to access groupware functionality and shared objects on the one hand, and to generate or receive event information on the other hand. Figure 7-14 summarizes the different components and their communication paths. 7.6.3 Object Model The awareness pipeline model described in Section 4.6.1 was the central design guideline regarding the necessary components of the awareness service. Therefore, the implementation had to provide these different components as identifiable objects. Moreover, it had to fulfill several basic design criteria: * Extendability: To allow testing and evaluation of different presentation techniques, additional perceptualization mechanisms should be easy to integrate, without having to change the underlying system. * Exchangeability: In accordance with generally accepted principles of software design, the interface parts of the awareness service should be separated from the non-interface parts. This separation allows the exchange of the basic groupware mechanisms, while retaining the user interface31. * Compatibility: The implementation had to be compatible with the programming interface of LinkWorks. * Functionality: The implementation had to fulfill the functional requirements defined by the awareness pipeline model and the perceptualization framework. All of these requirements call for an object-oriented implementation of the system. The first two issues are almost classical advantages of the object-oriented approach. The internal programming language of LinkWorks as well as its API are already oriented on an object- oriented language (namely C++). Finally, with a design model identifying specialized objects to perform part of the system's functionality, an object-oriented realization is the most straightforward approach. Therefore, the system was implemented in C++, providing different class hierarchies for the user interface, abstract awareness functionality, basic groupware functionality, and server functionality. The implementation totaled to approximately 70.000 lines of code, many of which were needed to replicate basic LinkWorks features. The system was designed in such a way that central data structures can easily be substituted. In the current implementation, the system is used to interact with the LinkWorks base system. 31 Of course, it also allows the exchange of the user interface while retaining the basic groupware mechanisms. While this option is more prominent in literature, in our case the user interface is the more interesting and stable part of the system. Evaluation 125 However, all LinkWorks-related functionality has been encapsulated in a separate class providing a well-defined programming interface. An additional class encapsulates the awareness server functionality. The implementation of these classes could easily be substituted to provide the same awareness mechanisms to other systems. For example, the Windows operating system provides similar base functionality than LinkWorks (i.e., file sharing and document management). Substituting the functions accessing basic groupware functionality and providing a corresponding awareness server would result in a file manager application with additional awareness functionality. Functionality which is not supported (e.g., the workflow management features) would simply be mapped to empty functions. This way, the interface to the otherwise collaboration-unaware operating system could be modified to support cooperative work in a much better way than before. In the same way, the system could be adapted to support other groupware tools like Lotus Notes, MS Exchange, or the BSCW system. In any case, it suffices to provide an appropriate awareness server and a new implementation of the basic groupware module. 7.7 Evaluation Any user interface design is questionable without proper evaluation. Despite the fact that groupware evaluation is extremely difficult, PoliAwaC went through an extensive evaluation phase. To gain qualitative results regarding its functionality, a set of different approaches was used. These included workshops and field tests with different user groups. 7.7.1 Problems of Groupware Evaluation Software evaluation is difficult. This is even more true for the evaluation of CSCW applications. While the appropriateness and usefulness of single-user applications can at least partly be tested with few users in limited time and in a dedicated test environment, this is not possible for groupware. "Users can be tested in a laboratory on the perceptual, motor and cognitive aspects of human-computer interaction that are central to single-user applications, but lab situations and partial prototypes cannot reliably capture complex but important social, motivational, economic, and political dynamics" (Grudin, 1994). Groupware applications depend heavily on the interdependencies and interactions between users, in addition to the interactions between the users and the software (Salvador et al., 1996). Cooperative work situations are difficult to simulate because the roles of several users have to be carefully designed. Even by doing so, any simulation may still fail to capture the real work dynamics present in the workplace because users do not work as expected by the designers. For example, this is the case if the test situation is designed after an organizational handbook that users fail to observe in practice. In this case, the evaluation simply tests a situation that is irrelevant for actual cooperation of the intended users. However, designing the test situation after actual work practice is extremely difficult as well: users may not even be aware of these work practices because they build on tacit knowledge (Kyng, 1991), or they may be hesitant to 126 The POLITeam Awareness Service admit they do not follow organizational rules. The sensation of being in an artificial laboratory situation may change users' behavior as well. Moreover, while most single-user functionality can be tested in a short period of time, cooperation may span a much larger time interval. This is particularly true for asynchronous cooperation. While one user is working, others have to wait, resulting in a difficult situation for laboratory tests. An obvious solution for all these problems is to test the software in the application field. Unfortunately, this approach has a variety of associated problems as well (Rowley, 1994). First of all, control over the experiment is not as rigid as in a laboratory condition. Intrusion into the users' working places should be minimal to avoid users feeling like being tested. Even worse, evaluation in the field implies that users actually work with the system to be tested: this prevents the usage of prototypes, let alone mock-ups. Since users are supposed to accomplish real work to provide relevant evaluation data, the system has to actually support them in this respect. Users will not accept limited functionality or reliability. Therefore, a complete set of functions supporting users' work has to be provided, even if it is totally unrelated to the features to be evaluated, and the system has to ensure a high degree of reliability (cf. Cool, Fish et al., 1992 p. 31). Both aspects are rather difficult to achieve in a research environment. A final problem is that for any groupware application to succeed, a critical mass of users have to adopt it (Ehrlich, 1987). To some extent, this argument is valid in the evaluation situation as well, because otherwise the features to be tested might simply go unnoticed. However, including a large number of users in the test increases the problems discussed before. 7.7.2 Approach We chose a combination of different approaches to evaluate the awareness features of PoliAwaC. We were interested in qualitative rather than quantitative results. We wanted to gather general impressions and gain insights into improvements and changes in users' working styles induced by the software, rather than statistical numbers on the usage of the different interface elements. Great care was taken to implement the necessary basic groupware functionality to allow evaluation of the prototype under real-life conditions. We expected this form of evaluation to be most, in particular because there is no evidence of real-world evaluations of systems supporting awareness in CSCW literature. Our approach was six-folded: 1. Several workshops were organized to present PoliAwaC to project members that were not involved with its implementation, but used to work with the original system. 2. In the same way, a workshop was used to present the system to selected pilot users. 3. PoliAwaC was used as a working tool by the project group members over a period of eight weeks. 4. A group of selected pilot users worked with the system for a duration of three weeks. 5. Pilot users not taking part in the field test were given a presentation of the prototype and its functionality in their working domain. Evaluation 127 6. The system was presented to the designer team of the original LinkWorks product from Digital. Each of these different steps served different purposes and provided different results. We will detail each approach, its methodology, its goals, and its results in the following sections. In the discussion, we will concentrate on evaluation results regarding the improved user interface and perceptualization mechanisms. Additional details on the evaluation of interest contexts and extended groupware functionality of the prototype can be found in (Fuchs, 1997) and (Syri, 1997a). 7.7.3 Project Members Workshop During the development of the system, two workshops involving the project team itself were conducted. In both cases, the designers of PoliAwaC demonstrated the system to a group of four to five project members. In the first workshop, participants were computer scientists with a more technical inclination, while the second workshop included non-technical staff, e.g. sociologists and psychologists. Workshops lasted from 2.5 to 3 hours. The purpose of these workshops was to analyze system functionality. The main design issues that were discussed were completeness in terms of awareness support, ease of use, and the integration of additional functionality into the existing system. The general opinion was that the design goals of PoliAwaC-broad support for awareness in an intuitive extension of the standard desktop metaphor-had been met. One participant observed that effective awareness support is achieved by a small set of unobtrusive and simple mechanisms. However, a major issue in the second workshop were privacy issues which were discussed controversially. In particular, it was criticized that the event history displayed all events concerning an object, even those that took place in a private workspace. It was suggested that all events happening in a private workspace should be collapsed to a single "object was modified" entry in the history to ensure privacy. This feature was consequently implemented and was part of the system used for further evaluation steps. Details on the actual usage of the system by the project group members will be discussed in Section 7.7.7. Since the workshop took place a month before the following evaluation phases, other suggestions for improvements could also be considered for the final design. However, almost all of these minor changes were concerned with the look-and-feel of the application rather than with concrete functionality, which was generally considered to be adequate. 7.7.4 Ministerial Users Workshop Prior to the field test in the ministry, prospective users were introduced to the system in an extensive workshop. Participants of the workshop were three test users, three system developers that presented new functionality, and two additional project members that observed and documented results. Each user had access to a workstation running PoliAwaC to allow hands-on experiences during system demonstration. During these experimenting phases, each user was assigned a system developer for individual assistance. The atmosphere of the workshop was intentionally chosen to be rather playful and relaxed, allowing users to express their true impressions more easily. The duration of the workshop was half a working day 128 The POLITeam Awareness Service (approximately 5 hours). The workshop was video-taped to allow detailed retrospective analysis. The workshop had two main goals: on the one hand, it was intended as a tutorial for the prospective users of the system. On the other hand, it should be tested whether users easily understood the principles behind awareness support in general and the usage of PoliAwaC in particular. Our assumption was that the intuitive nature of the PoliAwaC interface, in combination with its groundedness on well-known metaphors should allow users to easily work with the system and take advantage of its improved functionality. In fact, this proved to be the case. A short working scenario introducing most new system features was prepared to encourage users to actually work with the system. However, it turned out to be unnecessary: users established and tested short scenarios on their own ("What happens to your document icon if I change this document? ") without needing further incentive. It was extremely helpful to allow users to observe others' screens during their tests. For example, one user created a new object, which resulted in a series of notifications on the display of another user. Since users were sitting side-by-side, this gave them the opportunity to directly observe the consequences of their own actions on the screen of another user. This greatly facilitated understanding of the basic ideas and concepts of providing awareness information. As soon as a new feature was mentioned by the developers, users tended to experiment with it without paying further attention to additional explanations. While this showed that the new interface is in fact intuitive, it also led to some misconceptions about the system that were difficult to eliminate later. Users were impressed by the additional possibilities of the improved system. The awareness features that were commented most favorably during the workshop were the icon enlargement feature because it was considered to be easy to spot and interpret and the option to get a detailed object history because it allowed users to get a fine-grained track on object changes. This shows that users considered different aspects to be most important for synchronous and asynchronous presentation of awareness information: for the former, it was the ease of perceivability, while for the latter it was the level of detail actually presented. Users also welcomed the option to easily send short messages via the event bar. However, it turned out that they considered this mechanism to be a form of "email light" instead of the object-related information source it was designed to be. 7.7.5 Ministerial Work Practice To test awareness functionality in the application domain, a field test was subsequently conducted in the federal ministry. Three users were equipped with the new client and worked with the system for a period of three weeks32. The limited number of test users, and the limited time span of the test, were a compromise between projected benefits and costs. On the one hand, we strove for expressive evaluation results, while on the other hand, disturbances of 32 A fourth user from the technical department of the ministry also had the system installed. However, this user did not cooperate actively with the other users. Evaluation 129 users' work had to be considered, as well as the increased installation and support overhead for the project team. Test users were carefully selected for their cooperation potential. Moreover, care was taken to avoid the "critical mass" problem (Grudin, 1994), in this case the problem that a limited number of users does not generate enough events for a proper evaluation of the system. The POLITeam client of all users not directly participating in the test was modified in a way that they also generated events. This modification was transparent to users-it did not result in any noticeable changes in system behavior. Nevertheless, users were advised that their actions in shared workspaces would be visible to the evaluation participants during the test period. Test subjects were given an extensive introduction to the new system in a dedicated workshop (cf. Section 7.7.4). Moreover, subjects were shortly trained on the usage of the system at their workplace after installation. During the test phase, the new client was used as a complete replacement of the old system to accomplish normal, everyday work as described in Section 7.1.3. During the test, the system designers were constantly available for help, advice, and discussions on the system. After the test, interviews based on a semi-structured questionnaire were conducted. These interviews lasted from 30 minutes to 1.5 hours and included questions on system usage, on changes to the cooperation process, and on the perceived usefulness of new system features. Goal of this evaluation phase was to test whether the improved support for group awareness actually led to improvements in the cooperation of the group, and how the different interface elements would be used in practice. Our speculation was that positive effects should be quite noticeable, by using both synchronous and asynchronous perceptualization mechanisms. It turned out that in general the benefits for user cooperation, while observable, were not as highly visible as expected. This may be attributed both to technical problems of the prototype, and to the rather un-cooperative working style in the ministry. Regarding technical problems, the field test was hindered by an expected problem with unforeseen ramifications. This problem was the maturity and reliability of the prototype. Since this is a well-known issue in groupware evaluation (cf. Section 7.7.1), the prototype did in fact include all features supported by the original client that were actually used in the ministry. However, some of these features were implemented differently than their original counterpart. Partly, these were deliberate design decisions, but there were also subtle differences resulting from negligence on the designers' side. We overestimated users' ability to find workarounds if a function did not work as expected. While this is common practice for experienced users with extensive knowledge of different computer applications, our test users tended to simply assume that the particular function was not available, resulting in a negative overall rating of the system. To our surprise, users were also surprised by changes in functionality that were the very reason of the evaluation and had been discussed extensively before. Moreover, users' ability to accept limitations in overall system performance was restricted as well. For the evaluation, this resulted in the problem that users concentrated on reporting basic functionality problems, instead of the actual relevant research questions. It became apparent that users regard the system as a tool to accomplish their daily work, and are heavily disturbed if this tool does not behave exactly as before. Users' focus still lay on doing their work rather than evaluating the 130 The POLITeam Awareness Service system. They relied on work practices acquired through the use of the old system version. In case of problems or discrepancies, they did not search for alternative solutions but rather simply complained about it. These problems by no means resulted from user unwillingness to work around problems, but rather from their inability in doing so. These effects were clearly noticeable, although they varied with users' degree of computer experience. Note that users were well aware of the fact that the test would be performed with a research prototype which would not offer the reliability of a commercial product. In fact, they indicated to have no problem with this approach, stating they would "work around problems". Obviously, this was another, rather unexpected facet of the problem that users cannot judge systems until they work extensively with them (cf. Section 7.3), doing their regular work. Note that it would have been almost impossible to circumvent these technical problems. Either, the necessary implementation expenses would have been prohibitively high, or there was no technical solution at all. User assessment of awareness functionality reflects the highly asynchronous nature of ministerial work as described in Section 7.1.3. Most features supporting synchronous awareness were rated as being of minor importance. Features to present the activity of others while working with the word processor were not used. The nature of ministerial work in fact discourages the use of these features: users tend to work individually; very few synchronous events were actually reported. As a consequence of the basically asynchronous nature of ministerial work, the features supporting asynchronous awareness were generally judged more favorably. Both the event bar and the enhanced icons were used to spot and identify areas of previous activity, thereby speeding up coordination and cooperation processes. One user, returning after a few days of absence, was impressed by the system's ability to visualize where others worked during this time. This made it much easier to catch-up to current working processes. However, the different colors used to indicate users were not interpreted actively, and neither were the overlaid activity indicators. Due to the limited number of participants in the test group, users knew implicitly who was responsible for a document change. 7.7.6 System Demonstration During the field test in the ministry, the opportunity was used to present the system to users not actively participating in the evaluation. Four users were given an individual demonstration of the system, and were interviewed on their impressions afterwards. Furthermore, users could experiment "hands-on" with the system. Demonstrations lasted from 30 minutes to 1 hour each. Since the demonstrations took place at the users' workplace, they could observe and judge system functionality in their own personal working environment. This allowed direct comparison of old and new system functionality. The demonstration aimed at judging users perception of improved awareness support. We supposed that users would welcome the new functionality and see the benefits for their own work. This was only partly the case. All users agreed on the potential usefulness of the corresponding features. However, some users commented to have no need to see others' actions because their work only involved individual activities. Others were more favorable: particular Evaluation 131 highlights were icon enlargement33 allowing easy perception of changes, the detailed object history, and the option to automatically select a working object following an event notification. However, one user was concerned about the event bar taking up space of the word processor application. Interestingly, demonstration subjects were more concerned about privacy issues than users involved in the actual field test. Probably, their partially lower hierarchical status made them suspicious that awareness features could be misused by their superiors for control purposes. One user commented that although he had no problems with the awareness features, he would like to get feedback if someone observed him. 7.7.7 Project Field Test A complementary evaluation of PoliAwaC took place in the POLITeam project group itself. The original POLITeam system was used by the project team as a tool to support cooperation in the group. During the course of the project, its frequency of use decreased due to several problems, including its poor integration with the rapidly changing computing environment, its poor performance, and missing functionality including awareness features. The system was still being used, but merely as a shared document repository. PoliAwaC was used extensively by six project members over a period of eight weeks. Three of these users were the designers of PoliAwaC, while the others were completely unrelated to its design and implementation. Three additional users had the system installed but only performed a cursory test of its features, either because of time constraints or because of limited need for cooperation during the evaluation time period. All test users participated in a workshop (cf. Section 7.7.3) where basic system features and functionalities were explained. Furthermore, users were given a short individual training session after installation. During the evaluation period, help and assistance by the system designers was constantly available. The system was updated twice during the evaluation to correct errors that showed up in the test. The system was used to accomplish actual work needed by the group. This included the production of a series of scientific papers, each of which had several co-authors. There was a high demand for awareness functionality because there were strong interdependencies between the various authors. It is important to note the similarities and differences to the users in the ministry. While the basic task (joint paper production) was quite similar, the actual division of labor was much more flexible in the project group. The need for coordination of an otherwise unplanned cooperation was much higher as well. Since the project members were experienced with computer applications, their ability to cope with software problems and to find workarounds for missing functionality was highly developed, in contrast to the relatively inexperienced ministerial users. Also, due to their professional background, they were much more willing to experiment with new and unusual system functionality. It should be noted, 33 Interestingly, icon enlargement was judged positively not only as an awareness mechanism but as a single-user interface feature as well. As a byproduct of the scaleable icons feature, the whole object tree can be increased to up to 400% of its original size. This option was highly welcomed by a myopic user: "Finally, I can recognize the different icons". 132 The POLITeam Awareness Service however, that the "user advocates" participated in the evaluation, who tend to include a ministerial users' perspective in their judgment of systems' features (Bentley et al., 1992). Therefore, appropriateness of the system for ministerial use was not completely out of focus during this phase of the evaluation. After the test period, participants were interviewed. The interviews were semi-structured, based on a two-page questionnaire containing questions on the general user interface, the awareness features in the user interface, the definition of interest contexts, and on differences and improvements in work style resulting from the use of the system. Interviews were conducted by 1 or 2 interviewers and lasted from 45 minutes to 1.5 hours. Usage of the system continued after the evaluation phase, however these additional results are not reflected in our discussion. The goal of this evaluation phase was mainly the same as that of the ministerial field test: to test whether awareness support increases cooperation quality, and to observe which interface elements are accepted best and contribute most to the positive effects. Again, out hypothesis was that substantial improvements should be observable. More than in the ministerial field study, this turned out to be the case. The following discussion is based mainly on comments from test users not actively involved in the design of PoliAwaC. Comments of the systems' designers had to be considered with care, because they tended to be biased in favor of their design decisions. All users commented favorably on the improved interface. This included both general interface aspects and awareness functionality. In comparison to the old client, users judged PoliAwaC to be an "obvious improvement". One user commented that increased awareness led to shorter reaction and turnaround times for urgent tasks, and that it had a reminding function for pending activities in long-term tasks. Users particularly noticed that coordination on the usage of shared documents improved. In contrast, there was no noticeable effect on informal communication. The latter probably results from the fact that users' were closely located on the same floor in neighboring offices where informal communication happens all the time, without any need for computer support. Users reported to use the awareness features "extensively". Users defined interest both in object classes as well as in specific object instances. However, they tended to use high levels of intensity ("to be sure not to miss something important"), and to use immediate notification instead of more elaborate schemes. One user missed automatic increases in intensity as deadlines for tasks come closer. The presentation of awareness information on the object icons was perceived as being highly useful. Users found the enlargement of icons in the tree display to be most noticeable. The propagation of events in the hierarchy was used to navigate to the modified object. Coloring and overlay icons were noticed, but users reported problems in matching colors to users, desiring a stronger reinforcement of the mapping in the user interface. One user criticized the automatic resetting of the icon after object selection, claiming it would be useful to allow users to decide how long the notification remains visible. The perception of changes in the client while working with other applications did not work as expected. Users tended to start applications in the maximized mode (i.e., with the application window using the entire screen area), thereby totally hiding the client window. One user Evaluation 133 commented that this was no problem because he could easily spot any changes as soon as he switched the PoliAwaC window to the foreground, while the dialog box popping up for important events ensured that he did not miss any critical events while working in Word. The use of non-visual cues (e.g., sound) could also help in this situation. The use of the event bar as a stand-alone window was not used in the intended way as well. While users experimented with the feature, they found it difficult to invoke and to get feedback about its current status. However, this seemed to be more a problem of the particular implementation than of the feature itself: "it didn't work, but it's the right idea in principle". Figure 7-15. User suggestion for pending message display Users had most problems with the event messaging feature. While it was consensus that this is a highly useful functionality in theory, it was felt that the implementation had a major flaw. Neither did the system ensure that messages were actually read by others, nor did it acknowledge read messages in any way. Therefore, users felt highly unsure if their messages actually reached the intended recipients, and finally stopped using the feature to use more conventional forms of communication. A suggested improvement was the addition of a graphical comic balloon to objects with a pending message (Figure 7-15), a feature quite similar to the stick-up note display in DIVA. The color of the "text" in the balloon indicates the user who sent the message, while the balloon icon itself can be used to interact with the message. Another solution would have been the introduction of an event describing the reception of an event message that could have been transmitted back to the originator of the message. The implicit link of a message to a specific object was something users were unsure about as well. One user commented the current interface to be "clumsy" and suggested to start the sending of a message via the object context menu to reinforce this linkage. 7.7.8 Designers Workshop As a final evaluation step, the prototype was demonstrated to the LinkWorks design team from Digital. This demonstration again had the form of a workshop with open discussions. Participants were members of the POLITeam project group and five members from the LinkWorks development staff, including product and technical managers. Goal of this workshop was to evaluate whether the concepts implemented by PoliAwaC would be considered as an interesting option for a commercial product by a team of industrial designers. It showed that the solutions for awareness support offered by PoliAwaC are not only of academic interest, but are highly relevant for commercial systems as well. Awareness support of the new client was vividly discussed. LinkWorks designers were interested in learning that users actually demand corresponding functionality and effectively use it to improve their cooperation. The complete array of perceptualization mechanisms and the model of interest specification were considered to be highly useful. However, the model 134 The POLITeam Awareness Service was judged to be too complex to be integrated into the system in its entirety. Nevertheless, single interface elements, like the indication of awareness information on the object icons, were considered to be interesting candidates for inclusion in future system versions. In particular, the event propagation mechanism in the tree display, allowing users to spot activities even if the corresponding objects are hidden deeply in the object structure, was considered to be highly useful. 7.7.9 Summary of Evaluation Findings Parts of the evaluation turned out to be more troublesome than expected. While some difficulties were anticipated, their actual gravity only became visible during the test. In particular, reliability of the prototype, resemblance to the old system, and performance issues had all been carefully considered during the implementation, but were still major topics of user complaints. These problems simply could not be solved satisfactorily: with limited time and man power, it is impossible to introduce a completely new system with complex functionality that is fully accepted by users to replace their old computer work practices. The effort was justified nevertheless: the evaluation produced valuable results, which would have been impossible to gather without a test in the actual application domain. The system was used to accomplish routine work instead of artificial test scenarios. Therefore, users observed the benefits and drawbacks of awareness mechanisms in their actual working environment, and they reported on the improvement of their cooperation on real-world problems. Moreover, the field test was useful to shift the perspective of the systems' designers to that of the actual workplace. Aspects that were considered to be highly important during the design phase were observed to be negligible in the application field, while seemingly minor details turned out to be extremely important. Generally, users accepted the new awareness features. They were seen as a benefit to their work. They did not hinder users in any way, nor was the display of information considered to be disrupting. After the evaluation period, users were disappointed to learn that the enhanced features could not be integrated easily into their standard system. Most of the perceptualization mechanisms supported by PoliAwaC were judged to be useful. Nevertheless, the evaluation also showed that there is ample room for improvement. A few interface elements did not work as expected, and others could be improved by minor design changes. Table 7-4 lists the different perceptualization techniques, their perceived benefits and drawbacks, and potential design improvements. Regarding general awareness functionality, particularly effects on asynchronous cooperation were noticeable. The detailed object history was considered to be necessary to settle accountability and responsibility issues. The passive perceptualization techniques-icon modification, structural overview, event bar-were commented to be highly useful for catch- up. In this cases, it was not the exact, detailed information that was relevant, but rather spotting where activities took place was enough; details were completed implicitly by the users. There was only one general aspect users complained about: missing feedback about others' observing one's actions. Adding such a mechanism would support the use of social protocols to prevent privacy violations. Evaluation 135 Feature + - Design change Awareness support Improved cooperation Privacy concerns Feedback on observation by others / aggregation to anonymize data Workspace Views Tree view Improved navigation / Sorting of objects Allow user-defined Browsing facilities structuring Icon enlargement High visibility and context information Event propagation Locating of changed objects Minimized side display Not used Facilitate usage / implement as transparent layer Synchronized icon/list view "Best of both worlds" Tendency to use one view only Icon color Mapping user-color difficult Reinforce mapping by constantly showing user colors Elapsed time indication Difficult to differentiate/ interpret Overlay icon Activity indication Event windows Event bar Event representation Iconic and textual form History drop-down list Overview on current activities Event message sending Easy to use for short No feedback for sender and Indicate pending message messages recipient / on object icon / Link to object is unclear Change operation invocation Use as floating window Window space Minimize window area/ consumption/ Improve user interface Difficult to invoke Short-cut buttons Direct link event/object Difficult to identify button Reduce number of buttons functionality Event dialog Ensures event reception History window Record of past object activities/ accountability User representation In tree view Overview on workspace No indication of inactive Include inactive users in activities users34 display In status line Easy spotting of current workspace users Interest definition Flexibility Complex user interface More default configurations Other interface improvements Context menus Quick operation invocation Feature is constantly More user training overlooked necessary Improved drag&drop operations Facilitated object handling In-place attribute editing Object-related attribute Difficult to invoke Change invocation method editing Table 7-4. Summary of PoliAwaC interface evaluation The single most prominent perceptualization mechanism was the icon enlargement feature in combination with the structural overview display. This application of spatial distortion provided immediate access to changed objects while retaining contextual structure information. In a workshop conducted two month after the field test, users were asked about their lasting impressions from the test of PoliAwaC. They remembered particularly well the enlarged icons 34 This feature was planned for the prototype, but was not implemented due to difficulties of the base system in providing the necessary information. 136 The POLITeam Awareness Service indicating object modifications. This indicates that the basic design assumptions regarding this feature-icon enlargement being an easy to learn, easy to notice, non-disruptive, background presentation mechanism-are valid. The unobtrusiveness of this approach in combination with the less detailed, non-verbal background display of change information on object icons also weakened concerns about privacy violations. In general, the mechanisms provided were considered to be well balanced between perceptability on the one hand and unobtrusiveness and conservation of privacy on the other hand. The most obvious design flaw was the active entering of messages in the event bar. While this feature was generally considered to be highly useful, the implementation is unsatisfactory. Since users were unsure if their messages actually reached the recipients, users discontinued use of this feature. However, this problem could easily be addressed, for example by showing pending messages on an object icon as discussed before. In summary, evaluation of the system showed the feasibility of the approach. Awareness support in fact increased cooperation effectiveness by allowing implicit coordination. Usefulness varied with the prevailing working style of the users. If there are more interdependencies between individual work, awareness support becomes more important. It is possible to incorporate the presentation of awareness information into standard interfaces without changing their overall nature. A carefully designed array of simple presentation mechanisms is suitable to cover the most demanding aspects of awareness support and perceptualization. 7.8 Other Approaches PoliAwaC is not the only improved interface design developed for the POLITeam system. During the course of the project, a set of different interfaces, using different approaches, were implemented. The alternative interfaces included a simple predecessor of PoliAwaC, a web- based solution relying on HTML features, and a virtual reality approach based on 3D-modeling of the environment. It should be noted that there is no "best" interface. The mere existence of such a variety of interfaces to the same system, developed over a relatively short distance of time, makes clear that there is no optimal solution fitting all work situations and user requirements. Instead, each of these interfaces has its own merits and limitations. We have discussed theoretical aspects of these different approaches before. In the following sections, we will briefly describe strengths and weaknesses of the different approaches when applied to the same base system. In particular, we will discuss why none of the alternative interfaces was deemed to be usable in the ministerial application domain. Again, this emphasizes the limited possibilities for user interface improvement for a system used in an actual working environment. Other Approaches 137 7.8.1 Context Dependent Notification for Shared Workspaces An early prototypical predecessor of PoliAwaC, based on the same basic concepts and requirements, is described by Rauschenbach (1995). The system was developed to increase users' awareness while working with shared workspaces in the POLITeam system. It provides varying forms of perceptualization depending on a user's working context. Working contexts are defined by open containers. Users may specify interest in specific event types occurring in a shared workspace, and associate different presentation intensity levels with them. Due to technical problems with the base system (cf. Section 7.6.1), the implementation had to make several compromises regarding the envisaged functionality. In particular, the difficulty to extend the LinkWorks user interface led to severe inconsistencies between the additional awareness features and the rest of the system's functionality. Shared workspaces are implemented as special tools that may be opened from the standard LinkWorks desktop. The system displays these shared workspaces in dedicated windows. Users of a shared workspace are displayed as special objects contained in the workspace. Basic functionality of shared workspaces is highly limited: only one predefined type of documents and folders each is supported, and only few LinkWorks operations are available. The system provides two basic forms of perceptualization35: the modification of an object's icon, and a modal dialog box displaying either all events related to a shared workspace, all events applying to a specific object, or new events arriving with high priority. The same dialog is used both to display an object's history and to alert users to new events. Events are optionally propagated along the container hierarchy. The icon modification includes the use of different colors to indicate the time elapsed since event generation, and the overlay of additional sub-icons to indicate event type. The usage of discrete colors to represent a continuum of time values is somewhat problematic; so is the use of colors without considering that the original document icons also use colors to differentiate between document types. This works for the prototype that only supports one document type, but it does not extend well to the general LinkWorks icon system. The system was implemented as a research prototype. While it could be used to demonstrate basic concepts and ideas, its limited functionality made it impossible to use or evaluate it under any real working conditions. 7.8.2 POLIWeb With the growing importance of the internet and the world-wide-web, the idea of providing a web access to the POLITeam system emerged. Interface design was not the primary aspect of the WWW gateway (called POLIWeb), but rather providing a general architecture to support groupware applications via the web (Freund, 1996). An adequate interface had to be provided nevertheless. The peculiarities of the standard web protocol, HTML, afforded an interface 35 The author discusses an additional perceptualization mechanism based an aggregated iconic display of event types. However, this mechanism was not implemented. 138 The POLITeam Awareness Service completely different from the original version36. Since the interface was completely decoupled from that of the original LinkWorks client, it could offer awareness features going beyond those of standard LinkWorks. The implementation of the WWW gateway was preceded by a user survey (refer to Freund, 1996 for details). A questionnaire was distributed and could be answered via the web gateway itself. The questionnaire included questions on the usefulness and practicability of a web access to a groupware system as well as questions on the desired functionality of such a system. A number of participants explicitly stated the need to be able to observe others' activities, i.e. they claimed awareness should be supported in the WWW medium as well. For the WWW interface, the contents of each container object (a user's desk itself is such a container) are displayed on a web page in list form, showing the object icons and other information supported by LinkWorks. Each object constitutes a hyperlink which either displays a new page in case of a container object or opens an appropriate helper application to display the contents of a particular document (Figure 7-16). While the interface supports most of the POLITeam functionality, there are some features that are not implemented. These include system administration facilities, which were not implemented because of time restrictions, and workflow support. Workflows are constructed using a graphical diagram editor in the standard interface, which is almost impossible to replicate in HTML. Figure 7-16. The POLITeam WWW interface The WWW gateway flags new objects or those containing unseen changes. Therefore, users can easily spot where activities took place after opening a container. The flag remains set while 36 At the time the system was developed, the use of Java to implement the interface was not an option. Reliable Java development systems were simply not available. Other Approaches 139 the corresponding window remains open; it is reset if the window is closed or reloaded. While this is a very simple mechanism, it still more than standard LinkWorks offers. The idea of accessing an existing groupware system via the world wide web was generally considered to be a very good idea by participants of the user survey. In fact, Digital, as the manufacturer of LinkWorks, adopted the basic concept of POLIWeb and developed a corresponding system that is marketed along with the rest of the LinkWorks product line. The very same concept is increasingly adopted by other groupware manufacturers as well to enhance their products. Nevertheless, this approach was considered to be unsuited to be used in the ministry. POLIWeb had two problems making it unacceptable in this domain. On the technical side, it did not provide full LinkWorks functionality, and its user interface left something to be desired. Worse, however, was a psychological problem: the confusion between a technical approach based on Internet technology and tools used on a LAN (nowadays called an Intranet), and the universal access to sensible data via the "real" Internet. Since users had difficulties in differentiating between these two approaches, the psychological hurdle for an Internet-based solution was simply considered to be too high. 7.8.3 Virtual Reality Interface Another experimental user interface to the POLITeam system was based on a virtual reality approach (England et al., 1996). The system consists of a combination of POLITeam with the DIVE system (compare Section 6.5). The POLITeam object structure of a user is translated into a VRML scene. VRML (Virtual Reality Modeling Language) is a web protocol for three- dimensional world, in contrast to HTML which describes two-dimensional page layouts (Bentley, Appelt et al., 1997a). The generated VRML scene in turn is interpreted by DIVE. Objects may be augmented with special 3D behavior (e.g., an animation for the opening of a folder) by adding appropriate subprograms. Figure 7-17. The POLITeam virtual reality interface 140 The POLITeam Awareness Service The interface is based on a three-dimensional room metaphor. Figure 7-17 shows an exemplary POLITeam desk in its virtual reality representation. Note the users' desk with graphical main in- and out-boxes on it, the waste basket, and the three-dimensional cabinets containing drawers and folders. Objects mimic their real-world counterparts: for example, cabinets and drawers can be opened, showing a corresponding animation. Users can navigate freely in the virtual world, manipulate objects, and work on documents. This approach, at least potentially, includes the extensive awareness support provided by the DIVE system: user representation as virtual actors, and object auras, foci, and nimbi coordinating the provision of awareness information. The system provides an interesting visualization of the cooperative environment. However, this approach was not suitable for use in the ministry as well. Again, there was a technical and a psychological problem. The technical problem was the insufficient hardware installed in the ministry (compare Section 7.5.1). Experiments with the system showed that it required workstations far more powerful than the typical ministerial PC to run smoothly. On the psychological side, there is an unacceptable gap between the virtual reality interface and the interfaces of the standard applications used in the ministry. 7.9 Conclusions To test their abilities as design guidelines, the theoretical awareness and perceptualization frameworks discussed before were applied to implement the awareness service of the POLITeam project. POLITeam is an ambitious project developing telecooperation tools for the distributed German government. A central design goal was the development of an event and notification service to support users' awareness of the cooperative environment. The project is based on an evolutionary design approach involving extensive user participation. The system is installed with a group of pilot users in a German federal ministry. This allowed both a survey of user requirements for an awareness service, and a practical evaluation of the implemented system. To realize the awareness service, a special client application replacing the original POLITeam client was developed. It is based on the project goals, user requirements, and design choices implied by the awareness and perceptualization frameworks. The awareness client integrates a standard GUI interface, a sophisticated event selection mechanism, and a variety of different presentation techniques both for synchronous and asynchronous work. The user survey as well as evaluation of the prototype showed that an awareness service is needed to allow easy coordination of work and to support the establishing and maintenance of conventions for system usage. The evaluation showed also that the prototype meets its basic design goals, and the validity of these goals. However, severe problems of introducing new software and concepts with rather conservative users became apparent as well. These problems become even more visible with some alternative interfaces developed for the POLITeam system. While being appealing solutions, they are unacceptable for use in the Conclusions 141 ministry for a variety of "real-life" problems: user reluctance to learn new functionality and interface techniques, inappropriate hardware, and immature software. . 8 Conclusions and Outlook "More sophisticated awareness mechanisms are required [...]." J. Bowers While awareness is generally considered to be crucial for the success of CSCW applications, there is still a lot of work to be done to make it at least as useful as it is in real-world cooperation. This is especially true for the integration of awareness information into the user interface of such applications. The different approaches discussed in this paper solve some of the most demanding problems in this area. Both theoretical and practical issues have been covered. We described theoretical frameworks for the process of creating awareness and the related user interface concept, the perceptualization. On the practical side, two systems focusing on awareness support-DIVA and POLITeam-have been implemented and analyzed. 144 Conclusions and Outlook In the following sections we highlight the different contributions this thesis makes to CSCW research, elaborate how it answers the different questions on awareness support listed in the introduction, and give a brief outlook into the future of user interfaces-which is characterized by ubiquitous awareness support. 8.1 Contributions Awareness of others' activities is an important concept for multi-user systems. However, neither the theoretical foundations of awareness support, nor the consequences and implications resulting from the usage of corresponding systems under real work conditions, have been thoroughly discussed in literature. Moreover, existing implementations of awareness functionality often address related problems in an ad-hoc or unsystematic manner. This thesis addresses all three issues-theoretical background, practical implementation, real-life experiences-, making important contributions to all of them. * Theoretical foundations: Regarding theoretical aspects of awareness support, the thesis provides three important contributions. First, it develops a design model for awareness services incorporating different important aspects that are often neglected by existing systems. These issues of privacy, adherence to legal and organizational regulations, and minimizing of the information load have to be considered in real working environments. Second, it elaborates a design framework for perceptualization as the main user interface concept of an awareness service. This framework systematically lists and discusses the different factors that have to be considered to adequately present awareness information. The different functional aspects are applicable to any form of user interface. A series of innovative concepts is introduced in the framework, in particular the importance of temporal and spatial distortion to support different aspects of perceptualization. Third, the general importance of awareness support is discussed. In particular, the thesis contributes to the ongoing discussion on the relation between awareness support on the one hand and the establishment and maintenance of conventions on the other hand. Conventions and awareness are dually related. Conventions not only allow substitution of technical solutions by social norms, but they are also necessary for users to make effective usage of shared resources. The provision of awareness information allows users to build and maintain conventions implicitly, much like real-world conventions. * Concrete realization: On the practical side, the thesis discusses the concrete implementation of two systems supporting awareness. Both systems extend the existing standard desktop metaphor. Therefore, the realized concepts can easily be transferred to other standard applications as well. The first system, DIVA, is a research prototype based on a virtual office metaphor; it shows in particular the integration of awareness information into a spatial metaphor, its combination with video conferencing, and detailed application-level support. In contrast, the POLITeam awareness client has been employed in a real working environment in a German federal ministry, and therefore focused on adherence to standard interfaces, and dedicated support for asynchronous work. This was achieved by building on Questions Answered 145 user interface elements of the existing client application: object icons display additional awareness information, a structural view displays overview on shared workspaces, and an unobtrusive floating window provides asynchronous information presentation and active information generation even if working with other applications. * Practical experiences: Since the POLITeam awareness client was actually used in a German federal ministry, user expectations and requirements regarding an awareness service could be gathered. Furthermore, the system could be evaluated under real working conditions. In contrast to most other systems supporting awareness, which either go unevaluated or are tested under artificial laboratory situations, this allowed important insights into the actual experiences, benefits, and drawbacks of awareness support in a real-life setting. Users explicitly demanded awareness functionality to observe what happens in the system. Once introduced, they profited from the awareness service; their cooperation improved due to implicit coordination mediated by the non-verbal awareness cues. The combination of different interface mechanisms with an elaborate scheme to define user interest proved to be highly useful and adequate to support users' need for differing degrees of notification intensity. On the other hand, it turned out that evaluation of a prototypical system in a production environment is a difficult chore: users expect too much in terms of reliability and adherence to standards defined by previous system versions. All these results are not just of academic interest, but are highly relevant for practical purposes as well. The concepts discussed and implemented can easily be transferred to other applications. This is evidenced by the fact that the developers of a commercial groupware system expressed interest in these developments to incorporate awareness support in their product. 8.2 Questions Answered Awareness support for multi-user environments is a sophisticated problem, involving a wide range of aspects that have to be considered. This thesis discusses these different aspects extensively. In the introduction, we have listed a set of questions that we have dealt with throughout the thesis. In the following, we will re-examine these questions and discuss the contributions that were made to each of them. * Why is awareness important in multi-user environments? The most important form of multi-user environments is groupware: system supporting the cooperation of users (Chapter 3). Awareness is necessary for all forms of cooperation (Chapter 4). It provides a shared context that is essential for several reasons. First, observing the activities of others allows users to coordinate their work. Even if users are engaged in seemingly individual tasks, awareness may still be important to provide a background for fine-tuning own activities. Second, perceiving others' location and communication availability allows users to engage in informal communication, which has been shown to be highly important for cooperative work. Third, observing others' usage of the system allows the establishment and maintenance of conventions which are essential for efficient 146 Conclusions and Outlook collaboration using groupware tools. However, the provision of awareness information is inevitably coupled with a loss of users' privacy and potential disruption from their work. This tradeoff between positive and negative aspects has to be considered carefully in a given work situation. * How is awareness created? Awareness is a state of mind (Chapter 4). It cannot be produced by systems. Systems can only stimulate the necessary cognitive processes. Information regarding the essential aspects of others' activities has to be collected, distributed, and presented. Awareness information is all information targeted at answering the following questions: who did something, what did he do, how did he do it, when did he do so, why did he do it, and where did it happen. This information regarding originator, action, invocation, time, motivation, and location has to be stored persistently and made available through the distributed computer system. The information is gathered each time a participant of a cooperation performs an action on the common artefact. Presentation of this information at the user interface of other participants allows them to become aware of the originating action. The reception of an awareness information presentation is a user action in itself, allowing users to become aware of the potential awareness status of their cooperation partners as well. * How can the user interface support awareness? To become aware of others' activities, users have to perceive these actions. Therefore, presentation of these activities is a key factor of any awareness service. Awareness is not possible without presentation of the corresponding information at the user interface. The key interface concept in this context is the perceptualization: the act of making a user action perceivable to others (Chapter 5). This process may be repeated several times for the same action, depending on the working situation of a user. It involves two phases: selection and presentation. In the selection phase, information that is relevant to a user in a given working situation is selected. In the presentation phase, this information is actually presented to the user. The design of effective perceptualization mechanisms involves a wide variety of different aspects that have to be considered. * Which are the key factors for the design of an awareness service? Multi-user environments are socio-technical systems. The design of an awareness service therefore not only involves technical problems, but also raises social, organizational, and legal questions (Chapter 4). In particular, these social aspects have to be considered for systems to be used in an actual workplace. The awareness pipeline model can be used as a basis for corresponding systems. Awareness support involves a flow of information from the originator of an action to the receiver. On its way, this information is modified by a set of different components. A global filter ensures adherence to legal and organizational regulations. An individual filter controls outgoing information to support users' privacy. A second individual filter allows users to select incoming information based on their interests to prevent disruption and information overload. The user interface serves as a final filter in selecting and presenting awareness information. Moreover, all information is stored persistently in an event history to allow later retrieval and asynchronous presentation. Questions Answered 147 * Which are the key factors for the design of perceptualization mechanisms? The two aspects of perceptualization, selection and presentation, involve different design criteria (Chapter 5). For both phases, distortion is a key concept. Temporal distortion of awareness information allows asynchronous presentation of past activities. Spatial distortion allows compression of the information space by providing focused information while retaining context, thus supporting an overview of the workspace. For the selection of information, mechanisms to estimate the relevance of an information to a user are needed. These are optimally based on a combination of user-specified interests and automatic relevance filtering. Based on relevance, information can be suppressed, modified, or otherwise manipulated. Aural and in particular visual presentation are best suited for awareness purposes. The presentation model must include information not available in single-user environments: in particular, information about the users themselves as objects of the cooperation. Systems have to be built on adequate metaphors to facilitate presentation. Finally, different forms of reception of a presentation have to be covered: from completely unobtrusive forms to approaches that are impossible to miss. * How can corresponding systems be realized and what do they look like? Awareness support can be implemented using any user interface approach. We have discussed web-based applications, virtual reality solutions, and approaches based on the standard graphical user interface (Chapters 3 and 6). The world-wide web is particularly interesting because it already provides a distributed, connected environment with a well- defined interface for users. Due to limitations in its interface design capabilities, it is best suited for asynchronous work and asynchronous notification. Virtual reality is appealing due to its natural presentation and interaction metaphors; its inclination on real life makes is especially suited for synchronous forms of cooperation. The standard WIMP interface is of particular interest because it is the current de-facto standard supported by most systems and applications. Therefore, we have detailed the actual implementation of two corresponding systems: DIVA (Chapter 2) and POLITeam (Chapter 7). Their realization demonstrates the integration of awareness information in standard interfaces. DIVA is a research prototype based on a virtual office metaphor. It illustrates basic concepts and design solutions for an awareness service. In particular, it demonstrates the combination of a variety of mechanisms taking advantage of the spatial metaphor. In contrast, the POLITeam system is actually in use with several pilot partners performing "real" office work. Therefore, this implementation allowed requirement analysis, testing, and evaluation in an actual working environment. The system had to be concerned with reliability, standard functionality, and the integration of standard office applications to effectively allow users to take advantage of awareness features. * What are user requirements, expectations, and experiences when using these systems? Experiences made with the employment of the POLITeam system in a German federal ministry show that users in fact demand an awareness service to assist their work (Chapter 7). It shows also, however, that concerns about privacy violations, and fear of misuse of awareness features for surveillance purposes should not be neglected. Integration with standard office procedures and mechanisms is an important issue. The nature of cooperative 148 Conclusions and Outlook work has to be taken into account for the design of awareness facilities: highly asynchronous work increases the demand for asynchronous notification; synchronous notification is more important for synchronous work. A set of simple mechanisms, based on user interface standards and covering the different aspects of perceptualization, effectively increases users awareness and cooperation quality. In summary, we have explored awareness support and the necessary perceptualization process. These problems pose unique challenges to the designer of CSCW systems. We identified key issues and techniques that have to be considered to adequately design interfaces that support these processes. We believe that a more intensive and more conscious usage of these techniques will improve the usability of corresponding systems. Consideration of the design factors, concepts, experiences, and solutions discussed in this thesis leads to better interfaces for groupware applications and thereby to better computer supported cooperation. 8.3 The Future of User Interfaces User interfaces will change dramatically. There are many paths that future developments will follow. On the one hand, new input and output devices, in combination with adequate interaction and presentation techniques, will make better use of human sensorial and cognitive capacities, providing individual users with a more immersive experience while using the computer. Most of these developments are unpredictable. On the other hand, others can be extrapolated from current trends: in particular, the shift from single-user interfaces to multi- user interfaces. High speed, high capacity networks, increasing workstation and computer power, increasing social flexibility and distribution demand this new quality of user interfaces. Support for cooperation and social interaction using the computer is getting increasingly important both for entertainment and for productive work. These aspects are orthogonal to other user interface improvements, though improvements on one aspect may influence the design of the other. The ability of a user interface to support social aspects will become increasingly important; the presence of multiple users interacting through a network of connected computers has to be acknowledged by user interface designers. An essential component of multi-user interfaces is awareness support. Future user interfaces will include corresponding features regardless of their interaction and presentation mechanisms. Awareness support will be ubiquitous and inevitable. In fact, standard office applications like MS Word already begin to integrate corresponding features by allowing versioning and color-coded author annotations. However, most users will not be aware of its presence, because it will be unobtrusively integrated into the overall interface, and because it will be considered an integral part of the interface. Awareness support is necessary for different reasons. It provides information about others: their activities (allowing coordination of collaborative work), their status (allowing spontaneous communication), and their work patterns and styles (allowing the development of conventions). It allows the social integration of different people into the computer medium. While awareness The Future of User Interfaces 149 support may appear to be a threat to users' privacy, its very possibilities can also be used to alleviate this problem: by modifying and aggregating information, it may become sufficiently anonymous but remain useful for cooperation purposes. We have discussed the implementation and integration of awareness support into current standard interfaces. This is a sensible approach because these types of interfaces will remain in use for a long time. In particular, large organizations, being conservative to changes due to their very nature, will not adopt new, innovative interface concepts easily (as evidenced by the fact that text-based interfaces are still in use by many of these organizations). Nevertheless, the theoretical considerations and practical experiences discussed in this thesis are valid for any type of user interface: the basic ideas can be applied to the standard graphical user interface as well as to terminal based approaches, virtual reality, or any yet unknown future solutions. Not the concrete implementation, but its basic ideas are generally applicable. Awareness support not only helps mimicking real-life cooperation by providing the same cues that are available in this form of cooperation. It offers additional possibilities: information can be filtered, processed, rearranged, or synthesized; all these options are unavailable in real-life cooperation. Consider, as a simple example, (virtual) office walls that become transparent whenever needed to spot the activities of others. All this allows completely new forms of cooperation and social interaction to evolve. Awareness support not only allows computer-supported cooperation to become as good as real cooperation: it allows it to go beyond that. . 9 References "Words, words, words." W. Shakespeare, "Hamlet", II, 2 Ackerman, M. S. (1994). Augmenting the Organizational Memory: A Field Study of Answer Garden. Proceedings of the ACM Conference on Computer Supported Cooperative Work CSCW'94, Chapel Hill, NC, ACM Press, New York, pp. 243-252. Ackerman, M. S. and Starr, B. (1995). Social Activity Indicators: Interface Components for CSCW Systems. Proceedings of the ACM Symposium on User Interface Software and Technology UIST'95, Pittsburgh, PA, ACM Press, New York, pp. 159-168. Anderson, J. R. (1994). Cognitive Psychology and its Implications, W. H. Freeman, New York. Aytes, K. (1996). Comparing Collaborative Drawing Tools and Whiteboards: An Analysis of the Group Process. Computer Supported Cooperative Work (CSCW) 4(1), pp. 51-71. Bäcker, A., Genau, A. and Sohlenkamp, M. (1993). GINA++, The Generic Interactive Application for C++ and OSF/Motif. GMD, Sankt Augustin, Arbeitspapiere der GMD, 722. Beaudouin-Lafon, M. (1990). Collaborative development of software. Proceedings of the IFIP WG8.4 Conference on Multi-User Interfaces and Applications, Crete, North Holland, Amsterdam. 152 References Beaudouin-Lafon, M. and Karsenty, A. (1992). Transparency and Awareness in a Real-Time Groupware System. Proceedings of the ACM Symposium on User Interface Software and Technology UIST' 92, Monterey, CA, ACM Press, New York, pp. 171-180. Beck, E. E. and Bellotti, V. M. E. (1993). Informed Opportunism as Strategy: Supporting Coordination in Distributed Collaborative Writing. Proceedings of the Third European Conference on Computer- Supported Cooperative Work, Milan, Italy, Kluwer Academic Publishers, Dordrecht, pp. 233-248. Bellotti, V. and Sellen, A. (1993). Design for Privacy in Ubiquitous Computing Environments. Proceedings of the Third European Conference on Computer Supported Cooperative Work ECSCW'93, Milan, Italy, Kluwer Academic Publishers, Dordrecht, pp. 77-92. Benford, S., Bowers, J., Fahlén, L., Greenhalgh, C. and Snowdon, D. (1995). User Embodiment in Collaborative Virtual Environments. Proceedings of the Conference on Human Factors in Computing Systems CHI'95 (Conference Companion), Denver, CO, ACM Press, New York, pp. 242-249. Benford, S., Bowers, J., Fahlén, L. E., Mariani, J. and Rodden, T. (1994). Supporting cooperative work in virtual environments. The Computer Journal 37(8), pp. 653-668. Bentley, R., Appelt, W., Busbach, U., Hinrichs, E., Kerr, D., Sikkel, K., Trevor, J. and Woetzel, G. (1997). Basic Support for Cooperative Work on the World Wide Web. International Journal of Human Computer Studies, Special Issue on Novel Applications of the WWW. Bentley, R. and Dourish, P. (1995). Medium versus Mechanism: Supporting Collaboration through Customization. Proceedings of the Fourth European Conference on Computer Supported Cooperative Work ECSCW'95, Stockholm, Sweden, Kluwer Academic Publishers, Dordrecht, pp. 133-148. Bentley, R., Horstmann, T. and Trevor, J. (1997). The World Wide Web as enabling technology for CSCW: The case of BSCW. CSCW: The Journal of Collaborative Computing 2(3). Bentley, R., Hughes, J. A., Randall, D., Rodden, T., Sawyer, P., Shapiro, D. and Sommerville, I. (1992). Ethnographically-informed systems design for air traffic control. Proceedings of the ACM Conference on Computer Supported Cooperative Work CSCW'92, Toronto, Canada, ACM Press, New York, pp. 123- 129. Berlage, T. and Genau, A. (1993a). A Framework for Shared Applications with a Replicated Architecture. Proceedings of the ACM Symposium on User Interface Software and Technology UIST'93, Atlanta, GA, ACM/SIGCHI, pp. 249-258. Berlage, T. and Genau, A. (1993b). From Undo to Multi-User Applications. Proceedings of the Vienna Conference on Human-Computer Interaction, Vienna, Austria, pp. 213-224. Berlage, T. and Sohlenkamp, M. (1995). Visualizing Common Artefacts to Support Awareness in Computer- Mediated Cooperation. GMD, Sankt Augustin, Arbeitspapiere der GMD, 938. Berlage, T. and Spenke, M. (1992). The GINA Interaction Recorder. Proceedings of the IFIP WG2.7 Working Conference on Engineering for Human-Computer Interaction, Ellivuori, Finland. Borning, A. and Travers, M. (1991). Two Approaches to Casual Interaction over Computer and Video Networks. Proceedings of the Conference on Human Factors in Computing Systems CHI'91, New Orleans, LA, ACM Press, New York, pp. 13-19. Bowers, J. (1994). The Work to Make a Network Work: Studying CSCW in Action. Proceedings of the ACM Conference on Computer Supported Cooperative Work CSCW'94, Chapel Hill, NC, ACM Press, New York, pp. 287-298. Bowers, J. and Rodden, T. (1993). Exploding the Interface: Experiences of a CSCW Network. Proceedings of the Conference on Human Factors in Computing Systems INTERCHI'93, Amsterdam, The Netherlands, ACM/SIGCHI, pp. 255-262. Brown, M. L., Newsome, S. L. and Glinert, E. P. (1989). An Experiment into the Use of Auditory Cues to Reduce Visual Workload. Proceedings of the Conference on Human Factors in Computing Systems CHI'89, Austin, TX, ACM Press, New York, pp. 339-346. Bundesminister des Inneren (1974). Gemeinsame Geschäftsordnung der Bundesministerien, Kohlhammer-Verlag, Stuttgart. Buxton, W. (1994). The three mirrors of interaction: a holistic approach to user interfaces. Interacting with virtual environments. L. W. MacDonald and J. Vince (Eds.), Wiley, New York. Buxton, W. A. S. (1993). Telepresence: Integrating Shared Task and Person Spaces. Readings in Groupware and Computer Supported Cooperative Work. R. Baecker (Ed.), Morgan Kaufmann, San Mateo, CA, pp. 846- 852. Carpendale, M. S. T., Cowperthwaite, D. J. and Fracchia, F. D. (1995). 3-Dimensional Pliable Surfaces: For the Effective Presentation of Visual Information. Proceedings of the ACM Symposium on User Interface Software and Technology UIST'95, Pittsburgh, PA, ACM Press, New York, pp. 217-226. References 153 Chang, B.-W. and Ungar, D. (1993). Animation: From Cartoons to the User Interface. Proceedings of the ACM Symposium on User Interface Software and Technology UIST' 93, Atlanta, GA, ACM Press, New York, pp. 45-55. CHI'97 (1997). Proceedings of the Conference on Human Factors in Computing Systems CHI'97, Atlanta, GA, ACM Press, New York. Clement, A. (1994). Considering Privacy in the Development of Multi-media Communications. Computer Supported Cooperative Work (CSCW) 2, pp. 67-88. Cole, P. and Nast-Cole, J. (1992). A Primer on Group Dynamics for Groupware Developers. Proceedings of the Groupware, Los Alamitos, CA, IEEE Computer Society Press, Los Alamitos, pp. 44-57. Condon, C. and Keuneke, S. (1994). Metaphors and Layers of Signification: The Consequences for Advanced User Service Interfaces. Proceedings of the Second International Conference on Intelligence in Broadband Services and Networks IS&N'94, Aachen, Germany, Springer-Verlag, Berlin, pp. 75-88. Conklin, E. J. (1992). Capturing Organizational Memory. Proceedings of the Groupware'92, San Mateo, CA, Morgan Kaufman Publishers, pp. 133-137. Cool, C., Fish, R. S., Kraut, R. E. and Lawery, C. M. (1992). Iterative Design of Video Communication Systems. Proceedings of the ACM Conference on Computer Supported Cooperative Work CSCW'92, Toronto, Canada, ACM Press, New York, pp. 25-32. CSCW'96 (1996). Proceedings of the ACM Conference on Computer Supported Cooperative Work CSCW'96, Boston, MA, ACM Press, New York. Decouchant, D., Quint, V. and Salcedo, M. R. (1995). Structured Cooperative Editing and Group Awareness. Proceedings of the HCI International '95, 6th International Conference on Human-Computer Interaction, Yokohama, Japan, Elsevier Science. Dewan, P. (1991). Flexible user interface coupling in collaborative systems. Proceedings of the ACM Conference on Human Factors in Computing Systems CHI'91, New Orleans, LA, ACM Press, New York, pp. 41-48. Dewan, P. and Choudhary, R. (1991). Primitives for Programming Multi-User Interfaces. Proceedings of the ACM Symposium on User Interface Software and Technology UIST'91, Hilton Head, SC, ACM Press, New York, pp. 69-78. Digital Equipment Corporation (1995). LinkWorks User Manual, Digital Equipment Corporation. Dourish, P. (1993). Culture and Control in a Media Space. Proceedings of the Third European Conference on Computer-Supported Cooperative Work ECSCW'93, Milan, Italy, Kluwer Academic Publishers, Dordrecht, pp. 125-137. Dourish, P. and Bellotti, V. (1992). Awareness and Coordination in Shared Workspaces. Proceedings of the Conference on Computer Supported Cooperative Work CSCW ´92, Toronto, Canada, ACM Press, New York, pp. 107-114. Dourish, P. and Bly, S. (1992). Portholes: Supporting awareness in a distributed work group. Proceedings of the Conference on Human Factors in Computing Systems CHI'92, Monterey, CA, ACM Press, New York, pp. 541-547. Ehrlich, S. F. (1987). Social and Psychological Factors Influencing the Design of Office Communication Systems. Proceedings of the Conference on Human Factors in Computing Systems and Graphics Interface CHI + GI '87, Toronto, Canada, ACM, pp. 323-329. Ellis, C. A. and Gibbs, S. J. (1989). Concurrency Control in Groupware Systems. Proceedings of the ACM SIGMOD International Conference on the Management of Data, Portland, OR, ACM, pp. 399-407. Ellis, C. A., Gibbs, S. J. and Rein, G. L. (1991). Groupware: Some issues and experiences. Communications of the ACM 34(1), pp. 38-58. England, D., Prinz, W., Simarian, K. and Ståhl, O. (1996). Virtual Administration: Providing a DIVE VR Interface to POLITeam. Proceedings of the Workshop on Collaborative Virtual Environments CVE'96, Nottingham, UK, University of Nottingham. Fahlén, L., Brown, C. G., Stahl, O. and Carlson, C. (1993). A Space Based Model for User Interaction in Shared Synthetic Environments. Proceedings of the Conference on Human Factors in Computing Systems INTERCHI'93, Amsterdam, The Netherlands, ACM/SIGCHI, pp. 43-48. Fish, R. S., Kraut, R. E., Root, R. W. and Rice, R. E. (1992). Evaluating Video as a Technology for Informal Communication. Proceedings of the Conference on Human Factors in Computing Systems CHI'92, Monterey, CA, ACM/SIGCHI, pp. 37-48. Floyd, C. and Keil, R. (1983). Softwaretechnik und Betroffenenbeteiligung. Beteiligung von Betroffenenen bei der Entwicklung von Informationssystemen. P. Mambrey and R. Oppermann (Eds.), Campus Verlag, Frankfurt, pp. 137-164. Freund, R. (1996). A Model to Access Groupware Systems via the World-Wide Web. Master Thesis, Institut für Informatik - Lehrstuhl III, Rheinische Friedrich-Wilhelms-Universität, Bonn. 154 References Fuchs, L. (1997). Situationsorientierte Unterstützung von Bewußtsein in CSCW-Systemen. Ph.D. Thesis, University of Essen. Fuchs, L., Pankoke-Babatz, U. and Prinz, W. (1995). Supporting Cooperative Awareness with Local Event Mechanisms: The GroupDesk System. Proceedings of the Conference on Computer Supported Cooperative Work ECSCW`95, Stockholm, Sweden, Kluwer Academic Publishers, Dordrecht, pp. 247- 262. Fuchs, L., Sohlenkamp, M., Genau, A., Kahler, H., Pfeifer, A. and Wulf, V. (1996). Transparenz in kooperativen Prozessen: Der Ereignisdienst in POLITeam. Proceedings of the Deutsche Computer Supported Cooperative Work DCSCW'96, Stuttgart, Germany, Springer-Verlag, Berlin, pp. 3-16. Furnas, G. W. (1986). Generalized Fisheye Views. Proceedings of the Conference on Human Factors in Computing Systems CHI'86, Boston, MA, North Holland, Amsterdam, pp. 16-23. Furnas, G. W. and Bederson, B. B. (1995). Space-Scale Diagrams: Understanding Multiscale Interfaces. Proceedings of the Conference on Human Factors in Computing Systems CHI'95, Denver, CO, ACM Press, New York, pp. 234-241. Gaver, W. (1993). Synthesizing Auditory Icons. Proceedings of the Conference on Human Factors in Computing Systems INTERCHI'93, Amsterdam, The Netherlands, ACM/SIGCHI, pp. 228-235. Gaver, W., Moran, T., MacLean, A., Lovstrand, L., Dourish, P., Carter, K. and Buxton, W. (1992). Realizing a video environment: Europarc's RAVE system. Proceedings of the Conference on Human Factors in Computing Systems CHI'92, Monterey, CA, ACM/SIGCHI, pp. 27-35. Gaver, W. W. (1991). Sound Support for Collaboration. Proceedings of the Second European Conference on Computer Supported Cooperative Work ECSCW'91, Amsterdam, The Netherlands, Kluwer Academic Publishers, Dordrecht, pp. 293-308. Gaver, W. W. (1995). Oh What a Tangled Web We Weave: Metaphor and mapping in Graphical Interfaces. Proceedings of the Conference on Human Factors in Computing Systems CHI'95 (Conference Companion), Denver, CO, ACM Press, New York, pp. 270-271. Genau, A. and Kramer, A. (1995). Translucent History. Proceedings of the Conference on Human Factors in Computing Systems CHI'95 (Conference Companion), Denver, CO, ACM, pp. 250-251. Gerson, E. M. and Star, S. L. (1986). Analyzing Due Process in the Workplace. ACM Transactions on Office Information Systems 4(3), pp. 257-270. Gibbs, S. J. (1989). LIZA: An Extensible Groupware Toolkit. Proceedings of the Conference on Human Factors in Computing Systems CHI'89, Austin, TX, ACM Press, New York, pp. 29-35. Graham, T. C. N., Urnes, T. and Nejabi, R. (1996). Efficient Distributed Implementation of Semi-Replicated Synchronous Groupware. Proceedings of the ACM Symposium on User Interface Software and Technology UIST'96, Seattle, WA, ACM Press, New York, pp. 1-10. Greenberg, S. (1996). Peepholes: Low Cost Awareness of One's Community. Proceedings of the Conference on Human Factors in Computing Systems CHI'96 (Conference Companion), Vancouver, Canada, ACM Press, New York, pp. 206-207. Greenberg, S., Gutwin, C. and Cockburn, A. (1996). Using Distortion-Oriented Displays to Support Workspace Awareness. Department of Computer Science, University of Calgary, Calgary, Research Report, 96/581/101. Greenhalgh, C. and Benford, S. (1995). Virtual Reality Tele-Conferencing: Implementation and Experience. Proceedings of the Fourth European Conference on Computer Supported Cooperative Work, Stockholm, Sweden, Kluwer Academic Publishers, Dordrecht, pp. 165-180. Grudin, J. (1988). Why CSCW applications fail: Problems in the design and evaluation of organizational interfaces. Proceedings of the Conference on Computer-Supported Cooperative Work CSCW '88, Portland, OR, ACM Press, New York, pp. 85-93. Grudin, J. (1990a). The Computer Reaches Out: The Historical Continuity of Interface Design. Proceedings of the Conference on Human Factors in Computing Systems CHI'90, Seattle, WA, ACM Press, New York, pp. 261-268. Grudin, J. (1990b). interface. Proceedings of the Conference on Computer Supported Cooperative Work CSCW'90, Los Angeles, CA, ACM Press, New York, pp. 269-279. Grudin, J. (1994). Groupware and Social Dynamics: Eight Challenges for Developers. Communications of the ACM 37(1), pp. 92-105. Gutwin, C. and Greenberg, S. (1996). Workspace Awareness for Groupware. Proceedings of the Conference on Human Factors in Computing Systems CHI'96 (Conference Companion), Vancouver, Canada, ACM Press, New York, pp. 208-209. Gutwin, C., Greenberg, S. and Roseman, M. (1996a). Staying Aware in Groupware Workspaces. Proceedings of the ACM Conference on Computer Supported Cooperative Work CSCW'96 (Videos, Demonstrations and Short Papers), Boston, MA, ACM Press, New York. References 155 Gutwin, C., Greenberg, S. and Roseman, M. (1996b). Workspace Awareness Support with Radar Views. Proceedings of the Conference on Human Factors in Computing Systems CHI'96 (Conference Companion), Vancouver, Canada, ACM Press, New York, pp. 210-211. Gutwin, C., Roseman, M. and Greenberg, S. (1996). A Usability Study of Awareness Widgets in a Shared Workspace Groupware System. Proceedings of the ACM Conference on Computer Supported Cooperative Work CSCW'96, Boston, MA, ACM Press, New York, pp. 258-267. Haake, A. and Haake, J. M. (1993). Take CoVer: Exploiting Version Support in Cooperative Systems. Proceedings of the Conference on Human Factors in Computing Systems INTERCHI'93, Amsterdam, The Netherlands, ACM/SIGCHI, pp. 259-266. Haake, J. M. and Wilson, B. (1992). Supporting Collaborative Writing of Hyperdocuments in SEPIA. Proceedings of the ACM Conference on Computer Supported Cooperative Work CSCW'92, Toronto, Canada, ACM Press, New York, pp. 138-146. Hämmäinen, H. and Conden, C. (1991). Form and Room: Metaphors for Groupware. Proceedings of the Conference on Organizational Computing Systems, Atlanta, GA, ACM Press, New York, pp. 95-105. Hardock, G., Kurtenbach, G. and Buxton, W. (1993). A Marking Based Interface for Collaborative Writing. Proceedings of the ACM Symposium on User Interface Software and Technology UIST'93, Atlanta, GA, ACM Press, New York, pp. 259-266. Harrison, B., Mantei, M., Beirne, G. and Narine, T. (1994). Communicating about Communicating: Cross- Disciplinary Design of a Media Space Interface. Proceedings of the Conference on Human Factors in Computing Systems CHI'94, Boston, MA, ACM/SIGCHI, pp. 124-130. Harrison, B. L., Ishii, H., Vicente, K. J. and Buxton, W. A. S. (1995). Transparent Layered User Interfaces: An Evaluation of a Display Design to Enhance Focused and Divided Attention. Proceedings of the Conference on Human Factors in Computing Systems CHI'95, Denver, CO, ACM Press, New York, pp. 317-324. Heath, C. (1991). Disembodied conduct: Communication Through Video in a Multi-media Office Environment. Proceedings of the Conference on Human Factors in Computing Systems CHI'91, New Orleans, LA, ACM Press, New York, pp. 99-103. Heath, C., Jirotka, M., Luff, P. and Hindmarsh, J. (1993). Unpacking Collaboration: the Interactional Organisation of Trading in a City Dealing Room. Proceedings of the Third European Conference on Computer Supported Cooperative Work ECSCW'93, Milan, Italy, Kluwer Academic Publishers, Dordrecht, pp. 155- 170. Heath, C. and Luff, P. (1992). Collaboration and Control: Crisis Management and Multimedia Technology in London Underground Line Control Rooms. Computer-Supported Cooperative Work (CSCW) 1, pp. 69- 94. Heath, C. and Luff, P. (1993). Collaborative Activity and Technological Design: Task Coordination in London Underground Control Rooms. Proceedings of the Third European Conference on Computer Supported Cooperative Work ECSCW'93, Milan, Italy, Kluwer Academic Publishers, Dordrecht, pp. 65-80. Heath, C. and Luff, P. (1996). Documents and Professional Practice: 'bad' organizational reasons for 'good' clinical records. Proceedings of the ACM Conference on Computer Supported Cooperative Work CSCW'96, Boston, MA, ACM Press, New York, pp. 354-363. Henderson, D. A. J. and Card, S. K. (1986). Rooms: The use of multiple virtual workspaces to reduce space contention in a window-based graphical user interface. ACM Transactions on Graphics 5(3), pp. 211- 243. Hill, W. C., Hollan, J. D., Wroblewski, D. and McCandless, T. (1992). Edit Wear and Read Wear. Proceedings of the Conference on Human Factors in Computing Systems CHI'92, Monterey, CA, ACM/SIGCHI, pp. 119-125. Hollan, J. and Stornetta, S. (1992). Beyond Being There. Proceedings of the Conference on Human Factors in Computing Systems CHI'92, Monterey, CA, ACM/SIGCHI, pp. 119-125. Hoschka, P., Butscher, B. and Streitz, N. (1993). Telecooperation and Telepresence: Technical challenges of a government distributed between Bonn and Berlin. Informatization and the Public Sector 2(4), pp. 269- 299. Hudson, S. E. and Smith, I. (1996). Techniques for Adressing Fundamental Privacy and Disruption Tradeoffs in Awareness Support Systems. Proceedings of the ACM Conference on Computer Supported Cooperative Work CSCW'96, Boston, MA, ACM Press, New York, pp. 248-257. Hughes, J. A., Randall, D. and Shapiro, D. (1992). Faltering from Ethnography to Design. Proceedings of the ACM Conference on Computer Supported Cooperative Work CSCW'92, Toronto, Canada, ACM Press, New York, pp. 115-122. 156 References Ishii, H., Kobayashi, M. and Grudin, J. (1992). Integration of Inter-Personal Space and Shared Workspace: ClearBoard Design and Experiments. Proceedings of the ACM Conference on Computer Supported Cooperative Work CSCW'92, Toronto, Canada, ACM Press, New York, pp. 33-42. Johansen, R. (1988). Groupware: Computer Support for Business Teams, The Free Press, New York. Klöckner, K., Mambrey, P., Sohlenkamp, M., Prinz, W., Fuchs, L., Kolvenbach, S., Pankoke-Babatz, U. and Syri, A. (1995). POLITeam - Bridging the Gap between Bonn and Berlin for and with the User. Proceedings of the Fourth European Conference on Computer Supported Cooperative Work ECSCW'95, Stockholm, Sweden, Kluwer Academic Publishers, Dordrecht, pp. 17-31. Kraut, R., Egido, C. and Galegher, J. (1988). Patterns of Contact and Communication in Scientific Research Collaboration. Proceedings of the Conference on Computer Supported Cooperative Work CSCW'88, Portland, OR, ACM Press, New York. Kreifelts, T., Hinrichs, E., Klein, K.-H., Seuffert, P. and Woetzel, G. (1991). Experiences with the DOMINO Office Procedure System. Proceedings of the Second European Conference on Computer Supported Cooperative Work ECSCW'91, Amsterdam, The Netherlands, Kluwer Academic Publishers, Dordrecht, pp. 117-130. Kreifelts, T., Hinrichs, E. and Woetzel, G. (1993). Sharing To-Do Lists with a Distributed Task Manager. Proceedings of the Third European Conference on Computer Supported Cooperative Work ECSCW'93, Milan, Italy, Kluwer Academic Publishers, Dordrecht, pp. 31-46. Kyng, M. (1991). Designing for Cooperation: Cooperating in Design. Communications of the ACM 34(12), pp. 63- 73. Kyng, M. (1994). Scandinavian Design: Users in Product Development. Proceedings of the Conference on Human Factors in Computing Systems CHI'94, Boston, MA, ACM/SIGCHI, pp. 3-9. Lauwers, J. C. and Lantz, K. A. (1990). Collaboration awareness in support of collaboration transparency: Requirements for the next generation of shared window systems. Proceedings of the Conference on Human Factors in Computing Systems CHI'90, Seattle, WA, ACM Press, New York, pp. 303-311. Leland, M., Fish, R. S. and Kraut, R. E. (1988). Collaborative Document Production Using Quilt. Proceedings of the Conference on Computer Supported Cooperative Work CSCW'88, Portland, OR, ACM Press, New York, pp. 106-215. Leung, Y. K. and Apperley, M. D. (1994). A review and taxonomy of distortion-oriented presentation techniques. ACM Transactions on Human-Computer Interaction 1(2), pp. 126-160. Levergood, T. M., Payne, A. C., Gettys, J., Treese, G. W. and Stewart, L. C. (1993). AudioFile: A Network- Transparent System for Distributed Audio Applications. Proceedings of the USENIX Summer Conference, Cincinnati, OH, USENIX Association. Levy, E., Zacks, J., Tversky, B. and Schiano, D. (1996). Gratuitous Graphics? Putting Preferences in Perspective. Proceedings of the Conference on Human Factors in Computing Systems CHI'96, Vancouver, Canada, ACM Press, New York, pp. 42-49. Li, J. and Mantei, M. (1992). Working together, virtually. Proceedings of the Graphics Interface '92, Vancouver, Canada, CIPS, pp. 115-122. Lotus Development Corporation (1995). Groupware - Communication, Collaboration and Coordination, Lotus Development Corporation, Cambridge, MA. Lu, I. M. and Mantei, M. M. (1991). Idea management In a Shared Drawing Tool. Proceedings of the Second European Conference on Computer Supported Cooperative Work ECSCW'91, Amsterdam, The Netherlands, Kluwer Academic Publishers, Dordrecht, pp. 97-112. Mackinlay, J. D., Rao, R. and Card, S. K. (1995). An Organic User Interface for Searching Citation Links. Proceedings of the Conference on Human Factors in Computing Systems CHI'95, Denver, CO, ACM Press, New York, pp. 67-73. Mackinlay, J. D., Robertson, G. G. and Card, S. K. (1991). The Perspective Wall: Detail and Context Smoothly Integrated. Proceedings of the Conference on Human Factors in Computing Systems CHI'91, New Orleans, LA, ACM/SIGCHI, pp. 173-179. Madsen, C. M. (1992). Approaching Group Communication by Means of an Office Building Metaphor. Groupware: Software for Computer-Supported Cooperative Work. D. Marca and G. Bock (Eds.), IEEE Computer Society Press, Los Alamitos, pp. 316-328. Malm, P. S. (1994). CSCW and Groupware, a classification of CSCW-systems in a technological perspective. Ph.D. Thesis, University of Tromsø. Malone, T. W. (1985). Designing Organizational Interfaces. Proceedings of the Conference on Human Factors in Computing Systems CHI'85, San Fransisco, CA, ACM, New York, pp. 66-71. Mambrey, P., Mark, G. and Pankoke-Babatz, U. (1996). Integrating User Advocacy into Participatory Design: The Designer's Perspective. Proceedings of the Participatory Design Conference PDC'96, Cambridge, MA, pp. 251-259. References 157 Mambrey, P. and Robinson, M. (1994). "The Non-existing Nothing" - Privacy in a strict, formal bureaucracy: A challenge for CSCW. Critical Considerations in the Creation and Control of Personal/Collective Communication Spaces, Chapel Hill, NC, pp. 101-114. Mantei, M., Baecker, R. M., Sellen, A. J., Buxton, W. A. S. and Milligan, T. (1991). Experiences in the use of a media space. Proceedings of the Conference on Human Factors in Computing Systems CHI'91, New Orleans, LA, ACM Press, New York, pp. 203-208. Mariani, J. A. and Prinz, W. (1993). From Multi-User to Shared Object Systems: Awareness about Co-Workers in Cooperation Support Object Databases. Proceedings of the 23. GI-Jahrestagung, Dresden, Germany, Springer-Verlag, Berlin, pp. 476-481. Mark, G., Fuchs, L. and Sohlenkamp, M. (1997). Supporting Groupware Conventions through Contextual Awareness. Proceedings of the Fifth European Conference on Computer Supported Cooperative Work ECSCW'97, Lancaster, UK, Kluwer Academic Publishers, Dordrecht, pp. 253-268. Mark, G. and Prinz, W. (1997). What happened to our Document in the Shared Workspace? The Need for Groupware Conventions. Proceedings of the Sixth IFIP Conferenence on Human-Computer Interaction INTERACT 97, Sidney, Australia. Matsuura, N., Fujino, G., Okada, K.-I. and Matsushita, Y. (1996). VENUS: A Tele-Communication Environment to Support Awareness for Informal Interactions. The Design of Computer Supported Cooperative Work and Groupware Systems. D. Shapiro, M. Tauber and R. Traunmüller (Eds.), Elsevier Science, pp. 227- 239. Mullet, K., Shapiro, D. J., Robertson, G., Tesler, J. and Tversky, B. (1995). 3D or Not 3D: "More is Better" or "Less is More"? Proceedings of the Conference on Human Factors in Computing Systems CHI'95 (Conference Companion), Denver, CO, ACM, pp. 141-142. Mynatt, E. D. and Edwards, W. K. (1992). Mapping GUIs to Auditory Interfaces. Proceedings of the ACM Symposium on User Interface Software and Technology UIST' 92, Monterey, CA, ACM Press, New York, pp. 171-180. Navarro, L., Prinz, W. and Rodden, T. (1993). CSCW requires open systems. Computer Communications 16(5), pp. 288-297. Neuwirth, C. M., Chandhok, R., Kaufer, D. S., Erion, P., Morris, J. and Miller, D. (1992). Flexible Diff-ing in a Collaborative Writing System. Proceedings of the ACM Conference on Computer Supported Cooperative Work CSCW'92, Toronto, Canada, ACM/SIGCHI, pp. 147-154. O'Day, V. L., Bobrow, D. G. and Shirley, M. (1996). The Social-Technical Design Circle. Proceedings of the ACM Conference on Computer Supported Cooperative Work CSCW'96, Boston, MA, ACM Press, New York, pp. 160-169. Olson, G. M. and Olson, J. S. (1991). User-Centered Design of Collaboration Technology. Journal of Organizational Computing 1, pp. 61-83. Olson, J. S., Olson, G. M., Storrosten, M. and Carter, M. (1992). How a Group-Editor Changes the Character of a Design Meeting as well as its Outcome. Proceedings of the ACM Conference on Computer Supported Cooperative Work CSCW'92, Toronto, Canada, ACM Press, New York, pp. 91-98. Orlikowski, W. J. (1992). Learning from Notes: Organizational Issues in Groupware Implementation. Proceedings of the ACM Conference on Computer Supported Cooperative Work CSCW'92, Toronto, Canada, ACM Press, New York, pp. 362-369. Pankoke-Babatz, U. (1994). Reflections on Concepts of Space and Time in CSCW. Proceedings of the ECCE 7: Seventh European Conference on Cognitive Ergonomics. Human Computer Interactions: From Individuals to Groups, Sankt Augustin, Germany, GMD Studien, pp. 379-391. Pankoke-Babatz, U. and Syri, A. (1996). Gemeinsame Arbeitsbereiche: Eine neue Form der Telekooperation? Proceedings of the Deutsche Computer Supported Cooperative Work DCSCW'96, Stuttgart, Germany, Springer-Verlag, Berlin, pp. 52-67. Parikh, S. S. and Lohse, G. L. (1995). Electronic futures markets versus floor trading: Implications for interface design. Proceedings of the Conference on Human Factors in Computing Systems CHI'95, Denver, CO, ACM Press, New York, pp. 296-303. Patterson, J. F. (1991). Comparing the Programming Demands of Single-User and Multi-User Applications. Proceedings of the ACM Symposium on User Interface Software and Technology UIST'91, Hilton Head, SC, ACM Press, New York, pp. 87-94. Posner, I. R. and Baecker, R. M. (1992). How People Write Together. Proceedings of the Hawaii International Conference on System Sciences HICSS-25, Maui, Hawaii, IEEE Computer Society Press, Los Alamitos. Prinz, W. and Kolvenbach, S. (1996). Support for Workflows in a Ministerial Environment. Proceedings of the ACM Conference on Computer Supported Cooperative Work CSCW'96, Boston, MA, ACM Press, New York, pp. 199-208. 158 References Prinz, W. and Syri, A. (1996). Two Complementary Tools for the Cooperation in a Ministerial Environment. Proceedings of the First International Conference on Practical Aspects of Knowledge Management, Basel, Switzerland. Rauschenbach, U. (1995). Relevanzabhängige Darstellung von Meldungen über Benutzeraktivitäten in einem gemeinsamen Arbeitsbereich. Master Thesis, Fachbereich Informatik, Institut für Computergrafik, Universität Rostock. Rauschenbach, U. (1996). Supporting Awareness in Shared Workspaces Using Relevance-dependent Event Notifications. Proceedings of the Workshop on Collaborative Virtual Environments CVE'96, Nottingham, UK, University of Nottingham. Rhyne, J. R. and Wolf, C. G. (1992). Tools for Supporting the Collaborative Process. Proceedings of the ACM Symposium on User Interface Software and Technology UIST'92, Monterey, CA, ACM Press, New York, pp. 161-170. Robertson, G. G., Mackinlay, J. D. and Card, S. K. (1991). Cone Trees: Animated 3D Visualizations of Hierarchical Information. Proceedings of the Conference on Human Factors in Computing Systems CHI'91, New Orleans, LA, ACM/SIGCHI, pp. 189-194. Robinson, M. (1993a). Design for unanticipated use ..... Proceedings of the Third European Conference on Computer Supported Cooperative Work ECSCW'93, Milan, Italy, Kluwer Academic Publishers, Dordrecht, pp. 187-202. Robinson, M. (1993b). Keyracks and computers: an introduction to "common artefact" Computer Supported Cooperative Work (CSCW). Wirtschaftsinformatik 35, pp. 157-166. Rodden, T. (1996). Populating the Application: A Model of Awareness for Cooperative Applications. Proceedings of the ACM Conference on Computer Supported Cooperative Work CSCW'96, Boston, MA, ACM Press, New York, pp. 87-96. Rodden, T., Mariani, J. A. and Blair, G. (1992). Supporting Cooperative Applications. Computer Supported Cooperative Work (CSCW) 1, pp. 41-67. Rogers, Y. (1993). Coordinating Computer-Mediated Work. Computer-Supported Cooperative Work (CSCW) 1, pp. 295-315. Root, W. R. (1988). Design of a multi-media vehicle for social browsing. Proceedings of the ACM Conference on Computer Supported Cooperative Work CSCW'88, Portland, OR, ACM Press, New York, pp. 25-38. Roseman, M. and Greenberg, S. (1992). GroupKit: A Groupware Toolkit for Building Real-Time Conferencing Applications. Proceedings of the ACM Conference on Computer Supported Cooperative Work CSCW'92, Toronto, Canada, ACM Press, New York, pp. 43-50. Rowley, D. E. (1994). Usability Testing in the Field: Bringing the Laboratory to the User. Proceedings of the Conference on Human Factors in Computing Systems CHI'94, Boston, MA, ACM/SIGCHI, pp. 306-312. Salvador, T., Scholtz, J. and Larson, J. (1996). The Denver Model for Groupware Design. SIGCHI Bulletin 28(1), pp. 52-58. Schäl, T. and Zeller, B. (1990). A Methodological Approach to Computer Supported Cooperative Work. Proceedings of the Fifth European Conference on Cognitive Ergonomics, Urbino, Italy. Schmidt, K. and Bannon, L. (1992). Taking CSCW Seriously - Supporting Articulation Work. Computer Supported Cooperative Work (CSCW) 1, pp. 7-40. Schwabe, G. and Krcmar, H. (1996). CSCW-Werkzeuge. Wirtschaftsinformatik 38(2), pp. 209-225. Shapiro, D. and Traunmüller, R. (1993). CSCW in Public Administration: a review. Proceedings of the IFIP TC8/WG8.5 Working Conference on Systems Engineering in Public Administration, Lüneburg, Germany, Elsevier Science Publishers, pp. 1-17. Shneiderman, B. (1992). Designing the User Interface, Addison-Wesley, Reading, MA. Smith, I. (1996). Toolkits for Multimedia Awareness. Proceedings of the Conference on Human Factors in Computing Systems CHI'96 (Conference Companion), Vancouver, Canada, ACM Press, New York, pp. 59-60. Sohlenkamp, M. (1994a). Das virtuelle Büro als Benutzungsschnittstelle für kooperatives Arbeiten. Proceedings of the 24. GI-Jahrestagung, Hamburg, Germany, Springer-Verlag, Berlin, pp. 142-149. Sohlenkamp, M. (1994b). A Virtual Office Environment Supporting Shared Applications. Proceedings of the 3rd International Conference 'Interface to Real & Virtual Worlds', Montpellier, France, EC2, pp. 163-173. Sohlenkamp, M. and Berlage, T. (1996). Dynamic Interfaces for Cooperative Activities. Computers as Assistants - A New Generation of Support Systems. P. Hoschka (Ed.), Lawrence Earlbaum Associates, Mahwah, pp. 219-231. Sohlenkamp, M. and Chwelos, G. (1994). Integrating Communication, Cooperation, and Awareness: The DIVA Virtual Office Environment. Proceedings of the ACM Conference on Computer Supported Cooperative Work CSCW'94, Chapel Hill, NC, ACM Press, New York, pp. 331-343. References 159 Sohlenkamp, M., Fuchs, L. and Genau, A. (1997). Awareness and Cooperative Work: The POLITeam Approach. Proceedings of the Hawaii International Conference on System Sciences HICSS-30, Maui, HA, IEEE Computer Society Press, Los Alamitos, pp. 549-558. Sohlenkamp, M., Mambrey, P., Fuchs, L., Prinz, W., Syri, A., Kolvenbach, S., Klöckner, K. and Pankoke-Babatz, U. (1995). Unterstützung verteilter Regierungsarbeit mit POLITeam. Proceedings of the Workshop Koordinationsmethoden und -werkzeuge bei der computergestützten kooperativen Arbeit, Bamberg, Germany, Universität Bamberg, pp. 2-14. Sohlenkamp, M., Mambrey, P., Fuchs, L., Prinz, W., Syri, A., Kolvenbach, S., Klöckner, K. and Pankoke-Babatz, U. (1998). Supporting the Distributed German Government with POLITeam. International Journal of Multimedia Tools and Applications (to appear). Spenke, M. (1993). From Undo to Multi-User Applications - The Demo. Proceedings of the Conference on Human factors in Computing Systems INTERCHI'93, Amsterdam, The Netherlands, ACM/SIGCHI, pp. 468-469. Spenke, M. and Beilken, C. (1990). An Overview of GINA - the Generic Interactive Application. Proceedings of the Workshop on User Interface Management and Design, Lisbon, Portugal, pp. 273-293. Starker, I. and Bolt, R. A. (1990). A Gaze-Responsive Self-Disclosing Display. Proceedings of the Conference on Human Factors in Computing Systems CHI'90, Seattle, WA, ACM Press, New York, pp. 3-9. Stefik, M., Bobrow, D. G., Foster, G., Lanning, S. and Tatar, D. (1987). WYSIWIS revised: early experiences with multiuser interfaces. ACM Transactions on Office Information Systems 5(2), pp. 147-167. Stone, M. C., Fishkin, K. and Bier, E. A. (1994). The Movable Filter as a User Interface Tool. Proceedings of the Conference on Human Factors in Computing Systems CHI'94, Boston, MA, ACM/SIGCHI, pp. 306-312. Syri, A. (1998). Ein Entwurfsmodell für CSCW-Systeme. Ph.D. Thesis, Arbeitsgruppe Kooperationssysteme, Johannes-Kepler-Universität, Linz, Austria (to appear). Syri, A. (1997). Tailoring Cooperation Support through Mediators. Proceedings of the Fifth European Conference on Computer Supported Cooperative Work ECSCW'97, Lancaster, UK, Kluwer Academic Publishers, Dordrecht, pp. 157-172. Takemura, H. and Kishino, F. (1992). Cooperative Work Environment Using Virtual Workspace. Proceedings of the ACM Conference on Computer Supported Cooperative Work CSCW'92, Toronto, Canada, ACM Press, New York, pp. 226-232. Tang, J. C. and Rua, M. (1994). Montage: Providing Teleproximity for Distributed Groups. Proceedings of the Conference on Human Factors in Computing Systems CHI'94, Boston, MA, ACM/SIGCHI, pp. 37-43. Thomas, B. H. and Calder, P. (1995). Animating Direct Manipulation Interfaces. Proceedings of the ACM Symposium on User Interface Software and Technology UIST'95, Pittsburgh, PA, ACM Press, New York, pp. 3-12. Tollmar, K., Marmolin, H. and Sundblad, Y. (1994). The Collaborative Desktop: An Environment for Computer Supported Cooperative Work. Proceedings of the Conference on Human Factors in Computing Systems CHI'94 (Conference Companion), Boston, MA, ACM/SIGCHI, pp. 23-24. Tollmar, K. and Sundblad, Y. (1995). The Design and Building of the Graphic User Interface for the Collaborative Desktop. Computers & Graphics 19(2), pp. 179-188. Tuckman, B. and Jensen, M. A. (1977). Stages of Small Group Development Revisited. Group and Organizational Studies 2, pp. 419-427. Want, R. and Hopper, A. (1992). Active badges and personal interactive computing objects. IEEE Transactions on Consumer Electronics 38(1), pp. 10-20. Watzlawick, P., Beavin, J. H. and Jackson, D. D. (1967). Pragmatics of Human Communication, W. W. Norton & Company Inc., New York. Wax, T. (1996). Red light, green light: Using peripheral awareness of availability to improve the timing of spontaneous communication. Proceedings of the ACM Conference on Computer Supported Cooperative Work CSCW'96 (Videos, Demonstrations and Short Papers), Boston, MA, ACM Press, New York. Weisband, S. (1994). Overcoming Social Awareness in Computer-Supported Groups - Does Anonymity Really Help? Computer Supported Cooperative Work (CSCW) 2, pp. 285-297. Whittaker, S., Frohlich, D. and Daly-Jones, O. (1994). Informal Workplace Communication: What is it Like, and How Might We Support it? Proceedings of the Conference on Human Factors in Computing Systems CHI'94, Boston, MA, ACM Press, New York, pp. 131-137. Whittaker, S. and Schwarz, H. (1995). Back to the Future: Pen and Paper Technology Supports Complex Group