The Basic Support for Cooperative Work project (BSCW) at GMD is investigating the feasibility of extending the W3 to support such collaborative working. In this paper we report on the design and implementation of the BSCW Shared Workspace system; an extended W3 server which provides basic facilities for (primarily asynchronous) collaborative information sharing, activity awareness and integration of external applications across Macintosh, PC and Unix platforms. The system integrates the simple facilities found in ftp--namely storage and retrieval of documents--with more sophisticated features such as group and member administration, check-in/-out facilities and access to meta-information regarding documents and members. In addition, the system provides a simple, event-based awareness service to inform users, at-a-glance, of the current status and past changes to information held in the workspace.
By discussing the development of this system, we hope to contribute to the on-going debate regarding the extension of W3 protocols, architecture and so on to support more collaborative work--an area which the W3 Consortium has signalled as an important aspect of future W3 innovation [1]. In the next section we outline the motivation for our system and a more general focus on collaborative information sharing, and discuss the potential of the W3 as a basis for developing collaboration technologies. We then describe the design of the system in detail, and consider the implications of our experiences for possible extension of W3. We conclude that recent innovations, particularly in the area of client-computation, hold great potential and are a more suitable means of extension than radical change to either W3 protocols or architecture.
As a consequence of these problems, despite over 10 years of research in the field of CSCW (Computer Supported Cooperative Work), email and ftp remain the state-of-the-art in supporting collaboration within widely-distributed work-groups. Although such tools facilitate information exchange, they provide little support for information sharing, whereby details of users' changes, annotations and so on are made visible and available to all other participants. A conclusion drawn by many is that for more powerful CSCW technologies to flourish, a common infrastructure that addresses problems of integration is required, allowing developers to focus on application details rather than complexities of different system configurations (e.g. [2, 3]). The W3 is the first real example of such a common infrastructure, offering huge potential to CSCW system developers, through:
Each BSCW server maintains an index of all the workspaces it manages. Users access the index using a standard user-name and password scheme, and the server responds with a list of the workspaces the user can enter. Alternatively workspace members can access the workspace directly if they know the URL. New users are added to the server by completing (or having an existing member complete) a simple registration form which asks for a user-name and the new user's email address. This information is then used to check if the user is already known to the server, and if not, an initial password is generated and mailed to the user at the given address. This simple registration scheme requires users to give a valid email address in order to log on to the system. Once logged on, users can change their password to something more suitable.
In the current version of the system, to access a workspace a user must be a member of the group 'members', and can be added to this group by any existing group member. The member then sees a view of the root-folder of the workspace, similar to that in Figure 1. The form of this view is the same for each member, with a navigation bar at the top (and bottom) of the page, a (user-definable) workspace banner, a row of action buttons, and a listing of the contents of the current folder. The contents themselves are listed differently dependent on the view-type the user has currently selected.
In Figure 1, the member 'trevor' has selected the event-view of the root-folder of the 'Boston paper' workspace. He sees the workspace objects in this folder--in this case, a FrameMaker and a Microsoft Word document, two links to related W3 pages, a sub-folder, the 'members' group and the workspace Wastebasket. To the right of each object, one or more icons may be displayed which signal that events have occurred concerning that object. So in Figure 1, the document 'Boston draft' has been written, while the 'Screendumps' folder has been added to the workspace since 'trevor' last logged in. Other events signalled in this way include 'read', 're-named', 'moved', 'versioned', while a 'deleted' event is signalled by the Wastebasket object becoming 'full', as in Figure 1. Members can cli ck on the event icon to get more information (such as who caused it and when it occurred), and can 'catch-up' events, similar to catching up read articles in a Usenet newsgroup, by clicking the 'Catchup events' button above the workspace listing.
Figure 1. The user interface to a BSCW Shared Workspace
The event-view is one of three possibilities for interacting with a workspace. The three toggle buttons under and to the right of the action buttons allow members to switch between the event-view, the description-view and the action-view (Figure 2). The description view shows a one-line description of each workspace object, if one has been provided, while the action view displays a list of buttons which allow members to manipulate each object. These action buttons are generated based on the member's access rights; for example, only the creator of an object can 'destroy' that object (irrevocably remove it from the workspace), while all members may be able to 'check-out' a copy of a document object for editing. It is clear that these policies surrounding access to system functions have a great impact on how the system is used, and we have therefore deliberately isolated such policy decisions so that they can easily be tailored. To this end, we are currently working on an interface to allow members to specify the access policy associated with workspace objects.
Figure 2. 'Boston draft' in the event, description and action views
Documents can be added to a workspace using a simple, platform-specific 'helper application'. An appropriate helper must be installed on each members' machine, and is executed when the member clicks the 'Add Document' button (Figure 1). This helper allows members to select documents on their local file-store, specify a (possibly different) name for the document on the remote workspace, and transmit the document to the BSCW server. If the document is a new version of an existing document, the old version is moved to the workspace Wastebasket and a 'versioned' event is generated. The old version is therefore preserved and can be accessed unless explicitly 'destroyed' (Figure 2).
The system provides a simple check-in/check-out facility to assist with version management, using a form of 'soft-locks' to ensure members are aware of the current document status. If a member tries to retrieve a document which is currently checked-out, a notification message is returned showing who has the document, but provides the option for the member to retrieve the document anyway. We are currently working on a more powerful version and locking management system, but believe this basic approach provides at least an awareness of the current activities of group members. In addition to this facility, the system also provides more standard operations associated with document management, such as re-naming, moving and deleting. Following the Macintosh metaphor, deleted workspace objects are stored in the workspace Wastebasket, allowing them to be restored if necessary.
Finally, it is possible to request a page of information about each object in the workspace by clicking the 'info' button to the left of an object's icon (Figure 1). For document objects, this page includes details of the document creator, date added, MIME-type etc. (Figure 3), and for members this provides contact details, home page URL and so on. These pages allow members to access object actions (dependent on their access rights), such as 'edit description', and are integrated, so that in Figure 3 members can click on the 'document creator' and receive the info page on member 'trevor'.
This version of the BSCW Shared Workspace system is currently being evaluated with the aid of a number of researchers across Europe. Based on feedback from these trials, we hope to refine and extend the system to provide more flexible mechanisms which can be customised to the requirements of different work-groups; for example, we are currently investigating alternative methods of remote user administration, whereby users can 'subscribe' to workspaces or, conversely, where member administration might be performed by one or more 'privileged' users. Other topics for further work include multiple-group support, group mailing and mail archiving. Readers interested in trying out the system for themselves are invited to do so. Directions are provided at the end of the paper.
Figure 3. Information on the 'Boston draft' document
The current version of the server itself is an extended NCSA HTTP 1.4.2 daemon. While the majority of the extra functionality was provided through the CGI interface with Python scripts, it was necessary to add extra code and modify approximately 30 lines of the original server source. While a previous version of the system, built using the CERN server, was constructed entirely using the CGI interface [8], the restrictions this placed on the interface, and the need to duplicate much of the existing server functionality in the CGI scripts, led us to relax the third of our design goals as set out previously; as a consequence, our system falls into Category 2 of our classification of W3-based applications. To show why such server modification was necessary, we now focus on several key requirements which had to be supported by our system.
Figure 4. BSCW system architecture
Many of these innovations required modification of the core behaviour of the HTTP server. However, rather than simply replacing server code with our own, we have extended the source so that our code is called only if the server is used to access a workspace, otherwise the server functions as a normal HTTP daemon. All the software required to install the system is public domain and commonly available, and, more importantly, we have made no modifications to clients, HTML or HTTP. We therefore believe our system retains the advantages of W3 as an enabling platform, and provides a basic, though useful, set of facilities to support a more collaborative model of information sharing.
This is a well-known argument in CSCW, concerning the distinction between multi-user and collaborative systems. Briefly (see [12] for more details), while a multi-user system seeks to hide the activities of other users to give each the impression they are interacting with a dedicated system, a collaborative system must often propagate and explicitly represent other users' activities to provide a common context for the collaborative work taking place. For the W3, all interaction is handled by the central server which gives no indication of who else is, or has been, viewing the same page. Although the current, 'consumer-provider' model of information exchange does not require such awareness support, this is not the case for more collaborative information sharing [9]. The problem is highlighted by a number of previous system developments [e.g. 4], and is manifest in many current debates including the provision of shared virtual worlds in VRML.
It is tempting to suggest that this model of sharing requires a radical extension to the basic W3 architecture. Indeed, this is one approach being taken in the Stanford Digital Library Project, where the use of CORBA protocols to support meta-information objects such as annotations is being investigated [13]. Although the integration of more powerful mechanisms like CORBA might address many of the current problems, it is clear that much work needs to take place before applications can be developed and deployed which make use of such advanced features. Instead, we suggest that the key to a more collaborative W3 in the short term lies in extending the basic mechanisms, preserving the simplicity and utility of the current approach. Ubique's Virtual Places system [6] offers one method through addition of a second server responsible for event-propagation, but currently relies on the use of particular W3 clients. Perhaps a more flexible and extensible solution, however, is the integration of safe interpreter environments with W3 clients, allowing arbitrary code to be retrieved and executed at the client site. This approach--perhaps best developed in Sun's HotJava support for their Java language [14]--has the additional advantages of reducing network traffic and the load on servers.
To demonstrate the potential of this approach, we have extended the BSCW system with a simple 'talk facility' implemented using Java Applets (Figure 5). As with Virtual Places, end-users interacting with the same workspace see each others' icons and can type simple messages, click on the icon to 'alert' a user, and establish a simple audio connection. We are currently experimenting with more advanced features such as shared pointers and simple shared editors, and we believe that this approach allows support for more synchronous collaborative information sharing, without compromising the existing W3 architecture. The recent decision of Netscape to license the Java interpreter for their own W3 clients makes this approach more realistic, and the benefits will become more apparent as richer interface toolkits and class libraries become available.
Figure 5. The Java 'talk' facility
The W3 offers an excellent opportunity to support collaboration within widely-dispersed work-groups. As an enabling platform, integrated with different hardware and software, it has the potential to overcome many of the problems with current collaborative systems. We feel that for this potential to be realised, it is important that enhancements should not compromise the current availability and usability of W3, and to this end, we argue for extension of current mechanisms rather than radical change in the short term. In this paper we have highlighted several areas for extension, and suggested that the current innovations in client-side computation hold promise for future development.
[2] Patterson, J., Comparing the programming demands of single- and multi-user applications, in Proceedings of UIST'91, Hilton Head, SC, ACM Press, Nov. 11-13, 1991, pp 87-95
[3] Trevor, J., Rodden, T. and Mariani, J., The use of adapters to support cooperative sharing, in Proceedings of CSCW'94, Chapel Hill, NC, ACM Press, Oct. 22-26, 1994, pp 219-230
[4] Frivold, R., Lang, R. and Fong, M., Extending WWW for synchronous collaboration, in Electronic Proceedings of Second WWW Conference: Mosaic and the Web,
[5] http://www.lotus.com/inotes
[6] http://www.ubique.com/
[7] http://acsl.cs.uiuc.edu/kaplan/worlds.html
[8] Pollak, B., Spezifikation und Implementierung von geographisch weit verteilten Arbeitsbereichen, Master's Thesis, University of Kaiserslautern, Germany, March 1995
[9] Fuchs, L., Pankoke-Babatz, U. and Prinz, W., Supporting cooperative awareness with local event mechanisms: The GroupDesk system, in Proceedings of ECSCW'95, Stockholm, Kluwer Academic Publishers, Sept. 11-15, 1995, pp 247-262
[10] http://spinner.infovav.se/
[11] Quint, V., Roisin, C. and Vatton, I., A structured authoring environment for the World-Wide Web, in Computer Networks and ISDN Systems: Proceedings of the Third International W3 Conference, Darmstadt, Apr. 10-14, 1995, pp 831-839,
[12] Rodden, T., Mariani, J. and Blair, G., Supporting cooperative applications, in Computer Supported Cooperative Work, 1 (1), Kluwer Academic Publishers, 1992, pp 41-67
[13] Röscheisen, M., Mogensen, C. and Winograd, T., Beyond browsing: Shared comments, SOAPs, Trails, and on-line communities, in Computer Networks and ISDN Systems: Proceedings of the Third International W3 Conference, Darmstadt, Apr. 10-14, 1995, pp 739-749,
[14] http://java.sun.com