This paper describes our experiences implementing a component architecture for TeamWave WorkpIace, an integrated groupware environment using a rooms metaphor.The problem we faced was how to design the architecture to support rapid development of new embedded components.Our soIution, based on TcUTk and GroupKit, uses multiple interpreters and a shared window hierarchy.This proved effective in easing development complexity in TeamWave.We discuss some of the strategies we used, and identify the types of interactions between system components.The lessons learned in deveIoping this component model should be generally applicable to future integrated groupware systems in different environments.

GroupWeb is a prototype browser that allows group members to visually share and navigate World Wide Web page in real time. Its groupware features include document and view slaving for synchronizing information sharing, telepointers for enacting gestures, and relaxed “what you see is what I see” views to handle display differences. A groupware text editor lets groups create and attach annotations to pages. An immediate application of GroupWeb is as a presentation tool for real time distance education and conferencing. The video illustrates GroupWeb and all its features.

Real-time groupware systems often let each participant control their own view into a shared workspace. However, when collaborators do not share the same view they lose their awareness about where and how others are interacting with the workspace artifacts. We have designed a number of add-on awareness windows that help people regain this awareness. Two general strategies and several variations are illustrated in this video that extend work done in a few other groupware systems. First, radar overviews shrink the entire workspace to fit within a single window. Awareness is indicated by overlaying the overview with boxes representing others' viewports, by telepointers that show where they are working, and by seeing changes to objects in the workspace as they are made. The workspace can be represented within the radar overview as a scaled miniature, by stylized objects, or by its semantic structure. Second, two types of detailed views show some or all of what another person can see, providing awareness of fine-grained details of others' actions.

Workspace awareness is knowledge about others' interaction with a shared workspace. Groupware systems provide only limited information about other participants, often compromising workspace awareness. This paper describes a usability study of several widgets designed to help maintain awareness in a groupware workspace. These widgets include a miniature view, a radar view, a multiuser scrollbar, a glance function, and a "what you see is what I do" view. The study examined the widgets' information content, how easily people could interpret them, and whether they were useful or distracting. Observations, questionnaires, and interviews indicate that the miniature and radar displays are useful and valuable for tasks involving spatial manipulation of artifacts. Keywords Workspace awareness, shared workspaces, usability study. INTRODUCTION People maintain an ongoing awareness of others in physical workspaces like whiteboards and tabletops, and they do this using everyday perceptual abilit...

Teams whose members are in close physical proximity often rely on team rooms to serve both as meeting places and repositories of the documents and artifacts that support their projects.TeamRooms is a groupware system that fills the role of a team room for groups whose members can work both co-located and at a distance.Facilities in TeamRooms allow team members to collaborate either in real-time or asynchronously, and to customize their shared electronic space with tools to suit their needs.Unlike many groupware systems, all TeamRooms documents and artifacts are fully persistent.

This article presents an overview of GroupKit, a groupware toolkit that lets developers build applications for synchronous and distributed computer-based conferencing. GroupKit was constructed from our belief that programming groupware should be only slightly harder than building functionally similar single-user systems. We have been able to significantly reduce the implementation complexity of groupware through the key features that comprise GroupKit. Aruntime infrastructureautomatically manages the creation, interconnection, and communications of the distributed processes that comprise conference sessions. A set ofgroupware programming abstractionsallows developers to control the behavior of distributed processes, to take action on state changes, and to share relevant data.Groupware widgetslet interface features of value to conference participants to be easily added to groupware applications.Session managers—interfaces that let people create and manage their meetings—are decoupled from groupware applications and are built by developers to accommodate the group's working style. Example GroupKit applications in a variety of domains have been implemented with only modest effort.

Many information structures are represented as two-dimensional networks (connected graphs) of links and nodes. Because these network tend to be large and quite complex, people often perfer to view part or all of the network at varying levels of detail. Hierarchical clustering provides a framework for viewing the network at different levels of detail by superimposing a hierarchy on it. Nodes are grouped into clusters, and clusters are themselves place into other clusters. Users can then navigate these clusters until an appropiate level of detail is reached. This article describes an experiment comparing two methods for viewing hierarchically clustered networks. Traditional full-zoom techniques provide details of only the current level of the hierarchy. In contrast, fisheye views, generated by the “variable-zoom” algorithm described in this article, provide information about higher levels as well. Subjects using both viewing methods were given problem-solving tasks requiring them to navigate a network, in this case, a simulated telephone system, and to reroute links in it. Results suggest that the greater context provided by fisheye views significantly improved user performance. Users were quicker to complete their task and made fewer unnecessary navigational steps through the hierarchy. This validation of fisheye views in important for designers of interfaces to complicated monitoring systems, such as control rooms for supervisory control and data acquistion systems, where efficient human performance is often critical. However, control room operators remained concerned about the size and visibility tradeoffs between the fine room operators remained concerned about the size and visibility tradeoffs between the fine detail provided by full-zoom techniques and the global context supplied by fisheye views. Specific interface feaures are required to reconcile the differences.

This paper presents our approach to the design of groupware toolkits for real-time work, and how the design is instantiated in our toolkit, GROUPKIT.The design is based on both the technical underpinnings necessary for real-time groupware, and on user-centered features identified by existing CSCW human factors work.We also present three strategies for building GROUPKIT's components.First, an extendible, object-oriented run-time architecture supports managing distributed processes and the communication between them.Second, transparent overlays offer a convenient method for adding general components to various groupware applications, for example supporting gestures via multiple cursors and annotation via sketching.Third, open protocols allow the groupware designer to create a wide range of interface and interaction policies, accommodating group differences in areas such as conference registration and floor control.

Groupware designers are now developing multi-user equivalents of popular paint and draw applications. Their job is not an easy one. First, human factors issues peculiar to group interaction appear that, if ignored, seriously limit the usability of the group tool. Second, implementation is fraught with considerable technical hurdles. This paper describes the human and technical factors that have been met and handled by researchers and implementors of group drawing tools. We emphasize our own experiences building four systems supporting remote real time group interaction: GroupSketch and XGroupSketch, both multi-user sketchpads; GroupDraw, a prototype object-based multi-user drawing package, and GroupKit, a groupware toolkit. On the human factors side, we summarize empirically-derived design principles that we believe are critical to building useful and usable collaborative drawing tools. On the implementation side, we describe our experiences with replicated versus centralized architectures, schemes for participant registration, multiple cursors, network requirements, and the structure of the drawing primitives. A brief survey of other approaches to group drawing is also included.