State Treemap: an Awareness Widget for Multi-Synchronous Groupware Pascal Molli, Hala Skaf-Molli, Christophe Bouthier LORIA, INRIA Lorraine fmolli,skaf,
[email protected] Abstract Awareness widgets facilitate coordination for both synchronous and asynchronous groupware systems. Unfortunately, they cannot be used for multi-synchronous groupware systems, where people work simultaneously but disconnected on the same project. With a group of architects, we have designed a new awareness widget for multi-synchronous groupware system called “State Treemap”. This widget shows the divergence states of shared objects using Shneiderman’s treemap visualization. We have developed and integrated this widget in a platform for hosting virtual teams of architects. In this paper, we describe the motivations, the design and the realization of this original widget.
1 Introduction With the growth of global communications, a new kind of collaboration is emerging: virtual teams. For Lipnack [21] ”Virtual teams work across space, time and organizational boundaries with links strengthened by webs of communication technologies”. We are collaborating since two years with architects from the CRAI 1 to build a platform for hosting virtual teams of architects. Building virtual team software is quite complex, it requires shared data management, concurrent access control, knowledge sharing, security, interoperability, consistency, coordination, communication . . . In this paper, we focus on coordination problem. Gutwin et al [17, 14, 16] pointed out: “Workspace awareness reduces the effort needed to coordinate tasks and resources, helps people move between individual and shared activities, provides a 1 Research Center on Architecture and Engineering, http://www.crai.archi.fr/
context in which to interpret utterances, and allows anticipation of others’ actions”. They have demonstrated that workspace awareness widgets facilitate coordination for synchronous groupware [18]. Other proposals facilitate coordination for asynchronous groupware [30, 26, 27]. However, if we consider architects, their way of working is more “multi-synchronous”, as defined by Dourish [4, 5]. Multi-synchronous groupware is characterized by parallel streams of activities, by opposition with standard techniques that attempt to maintain the illusion of a single stream of activity. Multi-synchronous groupware environments involve simultaneous but disconnected working; they manage more than one thread of control. Configuration Management tools [6] with long transaction models [34, 8] and Copy-Modify-Merge (CMM) paradigm [7] are multi-synchronous groupware. Unfortunately, most of workspace awareness widgets such as radar views, multi-user scrollbar, graphical activity indicators [16, 15] have been developed for synchronous applications and not for multi-synchronous ones. They are not adapted for “multi-synchronous” applications in general and more specifically for virtual team software. In this paper, we present a new awareness widget for “multi-synchronous” groupware called “State Treemap”. This is a result of the COCAO project between the ECOO team, CRAI and the Research Center of France Telecom. The paper is organized as follows: Section 1 describes the motivations and requirements for a multi-synchronous compliant awareness widget. Section 2 shows the usability of the “State Treemap” on a scenario. Section 3 presents related work. Section 4 describes the integration of the State Treemap in a prototype of virtual team supporting platform, the Motu environment. The last section concludes with some pointers to future works.
2 Motivations for Multi-synchronous Awareness Widget Basically, multi-synchronous applications are characterized by their abilities to support divergence i.e. parallel stream of activities on replicated objects. Dourish [5] wrote: The notion of multiple, parallel streams of activity, is a natural approach to supporting this familiar pattern of collaborative work. Working activities proceed in parallel (multiple streams of activity), during which time the participants are disconnected (divergence occurs); and periodically their individual efforts will be integrated (synchronization) in order to achieve a consistent state and progress the activity of the group. The main difference between synchronous/asynchronous and multi-synchronous applications are modifications visibility and integration. In standard collaborative applications, when a modification is performed by one user, it is immediately visible by others. In multisynchronous applications, modifications done by one user are visible by other users, only when she (or he) validates her modifications (commit her changes). A visible change does not imply immediate integration by other activities streams. Concurrent modifications will be integrated when users will decide it. Allowing deferred validation of changes and divergence have several important advantages and impacts: Parallelization of activities If divergence is managed, then it can be possible for users to realize their main objective faster by working in parallel. If not, this advantage will be lost in costly integration stages. Privacy During discussion with architects, it was clear that an architect does not want to publish draft versions of plans. He wants to work insulated in his private workspace and waits until his work is refined enough before making his work visible by others. The responsibility of making changes visible must be under the control of the architect. Visibility of partial changes Visibility of partial changes can be dangerous because intermediate observable states can be inconsistent. If an architect starts to change something on a building, this change will have an impact on
several documents. For example, architects who are observing changes on the roof plan will be confused, since the latter plan is not yet consistent with the floor plan. Experimental changes Sometimes, it can be useful to try an experimental solution without any warranty of success. Architects can work insulated in their private workspaces and make any changes they want. They will be able to cancel those changes if they decide that these experimental changes cannot be achieved. The cancellation has no impact because nobody else had seen these experimental changes. The main goal of the multi-synchronous awareness widget is to make people aware of parallel streams of activities. Working in a multisynchronous environment means living with divergence, inconsistencies. To obtain expected benefits of parallelization, divergence must be managed and visualized in a simple way. If not, users can develop huge divergence and advantages of parallelism will be lost because of a difficult integration stage. Multi-synchronous awareness widget has to help user to answer the classical “who, what, where, when and how” questions. Answers have to take into account divergence: I diverge with whom? Where are the divergence? What is the importance of the divergence? Is there no more divergence? Is the divergence increasing or shrinking down? These questions are fundamental to help people to plan a general strategy to manage divergence. Another important point is the number of shared documents. A virtual team of architects can share more than 10000 documents. The building of French stadium for soccer world championship has required more the 100000 documents. Awareness widgets have to support a large number of shared documents. If five users are working on 100000 documents, how can they visualize in a small window the document they are working on ? Our objective is to build an awareness widget that can help people to be aware of divergence on a large number of documents.
3 Working with Divergence and State Treemaps In this section, we present a scenario where two users are making modifications on arbitrary documents (objects) with deferred validation of changes. The deferred validation of changes
is managed by the Copy-Modify-Merge (CMM) paradigm [7].
3.1 Working with Divergence: the CopyModify-Merge Paradigm Working with CMM paradigm is fairly simple. There is a shared repository storing multiversioned objects and three basic commands: Checkout(object) identifies an object with a particular version (by default the last one) in the repository and creates a local copy of that object in the personal workspace of the user. Commit(Local Object) validates modifications done locally on the local copy by creating a new version of that object in the repository. This will be done only if the local object is up-to-date i.e. if there is no new unread version in the repository committed by other users. Update(Local object) merges the local copy with the last version of that object stored in the repository. This stage can be assisted by merge algorithms like [24, 23, 33, 19]
foo
Repository
bar
Figure 1. Copy-modify-merge Figure 1 illustrates how operations are scheduled. Two users “foo” and “bar” are working concurrently.
“foo” and “bar” first checkout some objects from the repository and create local copies in their private workspaces (step 1,2). They can now work disconnected if they want. They can call their regular tools (a text editor, a compiler, : : : on their local copies (step 3). User “bar” commits his changes (step 4) and creates a new version of a shared object in the repository. At this stage, user “foo” is not “upto-date” on this object and cannot publish his own changes.
User “foo” has to re-synchronize his version with last version (step 5). The last version is downloaded from the repository and stored in the private workspace of “foo”. ‘foo” calls a merge tool (step 6) to merge concurrent changes. Now “foo” has a new version in his private workspace where his own changes and changes done by “bar” are merged. He can commit this version in the repository (step 7). This way of working is largely used in software engineering community [6, 10]. All configuration management tools support CMM paradigm. More than 100000 people are actually working with this paradigm on SourceForge for making open-source software [29]. Copy-Modify-Merge is a concurrency strategy representative of multi-synchronous applications. Each private workspace represents one stream of activity. After copying objects, users can work disconnected and each activity stream executes operations on local copies. Divergence can occur during this stage. To reach a consistent stage again, users have to re-synchronize without overwriting concurrent changes. The strategy of CopyModify-Merge forces people to reread last version of object if local copy is out-of-date. The merge stage is executed locally in the activity stream. If people are not aware about divergence, they will realize the importance of divergence at commit time. CMM strategy will force them to re-read changes done by other users. If these new changes have an impact on local change, maybe the local work has to be re-done. If CMM prevents users from losing data, it does not prevent them from developing huge divergence. Actually, people will be aware about the importance of divergence at committime: may be it is too late. “State Treemap” will help people to be aware about the divergence at regular intervals of time and to control it.
3.2 Working with State Treemap Widget Treemap has been designed for visualization of huge trees of objects [28, 20]. Treemaps help system managers to visualize quickly large trees of directories and subdirectories. System managers can see immediately where bigger files are located. Figure 2 represents a simple transformation of tree of objects into a treemap. Each leaf is displayed as a rectangle. The area of the rectangle is determined by an arbitrary size attached to the leaf. The nodes are implicitly displayed by the area occupied by all its children. For example, the area determined by
leafs E1 and F2 displays implicitly node B3 . More details about this figure can be found at [31].
State Name Local Up To Date
Figure 2. Treemap construction The principle of State Treemap is to display private workspaces objects as a treemap where rectangles are decorated with colors indicating the state of the objects. For visibility, in this paper we have substituted colors with black and white patterns for State Treemaps. Different states are described in figure 3. All these states are exclusive; a shared object cannot be in the “Local Up to Date” state and in the “Remotely Modified” state at the same time. Another possible visualization for tree structured data is a classic file system navigation interface. Such interface cannot provide a global view of all objects. User has to take some actions in order to build a mental global view. The objective of treemap visualization is to allow direct global view of all objects, without requesting any action. For example, suppose that a file x is changed in the directory a=b= . With a treemap view, user will see that immediately, with classic folder view, the directory a=b= has to be unfolded. In our context, treemap visualization provides a global view of the workspace. The user has a general picture of the situation. Seeing the whole picture instead of details helps user capture an in-
State meaning The local object is identical to the last version of object in the repository
Local Modified
The local object is modified
Remotely Modified
There exists at least another user who has uncommitted change on that object
Need Update
A new version of the local object is available in the repository
Potential Conflict
The local object is modified and there exists at least another user who has uncommitted change on that object
Will Conflict
The local object is modified and a new version of the local object is available in the repository
(a) Original tree
(b) Treemap visualization
Pattern white
Figure 3. State of objects
timate knowledge of the global situation, as predicted by the Gestalt theory [32]: “The whole has qualities that are more than the sum of all its parts”. For example, the more a user diverge, the more his treemap is red colored. When he is taking a glance at the treemap, he perceives the general state of his workspace. If he pays more attention to the treemap, he can see where divergence is located. If he is interacting with the treemap, he can see others users involved in divergence. We execute step by step the following scenario (State Treemaps are launched at step 2). Each “edit()” command represents the call of a tool on an object. For example, an architect calls AutoCAD on a file to modify it. Checkout, Commit, Update are regular commands of the Copy-Modify-Merge paradigm. An “edit()” command after an “Update” can be considered as calling a merge tool. This scenario can be executed with users distributed in time. In fact, users can connect and disconnect from the system as they wish. We can imagine that this scenario takes 6 months, for example, and
users have never connected in the same time. 1 2 3 4 5 6 7 8 9 10 11 12
foo Checkout(”project/*”) Treemap() Edit(”project/mybib.bib”) Edit(”project/lib/etat.tex”)
bar Checkout(”project/*”) Treemap() Edit(”project/mybib.bib”)
Commit(”project/lib/etat.tex”) Update(”project/lib/etat.tex”) Commit(”project/mybib.bib”)
are modifying this object, the tool-tip will display the list of all names. At line 5 of the scenario, “bar” is modifying the file “mybib.bib”. The system notices that another user has already changed the same file, so both files are marked as “potentially conflict” and are painted in with . Treemaps are repainted as follow:
Update(”project/mybib.bib”) Edit(”project/mybib.bib”) Commit(”project/mybib.bib”) Update(”project/mybib.bib”)
In step 1, both users take copies of all shared objects stored in the repository. For this example we have created a tree of 49 files distributed in three directories. We have omitted the tree representation of the files and directories since this is not necessary for the comprehension of the example. The following screen appears after the execution of line 2.
The left treemap represents the state of the workspace of user “foo” (as printed in the title) and the right treemap represents the state of the workspace of user “bar”. Of course, we represent here both treemaps side by side, but in reality, each user sees only his own treemap. Both treemaps are completely white. It means that all copies in the bar’s workspace and foo’s workspace are exactly similar. There is no divergence. If the user move the pointer onto the treemap, additional information can be displayed in a tool-tip (filename: mybib.bib, state: up to date). The pointer is located on the left upper corner of the tool-tip and has been removed for visibility. After the execution of lines 3 and 4, state treemaps have changed as depicted below:
The names of the users responsible of potential conflicts are displayed in the tool-tip. More than two users can be involved in this potential conflict. In this case, the tool-tip will display list of all the names. At the line 6, foo is publishing his modification on “etat.tex”. Treemaps are repainted as follow.
For “foo”, there is only one file in a potentially conflict state, whereas for “bar”, “etat.tex” was in the state remotely modified and move to the state pattern. “need update” painted with “bar” is not forced to re-synchronize his out-ofdate file immediately but he will do it in this scenario. In step 7, “bar” is updating “etat.tex” with last version of “etat.tex” available in the repository. After that, both treemaps are identical.
Now we focus on how “foo” and “bar” will reduce the potential conflict on “mybib.bib”. First, one of them has to publish his modifications. “foo” does it on line 8. Treemaps are repainted as follow: “foo” has changed files “mybib.bib” and “etat.tex”. The treemap of his workspace is disto indicate that files playing two files with are locally modified and not yet committed. “bar” treemap is indicating that two files have been modified in another workspace. It means that there is another activity on this files in another workspace. If “bar” is moving his pointer on highlighted filed, the tool-tip will display the name of the user who is currently modifying this object. If several users
“bar” sees “mybib.bib” painted with the pattern to signal a conflict and “foo” see “mybib.bib” painted with the i.e. remotely modified. It is important to note that, both of them
are aware that there is still a divergence between them. At lines 9-10, “bar” is re-synchronizing “mybib.bib” with the last version available in the repository. He downloads the last version, and starts to merge concurrent modifications with his own ones by calling locally a merge tool. After this operation, treemaps are repainted as follow:
For “bar”, “mybib.bib” is now up-to-date and just locally modified. Whereas for, foo his copy of this file is in a “remotely-modified” state. Now, “bar” can commit his modifications on “mybib.bib”. Treemap are repainted to signal to “bar” that his workspace is clean now and to signal to “foo” that his copy of “mybib.bib” needs an update.
“foo” updates his copy of “mybib.bib” and thus the both of workspaces are completely identical again, no more divergence. “foo” and “bar” are aware of that.
In this execution, we start from a point with no divergence, divergence is occurred and finally convergence is re-established. During these stages, at any moment, all users know exactly where the divergence is located, with who and what they have to do in order to converge. Connection, disconnection, massive distribution in time are supported, in addition, a large number of shared objects can be displayed in a very small window.
4 Related Works The main difference between State Treemap and other workspace awareness widgets is the capacity of State Treemap to handle divergence and support a large number of shared objects.
It is quite difficult to compare our State Treemap widget with other well-known workspace awareness widgets such as radar views, multi-user scrollbar, graphical activity indicators [17]. These widgets make sense for real-time groupware and are designed to support distribution in time. However, Greenberg et al [13, 12] have proposed to use fish-eye view, magnifying lenses to display large amount of data and to be able to focus on a particular point. Users can see in the same display the general picture and the detailed information on a point of interest. The State Treemap widget has been inspired by the distortion-oriented displays which can display a large number of shared objects. The comparison between State Treemap widget with asynchronous environment is quite difficult too. It is not always obvious to make difference between asynchronous and multi-synchronous applications. TeamRooms [26] provides a shared workspace but with immediate validation scheme. Any modification is immediately visible to others and divergence is not supported, scalability in number of objects is poorly supported; it is possible to create 10000 objects in a room, but it very hard to monitor what happen in this room. TeamRooms supports asynchronous style of work but does not support divergence. BSCW [2] is basically an asynchronous shared workspace. With BSCW, it is possible for a user to take a copy of shared object without locking this object and to work disconnected. Thus, BSCW is a multi-synchronous application. However, if users want to be aware of divergence, they will have to read carefully logs of events of document space. Divergence is allowed but not managed. Multi-synchronous applications like Configuration Management tools [1] tolerate divergence. Configuration Management tools already compute state like “need update” or “conflict”. However, they manage divergence from the point of view of concurrency control and consistency. CopyModify-Merge paradigm has been developed as an optimistic concurrency protocol with the objective to allow parallel execution of tasks. It prevents the lost update scenario by forcing people to read concurrent committed modifications before committing local one. Advanced transactions models can be seen as extension of Copy-Modify-Merge strategy with better warranties about consistency [3]. Divergence is seen like a source of inconsistencies and as a source of awareness. Minor and Magnusson [22] have described a model for multi-synchronous collaborative editing using Copy-Modify-Merge. In this model, two people can work on the same document, either
on two different versions or on the same shared version. Awareness is provided by visualization of the differences between versions (separated or shared) in the document itself. This provides divergence management, at the document level, and with textual display. By opposition, the treemap approach is based on a synthesis of the divergence into states. This gives a higher level of awareness, permitting divergence management on any type of objects (image, text,...) and not only on text document. Moreover, difference could only be visualized in the context of the shared editor. Treemap visualization is more general and application independent. Finally, state treemap allows to manage the divergence on a huge number of objects at the same time and not document by document. Finally, the state treemap is visually more peripheral, thus reducing the cognitive workload. Some notification systems like Elvin [9] and NESSIE [25] are concerned with both synchronous and asynchronous collaborations. However, dealing with both synchronous and asynchronous do not mean having a multi-synchronous system. The later one involves simultaneous but disconnected working; it manages more than one thread of control and support divergence. Elvin and NESSIE grant some support for virtual teams. The first one provides CVS log messages in Tickertape, and the second uses animated GIF in BSCW to report shared workspace activity. State awareness has not the same objective. It makes people aware about divergence: where is it located ? with who ? Providing CVS log messages in Tickertape makes people aware about activities. Using animated GIF helps people to understand past activities. State awareness, by providing divergence awareness, helps people to predict the complexity of the future integration stages. This helps people to anticipate others actions and gives information to plan integration strategy.
5 State Treemap in the Motu Framework We have integrated State Treemap in our platform for hosting virtual teams of architects. This platform is called “MOTU”. The Motu project is itself hosted on SourceForge and can be found at motu.sourceforge.net. Motu is a generic framework for supporting virtual teams distributed over the Internet. It provides the basic services needed by a virtual team: Shared data. The object model is a multi-version file system. Concurrency is managed using the copy-modify-merge paradigm and long
transaction approach. Versioning includes directory and branching. Access control is based on access control list. A notification engine is coupled with the multi-version system and provides a low-level events API. Formal Coordination. Coordination is based on a flexible Workflow system [11]. Communication. Motu provides an instant messaging feature and audio/video conferencing based on the Java Media Framework. Awareness. Motu provides activity awareness through different awareness engines. Availability awareness is provided by an integrated system of presence very similar to ICQ. The workflow engine provides workspace awareness. The State awareness helps users to manage divergence. State Treemap keeps users to be aware of where the divergence is located (on what object) and with whom. Presence awareness informs users if virtual team members are actually connected or not. Communication services of Motu can be used for people to communicate.
Figure 4. Expected benefits The expected benefits of State Treemap integration into the Motu framework is to generate unexpected interactions between users as described in the figure 4. We expect the following scenario: 1. State Treemap indicates the user “bar” that a new divergence is generated by the user “foo’ and located on the object A. 2. Presence awareness indicates “bar” that “foo” is connected now. 3. “bar” starts a Visio-conferencing with “foo” . Both of them discuss about the nature of the divergence. They can eventually use a realtime groupware tool to compare their uncommitted versions, to have more efficient interaction. They have all the elements to decide if the divergence is risky or not, to continue to
work in parallel or to re-synchronize immediately. They can manage their divergence. That is the main goal of State Treemap widget.
[4]
[5]
6 Conclusion and Future Works State Treemap is a workspace awareness widget designed to support divergence for a large number of objects. State Treemap is now integrated in the Motu platform and used by the architects. We plan to make a usability study in a realistic situation. State Treemap allows people to be aware about divergence. However, divergence is not really quantified. If two people are working just on one shared object, they will just see “potential conflict” and they cannot be aware if divergence is growing or not. State Treemap does not handle dependencies between objects. If two people are working on two shared objects A and B, and these two objects have a strong constraints between them, State Treemap will not detect the conflict. We are working on a divergence metric to really quantify divergence and to handle object dependencies. This metric can be the basic for new multi-synchronous awareness widgets.
[6]
[7]
[8]
[9]
7 Acknowledgments [10]
Our thanks to Tarik Hrouch, student of University Nancy 1, for his contribution to the development of State Treemap. And many thanks for the anonymous reviewers of this paper. This work has been partially funded by the CNRS and Region Lorraine under a BDI grant.
[11]
References [1]
[2]
[3]
L. Allen, G. Fernandez, K. Kane, D. Leblang, D. Minard, and J. Posner. ClearCase MultiSite: Supporting geographically-distributed software development. In J. Estublier, editor, Software Configuration Management: Selected Papers of the ICSE SCM-4 and SCM-5 Workshops, number 1005 in Lecture Notes in Computer Science, pages 194–214. Springer-Verlag, October 1995. R. Bentley, W. Appelt, U. Busbach, E. Hinrichs, D. Kerr, K. Sikkel, J. Trevor, and G. Woetzel. Basic support for cooperative work on the world wide web. International Journal of Human-Computer Studies, 46(6):827–846, 1997. G. Canals, C. Godart, F. Charoy, P. Molli, and H. Skaf. COO approach to support cooperation in software developments. IEE Proceedings Software Engineering, 145(2-3):79–84, 1998.
[12]
[13]
[14]
P. Dourish. A divergence-based model of synchrony and distributed in collabortive systems. Technical Report EPC-1994-102, Rank Xerox Research Centre, Cambridge Laboratory, 1994. P. Dourish. The parting of the ways: Divergence, data management and collaborative work. In Proceedings of the Fourth European Conference on Computer-Supported Cooperative Work, CSCW Mechanisms II, pages 215–230, 1995. J. Estublier, editor. Software Configuration Management: Selected Papers of the ICSE SCM-4 and SCM-5 Workshops, number 1005 in Lecture Notes in Computer Science. Springer-Verlag, October 1995. P. H. Feiler. Configuration management models in commercial environment. Technical Report CMU/SEI-91-TR-7 ADA235782, Software Engineering Institute (Carnegie Mellon University), March 1991. P. H. Feiler and G. F. Downey. TransactionOriented Configuration Management: A Case Study. Technical Report CMU/SEI-90-TR-23 ESD-90/TR-224, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania 15213, November 1990. G. Fitzpatrick, T. Mansfield, S. Kaplan, D. Arnold, T. Phelps, and B. Segall. Augmenting the workaday world with Elvin. In S. Bødker, M. Kyng, and K. Schmidt, editors, Proceedings of the Sixth European Conference on Computer Support Cooperative Work (ECSCW-99), pages 431–450, Dordrecht, NL, September 12–16 1999. Kluwer Academic Publishers. C. Godart, G. Canals, F. Charoy, and P. Molli. About some Relationships between Configuration Management, Software Process and Cooperative Work: the COO Environment. In 5th Workshop on Software Configuration and Maintenance, Seatle, Washington DC (USA), LNCS 1005, April 1995. C. Godart, O. Perrin, and H. Skaf. Coo: A workflow operator to improve cooperation modeling in virtual enterprises. In 9th IEEE International Workshop on Research Issues in Data Engineering Information Technology for Virtual Enterprises (RIDE-VE’99), 1999. S. Greenberg, C. Gutwin, and A. Cockburn. Awareness through fisheye views in relaxedWYSIWIS groupware. In W. A. Davis and R. Bartels, editors, Graphics Interface ’96, pages 28–38. Canadian Information Processing Society, Canadian Human-Computer Communications Society, May 1996. ISBN 0-9695338-5-3. S. Greenberg, C. Gutwin, and A. Cockburn. Using distortion-oriented displays to support workspace awareness. In Proceedings of the HCI’96 Conference on People and Computers XI, ComputerSupported Cooperative Work, pages 299–314, 1996. C. Gutwin and S. Greenberg. Design for individuals, design for groups: Tradeoffs between power and workspace awareness. In Proceedings of ACM
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
CSCW’98 Conference on Computer-Supported Cooperative Work, Shared Visual Spaces, pages 207–216, 1998. C. Gutwin, S. Greenberg, and M. Roseman. Workspace awareness in real-time distributed groupware: Framework, widgets, and evaluation. In Proceedings of the HCI’96 Conference on People and Computers XI, Computer-Supported Cooperative Work, pages 281–298, 1996. C. Gutwin, S. Greenberg, and M. Roseman. Workspace awareness support with radar views. In Proceedings of ACM CHI 96 Conference on Human Factors in Computing Systems, volume 2 of SHORT PAPERS: Supporting Awareness of Others in Groupware (Short Papers Suite), pages 210– 211, 1996. C. Gutwin and M. Roseman. A usability study of workspace awareness widgets. In Proceedings of ACM CHI 96 Conference on Human Factors in Computing Systems, volume 2 of SHORT PAPERS: Supporting Awareness of Others in Groupware (Short Papers Suite), pages 214–215, 1996. C. Gutwin, M. Roseman, and S. Greenberg. A usability study of awareness widgets in a shared workspace groupware system. In Proceedings of the ACM 1996 Conference on Computer Supported Work, pages 258–267, New York, November 16–20 1996. ACM Press. A. Haake, J. M. Haake, and D. Hicks. On merging hypertext networks. In European Conference on Computer Supported Cooperative Work, 1995. B. Johnson. TreeViz: Treemap visualization of hierarchically structured information. In P. Bauersfeld, J. Bennett, and G. Lynch, editors, Proceedings of the Conference on Human Factors in Computing Systems, pages 369–372, New York, NY, USA, May 1992. ACM Press. J. Lipnack and J. Stamps. Virtual Teams: Reaching Across Space, Time, and Organizations with Technology. Wiley, 1997. S. Minor and B. Magnusson. A model for semi-(a)synchronous collaborative editing. In Proceedings of the Third European Conference on Computer-Supported Cooperative Work, pages 219–231, 1993. J. Munson. Synchronization in Collaborative Applications. PhD thesis, The University of North Carolina at Chapel Hill, 1997. J. P. Munson and P. Dewan. A flexible object merging framework. In Proceedings of ACM CSCW’94 Conference on Computer-Supported Cooperative Work, Technologies for Sharing I, pages 231–242, 1994. W. Prinz. NESSIE: An awareness environment for cooperative settings. In S. Bødker, M. Kyng, and K. Schmidt, editors, Proceedings of the Sixth European Conference on Computer Support Cooperative Work (ECSCW-99), pages 391–410, Dordrecht, NL, September 12–16 1999. Kluwer Academic Publishers.
[26] M. Roseman and S. Greenberg. Teamrooms: Network places for collaboration. In Proceedings of ACM CSCW’96 Conference on ComputerSupported Cooperative Work, Places for Collaboration, pages 325–333, 1996. [27] C. Schuckmann, L. Kirchner, J. Schummer, and J. M. Haake. Designing object-oriented synchronous groupware with COAST. In Proceedings of ACM CSCW’96 Conference on ComputerSupported Cooperative Work, Language Support for Groupware, pages 30–38, 1996. [28] B. Shneiderman. Tree visualization with treemaps: A 2-D space-filling approach. ACM Transactions on Graphics, 11(1):92–99, January 1992. [29] SourceForge. Breaking down the barriers to open source development. Online http://www.sourceforge.net, (28 June 2000). [30] J. Tam, L. McCaffrey, F. Maurer, and S. Greeberg. Change awareness in software engineering using two dimensional graphical design and development tools. Technical Report 2000-670-22, University of Calgary, Alberta, Departement of Computer Science, October 2000. [31] J. J. van Wijk and H. van de Wetering. Cushion treemaps - visualization of hierarchical information, 1999. [32] M. Wertheimer. Principles of perceptual organization. D. S. Beardslee and M. Wertheimer, editors, Readings in perception, Van Nostrand-Reinhold, Princeton, NJ, 1958. Abridged translation by M. Wertheimer; original work published 1923. [33] XMLDiff. Xml diff and merge tool. Online http://alphaworks.ibm.com/, (28 June 2000). [34] A. Zeller. A unified version model for configuration management. In G. Kaiser, editor, Proceedings of the 3rd ACM SIGSOFT Symposium on the Foundations of Software Engineering, volume 20 (4) of ACM Software Engineering Notes, pages 151–160. ACM Press, October 1995.
