Supporting Collaborative Information Sharing with the World Wide Web: The BSCW Shared Workspace System

Transcription

1 Supporting Collaborative Information Sharing with the World Wide Web: The BSCW Shared Workspace System Richard Bentley, Thilo Horstmann, Klaas Sikkel and Jonathan Trevor Abstract The emergence and wide-spread adoption of the World Wide Web (W3) offers a great deal of potential for the developers of collaborative technologies, both as an enabling infrastructure and a platform for integration with existing end-user environments. This paper describes a system which attempts to exploit that potential by extending the W3 to provide a set of basic facilities for collaborative information sharing. The BSCW Shared Workspace system was conceived as an alternative to tools which currently support collaborative working for widelydispersed working groups such as electronic mail and ftp. We report on the design and implementation of our system, the problems we encountered and the benefits accruing from our choice of the W3 as an enabling platform, and using our experiences suggest how recent developments in the W3 point the way to more suitable and powerful mechanisms to support the development of collaborative systems. Keywords: CSCW, Information Sharing, Applications Introduction In its current form, the World Wide Web (W3) provides a simple and effective means for users to search, browse and retrieve information, as well as to make information of their own available for others. The utility of this approach, whereby providers design and retain control over the form and content of their information, is evident from the growth of the W3 to become the primary means of accessing information over the Internet. This approach, however, does not provide support for more collaborative information sharing, where widely-dispersed workinggroups can jointly author, comment and annotate documents, negotiating and developing the form and content of the information as part of a group, rather than an individual, activity. 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

2 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. Supporting Collaboration within Widely-distributed Work-groups The BSCW Shared Workspace system was conceived as a means of supporting the work of widely-dispersed work-groups, particularly those involved in large research and development projects. Members of such projects may come from a number of organisations, in different countries, yet have a need to share and exchange information and often collaborate over its production. The geographical distribution prohibits frequent face-to-face meetings, and would clearly benefit from computer support for the collaborative aspects of the work. Unfortunately, the lack of common computing infrastructure within the group often prohibits deployment of such technology and causes serious problems for system developers who must pay close attention to issues of heterogeneous machines, networks, and application software. As a consequence of these problems, despite over 10 years of research in the field of CSCW (Computer Supported Cooperative Work), 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: platform, network and operating system transparency, integration with end-user environments and application programs, a simple and consistent user interface across platforms, an application programmer interface for bolt-on functionality, and ease of deployment facilitating rapid system prototyping. Given this potential, it is unsurprising that a number of W3-based collaboration systems have been developed. We can classify these systems in four broad categories, based on the extent to which they depart from existing W3 standards: 1. Purely W3-based: Such systems use standard W3 clients, comply with HTML and HTTP standards, and only extend server functionality using the CGI interface. Any additional client functionality is provided by helper applications (we do not include client APIs here, such as CCI, as they are not standardised across clients and platforms). An example of such a purely W3-based system is reported in [4]. 2. Customised servers: As 1, but require special-purpose servers, to provide behaviour beyond the possibilities offered by CGI. Such systems still support standard W3 clients and protocols, but the enhancements may reduce the portability of the server itself. InterNotes [5] is an example of such a customised server. 3. Customised clients: As 1 (and sometimes 2), but require particular or modified clients (often to support non-standard HTML tags), or non-standard client APIs, and could not necessarily be used with different platforms or different clients. These systems do however support the HTTP protocol. The Sesame client for Ubique s Virtual Places system [6] is an example. 4. Web-related: Such systems may provide a W3 interface, but support only limited interaction using the HTTP protocol. The Worlds system [7] is an example of this category.

3 In this classification, the degree of W3 compliance decreases from 1 to 4; one might say that a system in Category 1 inherits all the benefits of the W3 listed above, while a system in Category 4 gives the developer a free-hand in choice of protocols, interface toolkits and so on but few of the benefits. A major goal of our work was to produce a useful and usable system one which could be deployed in our target domain and refined on the basis of actual usage feedback. We therefore set out the following design goals: 1. No modification to the HTTP protocol 2. No modifications to HTML, or client customisation other than through Helper applications 3. All server customisation to be performed through the CGI interface The following section describes the current version of the system we developed, and we then return to these three design goals to discuss the system s implementation. The BSCW Shared Workspace System The BSCW Shared Workspace system is a document storage and retrieval system extended with features to support collaborative information sharing. The system consists of a server which maintains a number of workspaces, accessible from different platforms using standard, unmodified W3 clients. Each workspace contains a number of shared information objects, and workspace members can perform actions to retrieve, modify and request more details on these objects. The objects we currently support are documents, links (to normal W3 pages and other workspaces), folders, groups and members. Figure 1 shows the user interface to a typical shared workspace, which is in fact the workspace we used in co-authoring this paper. 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 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 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 click on the event icon to get more infor-

4 mation (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

5 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,

6 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 Implementation of the BSCW System The key components of the BSCW system are an extended W3 server, a simple gdbm database to store data about workspace objects such as documents and members, and several platformspecific helper applications for transferring documents to the server (Figure 4). The documents themselves are stored on the Unix file-system, while the database contains information such as document creator and version number, member contact details and event information. The server makes extensive use of information in the database to generate the user interface to a workspace (Figure 1). The current version of the server itself is an extended NCSA HTTP 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.

7 Clients Macintosh Helper W3 client Helper PC W3 client Helper Sun W3 client Extended W3 server BSCW extensions + Python CGI Scripts delegated functionality NCSA W3 daemon Unix filestore Workspace Databases Documents in file hierarchy File I/O PUT requests GET, POST requests Figure 4. BSCW system architecture Implementation of the PUT method A lack of client support for selecting and sending documents to a HTTP daemon has required development of platform-specific helper applications. These helpers are started by a correctlyconfigured client when a special MIME-type is received, sent by the server when the Add Document button is pressed (Figure 1). The helpers provide a file-browsing interface to the local file-system, with versions for Macintosh, PC (Windows 95, NT, 3.1) and most Unix platforms currently implemented. The implementation of the PUT protocol is however not trivial; for example, the server must ensure that files cannot be added which would be interpreted as scripts or configuration files. Our solution to this problem is a double-handshaking between the server and the helpers to verify files can be added, resulting in an overly-complex protocol and introducing many points of possible failure. Furthermore, an implementation based on external helpers applications has implications for security and access control, as adding files to protected file-systems requires helpers to ask users for user-name and password details they may have already supplied to their W3 client. Full support for MIME-types The current server support for MIME-types relies on guessing the document type by examining its filename suffix. This is clearly unsuitable when documents must be shared between Macintosh (often no suffix, but a resource fork), PC (max. 3 character, case-insensitive suffix) and Unix (variable length, case-sensitive suffix) platforms. Thus our server does not use filenames to select MIME-types, but rather retrieves the document type from the object database, in some ways simulating the resource fork properties of a Macintosh document. When a document is added, the helper uses a local configuration file to guess a suitable MIME-type. As there is no guarantee this is correct, the user can override the helper s selection, as well as edit and extend the configuration file to suit their own requirements. It is worth noting, however, that although this method ensures that the correct application program is started, independently of a document s filename, many applications insist on a filename extension. This is particularly true on the PC, where the problem is compounded as it is not possible to configure most PC W3 clients to add an extension to received documents (as it is on the Sun, for example). More sophisticated access methods The current access models supported by W3 servers allow user- and group-based access control limiting ability to send GET, POST, PUT and other, as yet unimplemented, requests. Although the CERN server does implement per-file access control lists (ACLs), this still provides no way of expressing which actions (or scripts) can be requested in a particular context

8 (per-document and user), what files are visible to different users, and whether users can modify the access permissions of others. We have therefore extended these models by storing more complex ACLs as part of each object in the object database. These ACLs take the form of rules which describe the visibility of objects (for example, users can only see workspaces that they are members of) and the actions that users and groups can perform on them. These action rules are used by the server to suppress output of buttons which access action scripts denied to the current user, and by the scripts themselves to ensure the current user is authorised to perform the corresponding action. An enhanced user interface to the file-store The system requires a much richer, context-sensitive user interface to a workspace than is provided by standard server directory listings. In particular, the server must generate a different HTML page dependent on who the request is from, as users may have different actions they can perform (see above), different view-types selected, different event icons (dependent on when they last caught up ) and so on. This requires interaction with the database to retrieve member details and also to check document types and whether documents are currently checked-out in order to display appropriate icons. We were therefore forced to replace the existing directory listing routines for our BSCW server. More sophisticated logging The provision of awareness information regarding past activities of group members is essential for collaborative information sharing, as groups must coordinate their activities and maintain a shared understanding of the status of their work [9]. The event icons generated by the BSCW server are an attempt to support this awareness, but the logging facilities supported by existing servers only record request details and not the results of those requests. To capture this information and log it in a form suitable for the server to generate the event listing required generating and storing event objects in the workspace database. 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. Recommendations and Discussion Our experiences with the implementation of the BSCW system lead us to the following recommendations for extending the W3 for more collaborative work yet preserving the benefits as a cross-platform enabling technology: Client support for the PUT method: This is an obvious consequence of a more collaborative view of information sharing. The current state of the art requires developers to build their own, platform-specific helper applications if they wish to avoid modifying clients or using non-standard APIs and client features (such as the <ENCTYPE> attribute supported by recent versions of the Netscape clients). Reliance on external helpers creates potential problems with authentication, proxy servers and so on. Better support for MIME-types: This is required to enable true cross-platform information sharing. The current focus on file-name suffix creates problems for the Macintosh which

9 uses resource forks, and requires general consistency in document naming. These problems seem to be symptomatic of a more general problem with file naming, as many PC applications insist on a suffix being present when passed a document from a W3 client. A richer model of access control: The current methods provide little support for limiting information visibility, restricting access to certain functionality, and remote member administration. Differences in methods across servers inhibit the formulation of a richer and more general model. Improved user interface facilities: Although HTML was never claimed to be a user interface description language, this is a function to which it is often put. Although features such as the <FRAME> tag supported by recent versions of Netscape increase the possibilities, such features are not supported by all clients and there is clearly a limit to interface techniques, such as multiple selections and semantic feedback, that can be described with such extensions. Perhaps a more specific user interface description language is required. Better support for server customisation: The CGI interface does not allow customisation of core server functionality such as access logging, MIME-type mapping etc. Although some servers such as Apache and Netsite provide more extensive APIs, it is often the case that much server functionality is unused or needs to be replaced for custom applications. A cleaner method of removing, replacing and extending core components is required, perhaps in a similar manner to the module-based approach of the Spinner server [10]. These recommendations have arisen through an attempt to extend the W3 to support more collaborative information sharing, but many are more generally applicable; for example, client support for the PUT protocol is necessary for remote editing applications such as Grif [11], and the current support for MIME-types frustrates cross-platform document exchange. However, besides these general problems, in its current form the W3 suffers from a more serious limitation when considering support for collaborative sharing. This limitation concerns the fundamental architecture on which W3 is based, and becomes more apparent when we consider more synchronous sharing than that currently supported by the BSCW system. This architecture is based on a model of information provision which assumes information is relatively static, and no notification is required when information is changed. 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

10 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 Conclusions We have presented the BSCW Shared Workspace system and discussed our experiences with W3 as a platform for supporting collaborative work. The system is realised as an extended HTTP daemon, accessible from standard, unmodified W3 clients on a number of platforms. We are currently evaluating the system with the aid of researchers in several European countries, and we invite interested readers to install and try the system for themselves. (For details, see the BSCW home page 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. References [1]

11 [2] Patterson, J., Comparing the programming demands of single- and multi-user applications, in Proceedings of UIST 91, Hilton Head, SC, ACM Press, Nov , 1991, pp [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 , 1994, pp [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] [6] [7] [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 , 1995, pp [10] [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 , 1995, pp , [12] Rodden, T., Mariani, J. and Blair, G., Supporting cooperative applications, in Computer Supported Cooperative Work, 1 (1), Kluwer Academic Publishers, 1992, pp [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 , 1995, pp , [14] Author Details Richard Bentley, Thilo Horstmann, Klaas Sikkel and Jonathan Trevor German National Research Centre for Information Technology (GMD FIT.CSCW) Schloß Birlinghoven D Sankt Augustin Germany Phone: Fax: {bentley, horstmann, sikkel, trevor}@gmd.de

12