The World Wide Web as enabling technology for CSCW: The case of BSCW

Transcription

1 Academic Publishers, Amsterdam. Abstract The World Wide Web as enabling technology for CSCW: The case of BSCW Richard Bentley, Thilo Horstmann and Jonathan Trevor CSCW Group, Institute for Applied Information Technology (GMD FIT) German National Research Centre for Computer Science Schloß Birlinghoven D Sankt Augustin Germany Despite the growth of interest in the field of CSCW, and the increasingly large number of systems which have been developed, it is still the case that few systems have been adopted for widespread use. This is particularly true for widely-dispersed, cross-organisational working groups where problems of heterogeneity in computing hardware and software environments inhibit the deployment of CSCW technologies. With a lightweight and extensible client-server architecture, client implementations for all popular computing platforms, and an existing user base numbered in millions, the World Wide Web offers great potential in solving some of these problems to provide an enabling technology for CSCW applications. We illustrate this potential using our work with the BSCW shared workspace system an extension to the Web architecture which provides basic facilities for collaborative information sharing from unmodified Web browsers. We conclude that despite limitations in the range of applications which can be directly supported, building on the strengths of the Web can give significant benefits in easing the development and deployment of CSCW applications. Keywords World Wide Web, BSCW, Enabling technologies, Information sharing 1. Introduction Over the last decade the level of interest in the field of CSCW has grown enormously and an ever-increasing number of systems have been developed with the goal of supporting collaborative work. These efforts have led to a greater understanding of the complexity of group work and the implications of this complexity, in terms of the flexibility required of supporting computer systems, have driven much of the recent work in the field. Despite these advances, however, it is still the case that few cooperative systems are in widespread use and most exist only as laboratory-based prototypes. This is particularly true for widely-dispersed working groups, where electronic mail and simple file-transfer programs remain the state-ofthe-art in providing computer support for collaborative work. In this paper we examine the World Wide Web (Berners-Lee et al. 1994) as a technology for enabling development of more effective CSCW systems. The Web provides a simple client-server architecture with client programs (browsers) implemented for all popular computing platforms and a central server component that can be extended through a standard API. The Web has been extremely successful in providing a simple method for users to

2 search, browse and retrieve information as well as publish information of their own, but does not currently offer features for more collaborative forms of information sharing such as joint document production. There are a number of reasons to suggest the Web might be a suitable focus for developers of CSCW systems. For widely-dispersed working groups, where members may be in different organisations and different countries, issues of integration and interoperability often make it difficult to deploy existing groupware applications. Although non computerbased solutions such as telephone and video conferencing technologies provide some support for collaboration, empirical evidence suggests that computer systems providing access to shared information, at any time and place and using minimal technical infrastructure, are the main requirement of groups collaborating in decentralised working environments (Rao 1995, Gorton et al. 1996). By offering an extensible centralised architecture and cross-platform browser implementations, increasingly deployed and integrated with user environments, the Web may provide a means of introducing CSCW systems which offer much richer support for collaboration than and FTP, and thus serve as an enabling technology for CSCW. In the following section we discuss the need for such enabling technologies for CSCW to address problems of system development and deployment. We then give an overview of the Web architecture and components and critically examine these in the context of CSCW systems development. We suggest that the Web is limited in the range of CSCW systems that can be developed on the basic architecture and, in its current form, is most suited for asynchronous, centralised CSCW applications with no strong requirements for notification, disconnected working and rich user interfaces. We illustrate this with examples from our work with the BSCW shared workspace system an integrated set of cooperation tools offering basic facilities for information sharing from unmodified Web browsers. We reveal benefits of the Web as a platform for deploying such applications in real work domains, and conclude with a discussion of some current developments which may ease the limitations of the Web as a platform for system development and increase its utility as an enabling technology for CSCW. 2. Moving out of the laboratory: The need for enabling technologies for CSCW Most of the CSCW systems which have been developed to date have been constructed in laboratories as research prototypes. This is perhaps not surprising, as CSCW systems place novel requirements on underlying technology such as distributed systems and databases (Rodden et al. 1992), and many of the mechanisms developed to support multi-user interaction do not address issues of cooperation such as activity awareness and coordination. This has focused much attention on the development of mechanisms to support floor management, user interface coupling, update propagation and so on, and has resulted in a range of experimental systems tailored to the particular issues being investigated. The proprietary and incompatible architectures on which many are based, the esoteric hardware and software required and the lack of integration with existing application programs and data formats inhibits deployment outside the laboratory and within the intended application domain. It might be argued that this situation is not unduly problematic; issues of system deployment are implementation concerns and would be addressed by re-implementation of system prototypes. The lack of system deployment does however pose a serious question to CSCW: if systems built to investigate particular models or mechanisms are never deployed and evaluated in use, how can we determine the effectiveness of these models and page 2

3 mechanisms in supporting cooperative work? A central concern of CSCW is the need for systems which are sensitive to their contexts of use, and a body of empirical data exists to show the problems caused when systems are introduced which do not resonate with existing work practice. When systems do not leave the research laboratory it is difficult to see how the models and mechanisms they propose can be assessed other than from a technical perspective. Recent calls for CSCW systems to be designed so they can be evaluated in use (Bannon 1996) and for a more situated approach to system evaluation (Twidale et al. 1994) reflect this need to migrate CSCW systems out of the laboratory and into the field if we are to eventually provide more effective systems. This migration is far from trivial, as the diversity of machines, operating systems and application software which characterises the real work domain is often far removed from the homogeneity of the laboratory. This is particularly true for working groups which cross departmental or organisational boundaries, where issues of integration and interoperability mean it is extremely unlikely that systems developed as research prototypes can be directly deployed. Adaptation or re-implementation of system prototypes for deployment outside the laboratory is usually beyond the resources of most research projects, suggesting that the issue of system deployment and the attendant problems should not be tackled at the end of the prototype development, but should be a central focus of the system design. Developing CSCW systems that integrate smoothly with systems, applications and data formats already in place in the work domain adds considerably to what is already a complex design task. A number of researchers have pointed to the need for tools to assist with the development of CSCW systems (e.g. Patterson 1991, Dewan and Choudhary 1992), removing some of the complexity of user interface, application and distributed systems programming which developers currently face. Such enabling technologies would ease problems of system development and allow a more evolutionary approach an approach otherwise prohibited by the investment necessary to create system prototypes and the need to commit to policy decisions at an early stage in a system s design. Work in CSCW is already addressing these issues through development of toolkits or application frameworks with components which can be instantiated and combined to create groupware systems. Toolkits such as GroupKit (Roseman and Greenberg 1995) are by now relatively mature, and seem to reduce the complexity of CSCW system development in much the same way that user interface toolkits allow rapid development of single-user interfaces. As we have shown, the desire for enabling technologies for CSCW lies not only in easing problems of prototype construction but also facilitating deployment and thereby evaluation of system prototypes in real work domains. As yet, most CSCW toolkits focus primarily on system development and issues of cross-platform deployment, integration with existing applications and so on are secondary. In this regard more than any other the World Wide Web seems to offer potential as an enabling technology for CSCW: Web client programs (browsers) are available for all popular computing platforms and operating systems, providing access to information in a platform independent manner, browsers offer a simple user interface and consistent information presentation across these platforms, and are themselves extensible through association of external helper applications, browsers are already part of the computing environment in an increasing number of organisations, requiring no additional installation or maintenance of software for users to cooperate using the Web, page 3

4 many organisations have also installed their own Web servers as part of an Internet presence or a corporate Intranet and have familiarity with server maintenance and, in many cases, server extension through programming the server API. As a basis for deployment of CSCW applications in real work domains, the level of acceptance and penetration of Web technology in commercial and academic environments is grounds alone for suggesting that CSCW should pay serious attention to the World Wide Web. 3. The Web as enabling technology for CSCW [The Web] was developed to be a pool of human knowledge, which would allow collaborators in remote sites to share their ideas and all aspects of a common project (Berners-Lee et al. 1994, page 76) From its inception the Web was intended as a tool to support a richer, more active form of information sharing than is currently the case. Early implementations at CERN allowed the browsing of pages as is common today, but also supported annotation of these pages and addition of links between arbitrary pages, not just from pages on local servers the user can access and edit. Some of these concepts were carried through to early drafts of the standards for Web protocols and architecture which described features such as remote publishing of hypertext pages and check in/out support for locking documents to ensure consistency in a multi-author environment. To date these aspects have largely been side-lined while development of Web browsers, servers and protocols has focused on more passive aspects of information browsing. In this section we examine the Web as it currently exists as a platform for developing and deploying CSCW technologies, following a brief overview of the components on which it is based. 3.1 Components of the World Wide Web The Web is based on a simple client-server architecture that allows clients to request information from servers using a standard protocol called HTTP the HyperText Transfer Protocol 1. Web browsers use a standard naming scheme (the URL, or Uniform Resource Locator) to identify the particular information required and send a HTTP Request for this information to the Web server running on the machine on which this information is located. Access to information may be limited to specific users or machines and, if the browser does not send this information as part of the HTTP request, the server may have to request a valid user name and password before returning the information. Information may be stored on the server host machine in any format, and the server must tell the client what format the requested information is so it can handle it correctly. The server returns a HTTP Response consisting of a header which identifies the type of data (its MIME-type ) and a body which contains the requested information. Depending on the capabilities of the browser the information in the response body can be displayed directly (as with a GIF image for example) or its processing can be delegated to an external helper application (a Microsoft Word document might be displayed by launching the Word 1. In fact, it is hard to pin down exactly what the World Wide Web encompasses; for example modern Web browsers can access services using protocols other than HTTP (such as FTP and gopher), which has undoubtedly contributed to the success of these technologies (Dix 1997). Here we focus only on those components introduced by the Web which we consider to be the core HTTP, HTML and CGI. page 4

5 application). All browsers can be configured to do different things depending on the MIMEtype of the information received The HyperText Transfer Protocol (HTTP) [HTTP] is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods (commands). A feature of HTTP is the typing of data representation, allowing systems to be built independently of the data being transferred. (HTTP 1.0 specification 2 ) HTTP was designed as a very simple request-response protocol. The commands of HTTP are the request methods used by browsers to ask for particular services from a Web server. The most common are the GET method, used to request an information entity (a HTML page, document, sound clip etc.), the POST method for transmitting HTML form data to a server, and the HEAD method which is similar to GET but asks the server only for the HTTP header for an information entity, not the information itself. This last is used by programs like Web indexers ( robots etc.) to check if information known to be held on the server has been modified recently. Other methods like PUT (for sending documents to a Web server), DELETE and more are currently vaguely specified and a standard implementation is not provided by the majority of browsers and servers. HTTP is a stateless protocol; servers can process requests from Web browsers independently of any previous request. This allows development of lightweight server components and is ideal for simple document retrieval or browsing. Any state information must be preserved by the client and passed to the server as part of the HTTP Request. So, for example, if access to information requires user authentication with a user name and password, the Web browser must pass the name and password with every request to the server; the Web architecture and HTTP protocol provide no concept of a session. A strength of the HTTP protocol is its independence from the format of the transmitted data. This allows extension of clients and servers to handle new data formats; servers can be configured to recognise new data formats and return the correct MIME-type, while browsers can be configured to handle new types of data by registering new helper applications. All browsers can however directly interpret and display documents in HTML format The HyperText Markup Language (HTML) The HyperText Markup Language (HTML) is a simple data format used to create hypertext documents that are portable from one platform to another. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of domains... a number of new features of HTML are being proposed and experimented in the Internet community (HTML 2.0 specification 3 ) HTML is a simple document markup language which can transform a plain text document into a hypertext node. Using simple mark-up tags authors can indicate sections of the document are links to other information entities, and specify the URL for the entity the client should request if the user clicks on that section. In this way a number of HTML pages possibly held on different servers can be linked together to form a single hypertext. Mark-up tags are also used to specify the structure of a Web document. Originally these tags (like <H1> for a first-level heading) were intended to specify structure only and not how a document should be displayed. This is a powerful approach, as HTML documents can page 5

6 be parsed and appropriately presented by browsers running on very different hardware, including character-based terminals, small PDAs, Braille terminals for the blind as well as the more usual desktop machines. Recent extensions have however added a number of presentation mark-up tags to HTML, some of which are now being standardised in the most recent specification (HTML 3.2). A big advantage of HTML is its simplicity, both for Web page authors and for browsers which can interpret HTML documents using a very simple parsing algorithm. Most browsers simply ignore HTML tags they do not understand, allowing experimentation with new tags without defeating old browsers. Although it is sometimes argued that HTML would benefit from extension with more content-oriented tags like abstract and keywords (as are provided by other formatting languages like nroff and LaTeX), it is likely that the need for simple, rapid parsing, portability and support for older Web browsers will remain primary design goals The Common Gateway Interface (CGI) The Common Gateway Interface (CGI) is a standard for interfacing external applications with information servers, such as HTTP or Web servers. A plain HTML document that the Web daemon [server] retrieves is static, which means it exists in a constant state: a text file that doesn't change. A CGI program, on the other hand, is executed in real-time, so that it can output dynamic information (CGI 1.1 overview 4 ) The helper application mechanism described above is a means of extending Web browsers to handle different types of data. At the server side, most Web servers provide one or more Application Programming Interfaces (APIs) for extending the server with new functionality. The de-facto standard is the Common Gateway Interface (CGI), currently supported by all major Web servers. To extend a Web server though the CGI requires configuring the server to treat some HTTP requests as calls to developer-supplied programs or scripts, and to invoke these programs rather than handle the request itself. CGI specifies the request information (the URL requested, HTML form field values and so on) which is passed to the script. The script is expected to provide a reply to return to the client (often a HTML page), allowing development of Web pages with dynamic content, such as a page showing the output of the Unix finger command. The CGI script may be a very simple routine or an interface to a complex application like a database (Figure 1). There are a number of factors which have led to CGI becoming the standard server API and being implemented by all major Web servers: simplicity: CGI is straightforward to understand and implement, well defined standard: The current standard (CGI/1.1) is a robust and tested specification, language independence: CGI scripts can be written in most programming languages, architectural independence: CGI does not require a particular server architecture, process isolation: CGI scripts generally run as separate processes, so that buggy scripts cannot crash the Web server (or access its private internal state) page 6

7 W3 client e.g. Netscape HTTP request W3 server e.g. Apache request details CGI script integration with other applications HTTP reply reply details Figure 1. Extending a Web server via the Common Gateway Interface 3.2 Developing Web-based CSCW applications Despite the lack of direct support for collaboration, the current Web architecture does hide some of the complexity of deploying applications in a distributed, heterogeneous environment. The most common method of doing this is by extending a Web server through the CGI with new application functionality or glue code to an existing application, presenting the application user interface as a series of HTML pages which can be displayed by standard Web browsers. With this approach developers can take advantage of the existing base of browsers as client programs for their applications but must accept the constraints of the basic Web architecture and protocols as currently implemented and the limitations of existing Web browsers. These constraints are severe, inhibiting the development and deployment of CSCW applications in a number of areas: Communication: There is no support for server-server, (server initiated) server-client or client-client communication, problematic for applications where the server needs to play an active role (e.g. to notify users of changes to information or maintain information consistency over several servers). One consequence is that applications are now in common use which poll Web servers periodically to check if pages have been updated, allowing users to monitor Web sites of interest (e.g. Netscape s SmartMarks). Users can specify a very small time interval between checks, even for pages which change rarely, leading to huge amounts of unnecessary traffic on the Internet and hits on Web servers. Pure centralised architecture: The architecture provides no support for distribution of information or computation between clients and servers or replication across servers. Expensive, powerful and fault-tolerant machines are required to run a Web server if it is to scale to a large number of users. Even simple computations are not performed by the client, for example to check if a user has filled in all the fields of a form, resulting in unnecessary network traffic, server loading and slow feedback times for the user. The lack of support for replication means that disconnected working is not possible. No guaranteed Quality of Service : The HTTP protocol does not support the specification of guaranteed transmission rates between servers and clients. Data transfer is often bursty, subject to network and server loading which might vary considerably during a single transmission. This is unsuitable for transmission of (real-time) continuous media like audio and video, and alternative protocols such as RTP, the Real-Time Protocol, have been proposed for these media types. User interface design: HTML is not a user interface design toolkit, and although mark-up tags are provided for simple form-filling widgets like input fields these do not support features now common in desktop user interfaces such as drag and drop, multiple selection and semantic feedback. Although some browser vendors have introduced new tags to provide features like multiple, independent screen areas (Netscape Frames) they do little page 7

8 to broaden the possibilities for user interface design (and are not supported by all browsers). A fundamental problem here is the lack of server-client notification (see above); it is easy for the interface to become inconsistent with the information on the central server and is only updated when the user reloads the entire page. Some of these limitations are not so much problems with Web components like HTTP and HTML but more with the current implementations of browsers and servers. For example there is no reason why a server could not act as a client and vice versa to allow a form of update propagation and notification. (In fact some servers can send requests as well as handle them, often to act as a proxy for routing requests through a firewall.) These limitations do however restrict the kinds of CSCW systems which can be developed as extensions of the Web using the CGI, and suggest that the Web in its current form is largely unsuitable for developing systems which require highly-interactive user interfaces, rapid feedback and feedthrough (user interface updates in response to others interactions) or a high degree of synchronous notification. Of course, extending a Web server through the CGI programming interface is not the only method of deploying a CSCW system on the Web, and more radical approaches can remove some of the constraints of the basic architecture. Based on the extent to which a developer must modify the basic Web components, we can identify the following approaches: 1. Extending through CGI: As described above, where no modifications are required to protocols, browsers or servers. Any additional client functionality is provided through helper applications. The BSCW system described in the next section is an example of such a system. 2. Customising/building a server: Building a special-purpose Web server may be necessary to achieve adequate performance or security, or to introduce new functionality such as server-initiated notification. This approach requires deployment of the server software and any other application code, but is sometimes a better method of enabling access to existing applications from the Web in a more flexible and secure manner than CGI. The BASIS WEBserver, which enables Web access to the BASISplus document management system 5, is a good example of this. (See Trevor et al for a more detailed consideration of CGI versus specialised server approaches to deploying applications on the Web.) 3. Customising/building a client: Building a special-purpose client allows applications other than Web browsers to communicate with Web servers using HTTP, such as the coordinator clients developed for the WebFlow distributed workflow system (Grasso et al. 1997). Customising a client may also be necessary to interpret non-standard HTML tags such as those proposed by Vitali and Durand (1995) for version control to support collaborative editing of HTML documents. Custom clients can be used in conjunction with custom servers to provide additional services; as part of their Virtual Places system 6, the Ubique client can interact with the Virtual Places server to provide synchronous communication and a form of presence awareness. 4. Providing a Web interface: Some systems such as Worlds (Fitzpatrick et al. 1995) provide a Web interface but are not designed specifically for deployment on the Web. These applications use other means of providing the user interface, managing data and event distribution and so on, and only limited interaction is possible using a Web browser and HTTP page 8

9 Using this classification the flexibility for the developer increases from 1 to 4, and many of the problems identified above can be solved by specialising or replacing components such as clients and servers to provide richer mechanisms for the user interface, update propagation and so on. Of course, this level of flexibility is bought at the price of the innovation required from developers to build or integrate these components, and it should be obvious that very soon we may find ourselves back to square one; with a system which cannot be deployed outside the laboratory due to particular hardware and software requirements and a lack of integration with existing user environments. In this case, if our goal is eventual deployment and evaluation in real work domains, there seems little point in using the Web as a platform for CSCW system development. Despite these problems however we would strongly argue that the Web is an enabling technology for CSCW. The limitations identified above mean the Web is more suited to asynchronous, centralised applications with no strong requirements for synchronous notification, disconnected working and rich user interfaces. The advantages however an accepted technology, integrated with existing user environments and extensible through the server API without requiring additional client software on users machines indicate that here we have a method of deploying and evaluating basic mechanisms to support collaboration in real work domains. Further, the rapid pace of development in Web technologies suggests that many proprietary and experimental features which address some of the current limitations could become standards in the future. Of course much depends on the willingness of the main browser vendors (currently Netscape and Microsoft) to agree on and implement these features, but this does not seem to have been a problem to date. As Web technology matures some of the current problems with CSCW development on the Web should be solved. To illustrate the potential of the Web for enabling development and deployment of CSCW systems we now describe our work with the BSCW shared workspace system. Our intention here is to show the possibilities for developing CSCW systems without modifying Web components and thus reducing the utility of the Web as a platform for system deployment. In the final section of the paper we show how recent developments have the potential to broaden the range of CSCW systems which can be directly implemented using the Web. 4. The BSCW shared workspace system The BSCW (Basic Support for Cooperative Work) project at GMD is concerned with the integration of collaboration services with existing environments, supporting widely-dispersed working groups with different computing, network and software infrastructures. The BSCW shared workspace system is the basis for these services, which include features for uploading documents, version management, group administration and more, all accessible from different platforms using unmodified Web browsers. The system is an extension of a standard Web server using the CGI programming interface. The intention is to extend the basic Web architecture with mechanisms to support cooperation and information sharing and provide a stable platform on which more powerful tools can be implemented, deployed and evaluated. We give a brief overview of the system functionality (for a more comprehensive description see Bentley et al. 1997), the system s implementation as a CGI extension of a Web server, and some initial results from system deployment All BSCW software described in this paper is freely available for downloading; to obtain the software, use our public server, or for more information on the BSCW project see page 9

10 4.1 Sharing information with the BSCW system The BSCW system is based on the notion of a shared workspace which the members of a group establish for organising and coordinating their work. A shared workspace as realised by BSCW is a repository for shared information, accessible to group members using a simple user name and password scheme. Each BSCW server (a Web server extended with the BSCW system through the CGI) manages a number of such workspaces for different groups and users may be members of several workspaces (e.g. one workspace corresponding to each project a user is involved with). A shared workspace can contain information such as documents, images, links to other Web pages or FTP sites, threaded discussions, member contact information and more. The contents of a workspace are represented as information objects arranged in a folder hierarchy (Figure 2). Members can transfer (upload) information from their machines to a workspace and set access rights to control the visibility of this information and the operations which can be performed by others. In addition, members can download, modify and request more details on the information objects by clicking on HTML links to request workspace operations from the BSCW server. After each operation the server returns a new HTML page showing the new state of the workspace. Figure 2 shows a sample workspace view. The workspace contains a number of different kinds of documents, a URL link to another Web page ( BSCW project page ), an article object representing an item for discussion ( Features of 2.0 ), a sub folder containing further workspace information and a document under version control ( Publications ). The last significant operation performed on each object is described, and a list of clickable event icons give information on other recent changes. The operations which can be performed are given below each object and a description is also presented if one has been supplied (as with the GIF image BSCW icon ) Access to workspace functions is provided by the buttons at the top of the page as well as the HTML links below each object. The former operate on the current folder being shown (so that add URL would return a HTML form to specify the name and URL of a URL link object to add to the current folder) while the latter perform operations on individual objects, such as rename, edit description etc. As a short cut, the checkboxes to the left of each object in combination with the buttons above or below the list of objects allow operations on multiple object selections. Clicking on an object name will perform different operations depending on the type of the object; clicking on a document will download it, possibly for display by the browser, display by an external helper application (as with a Microsoft Word document) or saving to disk, while clicking on a folder opens the folder and replaces the current view with a display of the folder contents. This last method of navigating down through a folder hierarchy is supplemented by a navigation bar at the top of the page presenting the current location and path; clicking on the first element of the path ( :bentley in Figure 2) returns to the current user s home folder, which lists all the workspaces of which the user is a member, and therefore has access to. page 10

11 Figure 2. HTML user interface for the BSCW shared workspace system Storing documents in a shared workspace The HTTP protocol and basic Web components provide no standardised support for sending documents to a Web server for remote publishing. Currently only the more recent versions of the Netscape browser support any form of document uploading, and this requires extension of a Web server to receive and store uploaded documents. The BSCW system includes this extension allowing Netscape users to upload documents to a BSCW server to store in a workspace folder by specifying the document to upload, its MIME-type and so on in a HTML form. For users of browsers other than Netscape we have implemented a set of helper applications which must be installed on the user s machine. These applications, versions of which exist for PC, Macintosh and Unix platforms, provide a richer functionality than the Netscape built-in method including multiple document upload and progress reporting (Figure page 11

12 3), but use the same protocol for formatting and transmitting documents to the BSCW server. Netscape users can indicate whether to use the built-in or helper upload methods by setting a flag in their personal preferences, and clicking on the add doc button (Figure 2) returns a HTML form or launches the helper application as appropriate. Figure 3. Uploading documents with the helper application The event service The event service provided by the BSCW system provides users with information on the activities of others with respect to objects in a workspace. Events are triggered when a user performs an action such as uploading a document, renaming a document and so on. The system presents the recent events to each user as event icons in the workspace listing (Figure 2). Recent in this context means events which have occurred for an object since the user last caught up ; an operation by which users can indicate they are aware of events that have occurred so far and no longer wish to see them in the workspace (like catching up articles in a Usenet newsgroup). Events can be caught up at different levels, from individual objects to complete workspace folder hierarchies. The system distinguishes several types of events in the workspace listing such as new, read, written and so on. The touch event (shown by a hand icon) signals that something has happened to an object inside a folder or other container. Clicking on an event icon returns a list of all events of the type which have occurred since the last catch-up. This service therefore provides a very simple form of event information regarding changes within the workspace; we are currently extending this with features for more active notification of changes using Member registration By default access to a shared workspace is restricted to users who possess a valid login consisting of a registered user name and password. Using the standard access control mechanisms supported by Web servers, the server can be configured to request user page 12

13 authentication information and validate the user name and password before handling a request. The BSCW system uses this method of basic authentication to provide a degree of security and to establish user identity for recording event information and access control. New members can be added to a workspace through an invitation from an existing member. Invited users must register with the server and specify a user name and password if they do not already hold a valid login, which is possible if the invited user is already a member of a different workspace on the server. It is also possible to configure the system to allow self-registration, whereby users can specify a user name and password to create a registration without first being invited by an existing member Additional services The system provides standard features for simple document management such as creating folders, renaming, moving and so on. To date much of our attention has focused on these simple features with the goal of providing a more comfortable environment for crossplatform document sharing for groups than is possible with or FTP. An important role for the BSCW system however is to provide a stable platform on which more advanced collaboration services can be implemented. Examples of this are the version management and access control services. Many collaborations involve some form of joint document production. The BSCW system includes an experimental version management feature to preserve a document version history. This service uses a form of soft-lock (Bäcker and Busbach 1996) to provide awareness of the current status of a document, such as who is editing it, without enforcing a stricter model of locking. Based on our experience we feel this model may be more appropriate in many situations for collaborative document authoring than a more constraining check in/out model; the initial implementation in BSCW is a means of testing this hypothesis. Similarly the access control service provided by BSCW is an initial implementation of a more flexible access control model than found in most multi-user systems. Developing a general model for access control for collaborative systems is currently a topic of research in CSCW (see for example Shen and Dewan 1992), and attempts to provide the flexibility required greatly increase the complexity of the resulting model. Our goal here is to inform the development of a usable model for access control in CSCW systems through experience with implementations in the BSCW system. We are also looking to extend the range of tools provided by BSCW beyond shared document management. In Figure 2 for example, the object Features of BSCW2.0 is an Article object providing features for conducting threaded discussions as found in text-based conferencing systems like Internet newsgroups. In this vein we are also experimenting with interfaces to tools providing support for other forms of collaboration such as synchronous application sharing, audio and video conferencing software. 4.2 Implementation of the BSCW system The BSCW system provides a modular extension of the World Wide Web s client-server architecture without requiring modification to Web clients, servers or protocols. The core is a standard Web server extended with the BSCW software through the CGI. The system is written entirely in the interpreted programming language Python, and the only additional software required to use the system besides a Web server is the public domain Python interpreter page 13

14 Users interact with the system using the HTML user interface shown in Figure 2. Clicking on a link (or anchor) in the HTML page sends a HTTP request to the Web server which hosts the BSCW system. Request details such as the operation to perform ( add doc, rename etc.), the objects on which to perform it and other parameters are encoded in the URL sent to the server as part of the request, and these are then passed to the BSCW system through the server s CGI programming interface as described in Section At the highest level of abstraction the BSCW system itself can be decomposed into three layers which deal with request handling, operation handling and persistent object storage (Figure 4). In the request handling layer the details of the request are formatted as an internal representation called a request object, which is an abstraction over the method and protocol used to transmit the request. Thus, although the system currently supports only Web access, this approach allows consideration of other forms of access to the BSCW system such as via . request handling operation handling persistent data HTTP requests HTTP responses standard Web serv er request and response translation request object response object request and response dispatching list documents add member persistent object storage World Wide Web BSCW shared workspace system Figure 4. Architecture of the BSCW system The request object is dispatched to the operation handler which implements the requested BSCW functionality, such as listing the contents of a workspace, adding a new member and so on (Figure 4). Operation handlers interact with the persistent object store to process the request, creating, deleting and modifying objects as necessary, before generating a response object to return to the requestor. The response object is returned to the request handling layer for translation into a concrete format suitable for the access method employed, currently a HTML page which can be displayed by a standard Web browser. The request handling layer generates and returns to the Web server a HTTP response header identifying the type of the response data (HTML) followed by the HTML body, which is returned to the user s Web browser and displayed. This layered architecture therefore allows extension of the system in a number of different ways. Besides new request handlers for different methods of access, new operation handlers can be added to provide new functionality or as wrappers around an existing application. It is also straightforward to access the persistent store to store new kinds of objects without modifying the storage routines themselves. This extensibility allows new services to be integrated with BSCW in a straightforward manner, and reflects a role of the system as a platform on which additional tools can be implemented and deployed. page 14

15 4.3 Deploying the BSCW system The system described above is the second iteration of the BSCW shared workspace system. Its design is based largely on feedback following release of an earlier version to the public domain. Version 1 (Bentley et al. 1995) was intended as an exploratory prototype to investigate possibilities for extending the Web with richer support for CSCW. We made the server and helper application source code available in October 1995 and installed a public BSCW server at GMD where users could browse a guest workspace, create a login and add their own workspaces. In addition to the significant number who did so (more than 1800 registered users to June 1996), we are aware of a number of commercial companies, government organisations and academic institutions who have installed their own server, the latter often in support of lecture courses in the field of CSCW and groupware. Although we did not undertake a formal evaluation of version 1, we did receive reports from interested users via . In some cases these came from research groups who actually were evaluating groupware tools, and these provided valuable information on the strengths and weaknesses of the system. Combined with these were more mundane (but no less revealing) reports of installation difficulties, confusing or missing functionality, bugs (or assumed bugs) in the software and so on. It should be stressed that the majority of the feedback we received originated from groups who were using (or analysing) the system in supporting collaborative tasks in real work domains. Our experiences have revealed the importance of developing CSCW systems which can be deployed beyond the research laboratory. Without the feedback from users who employed the system to support real tasks we would not have discovered many of the problems with our initial design, nor revealed activities for which the system might be useful which we had not considered. One example of this (for others see Bentley and Appelt 1997) was the use of the system for collaborative management of Web sites. It is now clear that in many organisations maintenance of a Web site is a group rather than an individual responsibility. The support provided by BSCW for document management combined with the simple event service led several BSCW user groups to attempt to use the system for Web site management, storing the Web pages in a shared workspace. However, the need to specify a user name and password to access information meant that HTML documents could not be stored in a workspace and open for anonymous access simultaneously. In at least one case this led a group to develop programs to copy files from a workspace to a directory which was open for anonymous access via the Web server. We anticipate that as the richness of Web pages and the complexity of Web sites grows, integrated tools to assist with collaborative Web site management will become increasingly necessary. For version 2 of the BSCW system, described above, we have therefore provided better support for this application of the system. The access control mechanism allows objects to be declared public, so that users can request these without a registration on the server. In addition we have simplified the process of creating and editing Web pages by providing support for direct uploading from a number of WYSIWYG HTML editors, including Netscape Navigator Gold. We have recently begun to repeat the process of system deployment with version 2 of the BSCW system. In conjunction with our user groups in the CoopWWW project a more rigorous evaluation of the system is being performed to inform the next stage of development, including integration of more sophisticated features for access control, version management and more. page 15

16 5. Experiences and perspectives of the Web as enabling technology for CSCW The above description of our work with the BSCW shared workspace system is intended to illustrate some possibilities for developing and deploying CSCW applications on the Web. In this paper we are concerned primarily with the Web as a potential enabling technology for CSCW systems, rather than possibilities for enhancing the Web itself with mechanisms to make it more collaborative. We therefore focus our discussion on the role of the Web as a vehicle for developing and deploying CSCW systems, instead of a target of CSCW research in its own right, and thus orient more to the utility of current and future Web standards for CSCW systems rather than possible modifications to these standards as informed by CSCW research. This last however is clearly an area where CSCW and the Web have much to say to each other; for example, the phenomenon that the Web is currently a lonely place is an argument put forward by Lea et al. (1997) for their work on Virtual Societies, and the goal of adding group awareness mechanisms to augment the Web is receiving increasing attention from the CSCW community (see for example Greenberg and Roseman 1996, Palfreyman and Rodden 1996). The topic of awareness is only one of several issues which might be included in a research agenda for CSCW with respect to augmenting the basic Web architecture, protocols and technologies. We have taken the position that for CSCW the role of an enabling technology is twofold, easing problems of both development and deployment of CSCW systems in realworld domains, and that deployment is best achieved when systems integrate smoothly with existing Web technologies. We now discuss the possibilities and problems of developing CSCW systems on the Web, before reviewing recent developments which might address these problems and broaden the range of CSCW systems which can be supported. 5.1 Experiences of developing Web-based CSCW systems The current standards for Web components like HTML and HTTP reflect the emphasis to date on the Web as a tool for information browsing. This allows information providers to design and retain control of the form and content of their information and publish it via a Web server. Consumers can then access the information by sending requests via their Web browsers. The CGI server programming interface allows extension of the Web within this provider-consumer framework, so that servers can generate responses on-the-fly as well as serve static Web pages stored in files on the server file system. Our experiences with the BSCW system suggest that, as a tool for application development, it is straightforward to extend the Web with application functionality or interface to an existing application. The method of passing request details through the CGI programming interface is simple and allows developers to write extension programs in most programming languages, with no need to link extension code with the server. Extension programs must generate and return HTML which again is straightforward. In combination with a high-level, interpreted programming language such as Python, this arrangement allows extremely rapid prototyping and testing using a standard Web client and server. The CGI approach does however inherit all the problems of the request-response model of the Web. One of these is the feedback delay caused by the round-trip to the server to service every user interaction. When requesting documents or even HTML pages this delay may be acceptable, but for simple requests, especially those which change only the state of the interface, this delay is a problem. For example, with the BSCW system it is possible for users to fold in/out the object action and description lines using the A and D buttons shown in Figure 2, and with the adjacent checkbox buttons select all/none of the objects in a page 16