Academic Publishers, Amsterdam. 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-53754 Sankt Augustin Germany Email: [email protected] Abstract 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 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 email 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 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 • 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 Protocol1. 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 application). All browsers can be configured to do different things depending on the MIMEtype of the information received. 3.1.1 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 2 specification ) 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. 3.1.2 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 3 community” (HTML 2.0 specification ) 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 2 . http://ds.internic.net/rfc/rfc1945.txt . http://www.w3.org/pub/WWW/MarkUp/html-spec/ 3 page 5 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. 3.1.3 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” 4 (CGI 1.1 overview ) 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). 4 . http://hoohoo.ncsa.uiuc.edu/cgi/intro.html page 6 HTTP request W3 client e.g. Netscape W3 server e.g. Apache HTTP reply integration with other applications request details CGI script 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 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 system5, is a good example of this. (See Trevor et al. 1996 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 system6, 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. 5 . http://www.idi.oclc.org/ . http://www.vplaces.com/ 6 page 8 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 deployment7. 7 . 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 http://bscw.gmd.de/ page 9 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 Figure 2. HTML user interface for the BSCW shared workspace system 4.1.1 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 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 4.1.2 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 email. 4.1.3 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 ‘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. 4.1.4 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 email 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 interpreter8. 8 . http://www.python.org/ page 13 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 3.1.3. 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 email. request handling HTTP requests HTTP responses request object standard Web serv er World Wide Web request and request and response response translation response dispatching object operation handling persistent data list documents persistent object storage add member 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 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 email. 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 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 folder listing. Using these features requires a request to the server to generate a modified HTML page, and when interacting via the Internet (as do most of the users of our public server) network delays represent a much larger component of the total time to service the request than processing time. In designing a user interface for a Web-based application, developers must take care to reduce the number of required trips to the server, possibly by allowing the user to ‘batch’ requests at the client (using multiple HTML forms for example). At the server side the simplicity of the CGI approach can also be problematic. The execution of extension programs in separate processes which are passed details of the request may allow rapid development, but gives the developer no chance to modify server behaviour or request information which is not passed explicitly through the CGI. Where the default behaviour is adequate, as is the case for the user authentication features used directly by BSCW for example, there are no problems. Where features are inadequate for an application’s needs the developer cannot modify these but must either re-implement them using the CGI or build a custom HTTP server (Trevor et al. 1996). The Web is best suited as a development platform for applications which do not need to step outside the information provider-consumer model, currently enshrined in existing standards and browser and server implementations. When this is required, it is often necessary to provide additional components at the server or client (in the form of helper applications). The latter removes one of the main advantages of the Web, which is the ability to deploy systems without requiring development of client programs that run across platforms or installation of additional software by users. For BSCW, the need to upload documents to the server has required considerable effort to produce versions of the (very simple) helper which operate on PC, Macintosh and Unix machines. For this and other aspects such as synchronous notification, information replication and so on the basic Web standards and components offer no support and developers must provide their own solutions. Much of the work in the Web standards community is focusing on refinement of protocols, client and server architectures to improve the speed and reliability with which requests can be handled, and not on providing more flexible and powerful components for application development. This emphasis is not surprising; the growth of the Web has been so rapid that aspects of the HTTP protocol in particular must urgently be re-designed to ensure the Web architecture can continue to scale to millions of users world-wide. However, this growth has also led to demand from users and third-party vendors for extensions to Web components to allow richer support for different media types, user interfaces and so on. To meet this demand, server and browser vendors have proposed a number of mechanisms and built support for these in their products. There is some evidence that this practice is key in the continuing development of the Web. An example of this is the support for HTML page editing and remote publishing, identified as an area requiring support by a number of vendors including Netscape (with the Navigator Gold browser), Microsoft (with FrontPage) and GNN’s GNNPress. Although the solutions offered are currently incompatible, all have a need for uploading documents to a Web server and this has prompted efforts to agree a standard method for doing this9. Similarly, the need for richer Web pages has led to tools like Java and JavaScript being supported by the major browser vendors and becoming de-facto standards. Where relevant, these de-facto standards have also filtered into the documented standards process, as is the case with some of the proprietary extensions to HTML now part of the latest proposed standard, HTML 3.2. 9 . The World Wide Web Consortium (W3C) has recently established a working group on “Distributed Authoring and Versioning on the World Wide Web” to examine requirements and work towards specifications to support this activity. See http://www.ics.uci.edu/~ejw/authoring/ page 17 5.2 Broadening the possibilities for CSCW As Internet technologies continue to penetrate and impact upon marketing, finance, publishing, organisational IT and so on, the demand for extension and innovation will increase. The growth of the corporate Intranet, for example, raises requirements of information replication, workflow services and the like, while commerce applications require much higher levels of security and privacy than are currently supported. Although many vendors will seek to provide proprietary solutions to these requirements, and thus lock corporate customers into particular technological solutions, it is also clear that technologies are emerging which have the potential to broaden the possibilities for third-parties to customise Web components and develop new extensions in a more generic fashion. The problems of the CGI approach to extending an existing Web server are well known, and vendors of Web server technology are seeking to provide more flexible solutions for developers. For example, in designing the API for the Apache server (currently the most well-deployed Web server on the Internet), the developers sought to allow “third-party developers to easily change aspects of the server functionality which you can’t easily access from CGI” (Thau 1996, page 1113). Similar developments in browser programming interfaces such as Netscape’s ‘Plug-in’ development kit and Microsoft’s ‘ActiveX’ environment are intended to extend the capabilities of standard Web browsers to handle new media types directly, embed Web browsers in other applications and more. Such advances in client and server programming interfaces allow development of much richer CSCW systems, better integrated with desktop environments than is possible with basic Web components. In the main however these developments are specialised to particular browsers or servers or operate only on particular platforms, and do not offer the same advantages as the basic components for cross-platform deployment of CSCW systems. Although some vendors have announced support for others’ programming interfaces, it remains to be seen how this will work in practice as they (particularly browser vendors) seek to differentiate their products on the basis of the richness of features supported. An approach which is independent of particular client and server programming interfaces seems to offer more potential in this regard. One area receiving much attention is that of ‘mobile code’ where, in addition to data in HTML or other formats, a browser might download small application programs or ‘applets’ which are executed on the local machine, taking input and displaying output via the Web browser. This should remove many of the constraints on the application developer: applets can be designed which provide much richer user interfaces than are possible with HTML; computation can be moved to the client, for example to check for valid input data and thus reduce network traffic, server loading and feedback lags; applets supporting special protocols can be developed which handle different media types and so on. Although there are many problems to be overcome, most notably security concerns when code downloaded over the Internet is executed on the user’s machine, significant progress has been made in this area. Support for applets written in Sun’s Java programming language is now provided by the latest Web browsers from Netscape, Microsoft and IBM. For tasks requiring less power than a full programming language, scripting tools like Netscape’s JavaScript follow similar principles but are less ambitious, allowing HTML pages to be extended with code fragments to pass responsibility for simple computations from the server to the client. We see these developments as broadening the role of the Web as an enabling technology for CSCW, increasing the range of CSCW systems which can be developed while not compromising the benefits of cross-platform system deployment. In the BSCW project we are making use of both Java and JavaScript to overcome problems with the basic Web page 18 components and provide richer collaboration services to users of the BSCW system. With JavaScript we have augmented the HTML user interface of the BSCW system to remove the need to send requests to the server for changes in user interface state, including the folding of actions and descriptions and the select all/none behaviour discussed above. With Java we are being more ambitious, designing applets which provide synchronous collaboration services such as event notification, presence awareness, simple text chat and more, which can be presented in standard Web browsers alongside the existing BSCW HTML user interface. An early prototype of this work is discussed in (Bentley et al. 1995). 6. Conclusions In this paper we have discussed the role of the World Wide Web as an ‘enabling technology’ for CSCW, arguing that such a technology should assist with both the development and deployment of CSCW systems beyond the laboratory. Despite the current limitations of the Web as a platform for development, the advantages of an accepted technology integrated with different hardware and software environments suggests that the Web is worthy of attention from the CSCW community. Using examples from our own work with the BSCW shared workspace system, we have tried to illustrate the kinds of systems which can be implemented and directly deployed on the basic Web architecture, and some of the benefits when this approach is followed. In general we see the continuing development of Web technologies, and in particular those which provide greater flexibility to system developers while supporting open standards and cross-platform, client and server implementation, as transforming the Web from a platform for information browsing to a more sophisticated environment for system development and deployment. We believe it is important that the CSCW community takes the opportunities offered by the Web, and in doing so helps transform the Web from a largely passive information repository to an active tool for cooperation. Acknowledgments We wish to thank our colleagues in the BSCW project whose work is reported in this paper: Wolfgang Appelt, Uwe Busbach, Elke Hinrichs, David Kerr, Klaas Sikkel and Gerd Woetzel. Parts of this work were funded by the Telematics Applications Programme of the European Union under contract TE 2003 (CoopWWW). References Bäcker, A. and Busbach, U. (1996), DocMan: A document management system for cooperation support, in Proceedings of 29th Hawaii International Conference on System Sciences, volume III, Maui, Hawaii, 3-6 January 1996, IEEE Computer Society Press, pp 8291. Bannon, L. (1996), Use, design and evaluation: Steps towards an integration, in The Design of Computer Supported Cooperative Work and Groupware Systems, D. Shapiro, M. Tauber and R. Traunmüller (Eds), North-Holland, pp 423-444. Bentley, R., Horstmann, T., Sikkel, K. and Trevor, J. (1995), Supporting collaborative information sharing with the World Wide Web: The BSCW Shared Workspace system, in The World Wide Web Journal: Proceedings of the 4th International World Wide Web Conference, Boston, MA, 12-14 December 1995, O’Reilley & Associates, pp 63-74. page 19 Bentley, R. and Appelt, W. (1997), Designing a system for cooperative work on the World Wide Web: Experiences with the BSCW system, in Proceedings of 30th Hawaii International Conference on System Sciences, Maui, Hawaii, 7-10 January 1997, IEEE Computer Society Press, in press. Bentley, R., Appelt, W., Busbach, U., Hinrichs, E., Kerr, D., Sikkel, K., Trevor, J. and Woetzel, G. (1997), Basic support for cooperative work on the World Wide Web, in International Journal of Human-Computer Studies: Special issue on Innovative Applications of the World Wide Web, Academic Press, in press. Berners-Lee, T., Cailliau, R., Luotonen, A., Frystyck Nielsen, H., and Secret, A. (1994), The World Wide Web, in Communications of the ACM, 37(8), August 1994, pp 76-82. Dewan, P. and Choudhary, R. (1992), A high-level and flexible framework for implementing multi-user user interfaces, in ACM TOIS, 10 (4), 1992, pp 345-380. Fitzpatrick, G., Tolone, W. and Kaplan, S. (1995), Work, Locales and distributed social worlds, in Proceedings of ECSCW’95, Stockholm, 10-14 September 1995, Kluwer, pp 1-16. Dix, A. (1997), Challenges for cooperative work on the Web: An analytical approach, in International Journal of CSCW: Special issue on CSCW and the Web, Kluwer, this issue. Gorton, I., Hawryszkiewycz, I. and Fung, L. (1996), Enabling software shift work with groupware: A case study, in Proceedings of 29th Hawaii International Conference on System Sciences, volume III, Maui, Hawaii, 3-6 January 1996, IEEE Computer Society Press, pp 7281. Grasso, A., Meunier, J., Pagani, D. and Pareschi, R. (1997), Distributed coordination and workflow on the World Wide Web, in International Journal of CSCW: Special issue on CSCW and the Web, Kluwer, this issue. Greenberg, S. and Roseman, M. (1996), GroupWeb: A WWW browser as real time groupware, in Companion Proceedings of CHI’96, ACM Press, pp 271-272. Lea, R., Honda, Y. and Matsuda, K. (1997), Virtual Society: Collaboration in 3D spaces on the Internet, in International Journal of CSCW: Special issue on CSCW and the Web, Kluwer, this issue. Palfreyman, K. and Rodden, T. (1996), A protocol for user awareness on the World Wide Web, in Proceedings of CSCW’96, Boston, MA, 16-20 November 1996, ACM Press, pp 130139. Patterson, J. (1991), Comparing the programming demands of single- and multi-user applications, in Proceedings of UIST’91, Hilton Head, SC, 11-13 November 1991, ACM Press, pp 87-95. Rao, V. (1995), The implementation of satellite offices: Initial recommendations based on observations from one site, in Proceedings of 28th Hawaii International Conference on System Sciences, volume IV, Maui, Hawaii, 3-6 January 1995, IEEE Computer Society Press, pp 426-436. Rodden, T., Blair, G. and Mariani, J. (1992), Supporting cooperative applications, in International Journal of CSCW, 1(1), 1992, Kluwer, pp 41-67. page 20 Roseman, M. and Greenberg, S. (1995), Building real-time groupware with GroupKit, a groupware toolkit, in ACM Transactions on CHI, 3(1), ACM Press, pp 66-106. Shen, H. and Dewan, P. (1992), Access control for collaborative environments, in Proceedings of CSCW’92, Toronto, 31 October-4 November 1992, ACM Press, pp 51-58. Thau, R. (1996), Design considerations for the Apache server API, in Computer Networks and ISDN Systems 28: Proceedings of 5th International World Wide Web conference, Paris, 6-11 May 1996, pp 1113-1122. Trevor, J., Bentley, R. and Wildgruber, G. (1996), Exorcising daemons: A modular and lightweight approach to deploying applications on the Web, in Computer Networks and ISDN Systems 28: Proceedings of 5th International World Wide Web conference, Paris, 6-11 May 1996, pp 1053-1062. Twidale, M., Randall, D. and Bentley, R. (1994), Situated evaluation for cooperative systems, in Proceedings of CSCW’94, Chapel Hill, NC, 22-26 October 1994, ACM Press, pp 441-452. Vitali, F. and Durand, D. (1995), Using versioning to provide collaboration on the WWW, in The World Wide Web Journal: Proceedings of the 4th International World Wide Web Conference, Boston, MA, 12-14 December 1995, O’Reilley & Associates, pp 63-74. page 21
© Copyright 2024 Paperzz