The World Wide Web as Enabling Technology for CSCW: The Case of BSCW

Computer Supported Cooperative Work: The Journal of Collaborative Computing 6: 111–134, 1997. 111c 1997 Kluwer Academic Publishers. Printed in the Netherlands.

The World Wide Web as Enabling Technology forCSCW: The Case of BSCW

RICHARD BENTLEY, THILO HORSTMANN and JONATHAN TREVORCSCW Group, Institute for Applied Information Technology (GMD FIT), German NationalResearch Centre for Computer Science, Schloß Birlinghoven, D-53754 Sankt Augustin, GermanyE-mail: [email protected]

(Received 31 July 1996; in final form 29 November 1996)

Abstract. Despite the growth of interest in the field of CSCW, and the increasingly large numberof systems which have been developed, it is still the case that few systems have been adopted forwidespread use. This is particularly true for widely-dispersed, cross-organisational working groupswhere problems of heterogeneity in computing hardware and software environments inhibit thedeployment of CSCW technologies. With a lightweight and extensible client-server architecture,client implementations for all popular computing platforms, and an existing user base numbered inmillions, the World Wide Web offers great potential in solving some of these problems to providean ‘enabling technology’ for CSCW applications. We illustrate this potential using our work withthe BSCW shared workspace system – an extension to the Web architecture which provides basicfacilities for collaborative information sharing from unmodified Web browsers. We conclude thatdespite limitations in the range of applications which can be directly supported, building on thestrengths of the Web can give significant benefits in easing the development and deployment ofCSCW applications.

Key words: 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 enormouslyand an ever-increasing number of systems have been developed with the goal ofsupporting collaborative work. These efforts have led to a greater understanding ofthe complexity of group work and the implications of this complexity, in terms ofthe flexibility required of supporting computer systems, have driven much of therecent work in the field. Despite these advances, however, it is still the case thatfew 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-of-the-artin providing computer support for collaborative work.

In this paper we examine the World Wide Web (Berners-Lee et al., 1994) as atechnology for enabling development of more effective CSCW systems. The Webprovides a simple client-server architecture with client programs (browsers) imple-mented for all popular computing platforms and a central server component thatcan be extended through a standard API. The Web has been extremely successful

[1]

112 R. BENTLEY ET AL.

in providing a simple method for users to search, browse and retrieve informationas well as publish information of their own, but does not currently offer features formore collaborative forms of information sharing such as joint document production.

There are a number of reasons to suggest the Web might be a suitable focusfor developers of CSCW systems. For widely-dispersed working groups, wheremembers may be in different organisations and different countries, issues of inte-gration and interoperability often make it difficult to deploy existing groupwareapplications. Although non computer-based solutions such as telephone and videoconferencing technologies provide some support for collaboration, empirical evi-dence suggests that computer systems providing access to shared information, atany time and place and using minimal technical infrastructure, are the main require-ment 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 userenvironments, the Web may provide a means of introducing CSCW systems whichoffer much richer support for collaboration than email and FTP, and thus serve asan ‘enabling technology’ for CSCW.

In the following section we discuss the need for such enabling technologies forCSCW to address problems of system development and deployment. We then givean overview of the Web architecture and components and critically examine thesein the context of CSCW systems development. We suggest that the Web is limitedin 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 applicationswith no strong requirements for notification, disconnected working and rich userinterfaces. We illustrate this with examples from our work with the BSCW sharedworkspace system – an integrated set of cooperation tools offering basic facilitiesfor information sharing from unmodified Web browsers. We reveal benefits ofthe Web as a platform for deploying such applications in real work domains, andconclude with a discussion of some current developments which may ease thelimitations of the Web as a platform for system development and increase its utilityas an enabling technology for CSCW.

2. Moving out of the laboratory: The need for enabling technologies forCSCW

Most of the CSCW systems which have been developed to date have been con-structed in laboratories as research prototypes. This is perhaps not surprising, asCSCW systems place novel requirements on underlying technology such as dis-tributed systems and databases (Rodden et al., 1992), and many of the mechanismsdeveloped to support multi-user interaction do not address issues of cooperationsuch as activity awareness and coordination. This has focused much attention onthe development of mechanisms to support floor management, user interface ‘cou-pling’, update propagation and so on, and has resulted in a range of experimental

[2]

THE WORLD WIDE WEB AS ENABLING TECHNOLOGY FOR CSCW 113

systems tailored to the particular issues being investigated. The proprietary andincompatible architectures on which many are based, the esoteric hardware andsoftware required and the lack of integration with existing application programsand data formats inhibits deployment outside the laboratory and within the intendedapplication domain.

It might be argued that this situation is not unduly problematic; issues of sys-tem deployment are ‘implementation concerns’ and would be addressed by re-implementation of system prototypes. The lack of system deployment does, how-ever, pose a serious question to CSCW: if systems built to investigate particularmodels or mechanisms are never deployed and evaluated in use, how can we deter-mine the effectiveness of these models and mechanisms in supporting cooperativework? A central concern of CSCW is the need for systems which are sensitive totheir contexts of use, and a body of empirical data exists to show the problemscaused when systems are introduced which do not resonate with existing workpractice. When systems do not leave the research laboratory it is difficult to seehow the models and mechanisms they propose can be assessed other than from atechnical 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 (Twidaleet al., 1994) reflect this need to migrate CSCW systems out of the laboratory andinto the field if we are to eventually provide more effective systems. This migrationis far from trivial, as the diversity of machines, operating systems and applicationsoftware which characterises the real work domain is often far removed from thehomogeneity of the laboratory. This is particularly true for working groups whichcross departmental or organisational boundaries, where issues of integration andinteroperability mean it is extremely unlikely that systems developed as researchprototypes can be directly deployed. Adaptation or re-implementation of systemprototypes for deployment outside the laboratory is usually beyond the resourcesof most research projects, suggesting that the issue of system deployment and theattendant 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, applicationsand data formats already in place in the work domain adds considerably to what isalready a complex design task. A number of researchers have pointed to the needfor 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 andallow a more evolutionary approach – an approach otherwise prohibited by theinvestment necessary to create system prototypes and the need to commit to policydecisions at an early stage in a system’s design. Work in CSCW is already address-ing these issues through development of toolkits or application frameworks withcomponents which can be instantiated and combined to create groupware systems.

[3]


Toolkits such as GroupKit (Roseman and Greenberg, 1995) are by now relativelymature, and seem to reduce the complexity of CSCW system development in muchthe same way that user interface toolkits allow rapid development of single-userinterfaces.

As we have shown, the desire for enabling technologies for CSCW lies notonly in easing problems of prototype construction but also facilitating deploymentand thereby evaluation of system prototypes in real work domains. As yet, mostCSCW toolkits focus primarily on system development and issues of cross-platformdeployment, integration with existing applications and so on are secondary. In thisregard more than any other the World Wide Web seems to offer potential as anenabling technology for CSCW:� Web client programs (browsers) are available for all popular computing plat-

forms and operating systems, providing access to information in a platformindependent manner;

� browsers offer a simple user interface and consistent information presentationacross these platforms, and are themselves extensible through association ofexternal ‘helper applications’;

� browsers are already part of the computing environment in an increasingnumber of organisations, requiring no additional installation or maintenanceof software for users to cooperate using the Web;

� many organisations have also installed their own Web servers as part of anInternet presence or a corporate intranet and have familiarity with servermaintenance and, in many cases, server extension through programming theserver API.

As a basis for deployment of CSCW applications in real work domains, the level ofacceptance and penetration of Web technology in commercial and academic envi-ronments is grounds alone for suggesting that CSCW should pay serious attentionto the World Wide Web.

3. The Web as enabling technology for CSCW

[The Web] was developed to be a pool of human knowledge, which wouldallow collaborators in remote sites to share their ideas and all aspects of acommon project. (Berners-Lee et al., 1994, p. 76)

From its inception the Web was intended as a tool to support a richer, more activeform of information sharing than is currently the case. Early implementations atCERN allowed the browsing of pages as is common today, but also supportedannotation of these pages and addition of links between arbitrary pages, not justfrom pages on local servers the user can access and edit. Some of these conceptswere carried through to early drafts of the standards for Web protocols and archi-tecture which described features such as remote publishing of hypertext pages andcheck in/out support for locking documents to ensure consistency in a multi-authorenvironment. To date these aspects have largely been side-lined while development

[4]


of Web browsers, servers and protocols has focused on more ‘passive’ aspects ofinformation browsing. In this section we examine the Web as it currently existsas a platform for developing and deploying CSCW technologies, following a briefoverview 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 torequest information from servers using a standard protocol called HTTP – theHyperText Transfer Protocol.? Web browsers use a standard naming scheme (theURL, or Uniform Resource Locator) to identify the particular information requiredand send a HTTP Request for this information to the Web server running on themachine on which this information is located. Access to information may be limitedto specific users or machines and, if the browser does not send this information aspart of the HTTP request, the server may have to request a valid user name andpassword before returning the information.

Information may be stored on the server host machine in any format, andthe server must tell the client what format the requested information is so it canhandle it correctly. The server returns a HTTP Response consisting of a headerwhich identifies the type of data (its ‘MIME-type’) and a body which contains therequested information. Depending on the capabilities of the browser the informationin the response body can be displayed directly (as with a GIF image for example) orits processing can be delegated to an external ‘helper’ application (a Microsoft Worddocument might be displayed by launching the Word application). All browsers canbe configured to do different things depending on the MIME-type of the informationreceived.

3.1.1. The HyperText Transfer Protocol (HTTP)

[HTTP] is an application-level protocol with the lightness and speed necessaryfor distributed, collaborative, hypermedia information systems. It is a generic,stateless, object-oriented protocol which can be used for many tasks, such asname servers and distributed object management systems, through extensionof its request methods (commands). A feature of HTTP is the typing of datarepresentation, allowing systems to be built independently of the data beingtransferred. (HTTP 1.0 specification??)

HTTP was designed as a very simple request-response protocol. The commandsof HTTP are the ‘request methods’ used by browsers to ask for particular services

? In fact, it is hard to pin down exactly what the ‘World Wide Web’ encompasses; for examplemodern 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 focusonly on those components introduced by the Web which we consider to be the ‘core’ – HTTP, HTMLand CGI.?? http://ds.internic.net/rfc/rfc1945.txt

[5]


from a Web server. The most common are the GET method, used to requestan information ‘entity’ (a HTML page, document, sound clip, etc.), the POSTmethod for transmitting HTML form data to a server, and the HEAD methodwhich is similar to GET but asks the server only for the HTTP header for aninformation entity, not the information itself. This last is used by programs likeWeb indexers (‘robots’, etc.) to check if information known to be held on the serverhas been modified recently. Other methods like PUT (for sending documents toa Web server), DELETE and more are currently vaguely specified and a standardimplementation is not provided by the majority of browsers and servers.

HTTP is a ‘stateless’ protocol; servers can process requests from Web browsersindependently of any previous request. This allows development of lightweightserver components and is ideal for simple document retrieval or browsing. Anystate information must be preserved by the client and passed to the server as partof the HTTP Request. So, for example, if access to information requires user‘authentication’ with a user name and password, the Web browser must pass thename and password with every request to the server; the Web architecture andHTTP protocol provide no concept of a ‘session’.

A strength of the HTTP protocol is its independence from the format of thetransmitted data. This allows extension of clients and servers to handle new dataformats; servers can be configured to recognise new data formats and return thecorrect MIME-type, while browsers can be configured to handle new types ofdata by registering new ‘helper’ applications. All browsers can, however, directlyinterpret 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 tocreate hypertext documents that are portable from one platform to another.HTML documents are SGML documents with generic semantics that areappropriate for representing information from a wide range of domains : : : anumber of new features of HTML are being proposed and experimented in theInternet community. (HTML 2.0 specification?)

HTML is a simple document markup language which can transform a plain textdocument into a hypertext ‘node’. Using simple mark-up tags authors can indicatesections of the document are links to other information entities, and specify theURL for the entity the client should request if the user clicks on that section. Inthis way a number of HTML pages possibly held on different servers can be linkedtogether to form a single hypertext.

Mark-up tags are also used to specify the structure of a Web document. Orig-inally these tags (like ‘<H1>’ for a first-level heading) were intended to specifystructure only and not how a document should be displayed. This is a power-ful approach, as HTML documents can be parsed and appropriately presented by

? http://www.w3.org/pub/WWW/MarkUp/html-spec/

[6]


browsers running on very different hardware, including character-based terminals,small PDAs, Braille terminals for the blind as well as the more usual desktopmachines. Recent extensions have, however, added a number of presentation mark-up tags to HTML, some of which are now being standardised in the most recentspecification (HTML 3.2).

A big advantage of HTML is its simplicity, both for Web page authors andfor browsers which can interpret HTML documents using a very simple parsingalgorithm. Most browsers simply ignore HTML tags they do not understand, allow-ing experimentation with new tags without defeating old browsers. Although it issometimes argued that HTML would benefit from extension with more ‘content-oriented’ tags like ‘abstract’ and ‘keywords’ (as are provided by other formattinglanguages 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 externalapplications with information servers, such as HTTP or Web servers. A plainHTML document that the Web daemon [server] retrieves is static, which meansit 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 dynamicinformation. (CGI 1.1 overview?)

The helper application mechanism described above is a means of extending Webbrowsers to handle different types of data. At the server side, most Web serversprovide one or more Application Programming Interfaces (APIs) for extendingthe server with new functionality. The de-facto standard is the Common GatewayInterface (CGI), currently supported by all major Web servers.

To extend a Web server though the CGI requires configuring the server totreat some HTTP requests as calls to developer-supplied programs or scripts, andto invoke these programs rather than handle the request itself. CGI specifies therequest information (the URL requested, HTML form field values and so on) whichis passed to the script. The script is expected to provide a reply to return to theclient (often a HTML page), allowing development of Web pages with dynamiccontent, such as a page showing the output of the Unix finger command. The CGIscript may be a very simple routine or an interface to a complex application like adatabase (Figure 1).

There are a number of factors which have led to CGI becoming the standardserver 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,

? http://hoohoo.ncsa.uiuc.edu/cgi/intro.html

[7]


Figure 1. Extending a Web server via the Common Gateway Interface.

� language independence: CGI scripts can be written in most programminglanguages,

� architectural independence: CGI does not require a particular server architec-ture,

� process isolation: CGI scripts generally run as separate processes, so thatbuggy scripts cannot crash the Web server (or access its private internal state).

3.2. DEVELOPING WEB-BASED CSCW APPLICATIONS

Despite the lack of direct support for collaboration, the current Web architecturedoes hide some of the complexity of deploying applications in a distributed, het-erogeneous environment. The most common method of doing this is by extending aWeb server through the CGI with new application functionality or ‘glue’ code to anexisting application, presenting the application user interface as a series of HTMLpages which can be displayed by standard Web browsers. With this approach devel-opers can take advantage of the existing base of browsers as client programs fortheir applications but must accept the constraints of the basic Web architecture andprotocols as currently implemented and the limitations of existing Web browsers.These constraints are severe, inhibiting the development and deployment of CSCWapplications 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 theserver needs to play an active role (e.g., to notify users of changes to infor-mation or maintain information consistency over several servers). One conse-quence is that applications are now in common use which poll Web serversperiodically to check if pages have been updated, allowing users to monitorWeb sites of interest (e.g., Netscape’s SmartMarks). Users can specify a verysmall time interval between checks, even for pages which change rarely, lead-ing to huge amounts of unnecessary traffic on the Internet and ‘hits’ on Webservers.

� Pure centralised architecture: The architecture provides no support for distrib-ution of information or computation between clients and servers or replicationacross servers. Expensive, powerful and fault-tolerant machines are requiredto run a Web server if it is to scale to a large number of users. Even simple

[8]


computations are not performed by the client, for example to check if a userhas 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 forreplication means that disconnected working is not possible.

� No guaranteed ‘Quality of Service’: The HTTP protocol does not supportthe specification of guaranteed transmission rates between servers and clients.Data transfer is often ‘bursty’, subject to network and server loading whichmight vary considerably during a single transmission. This is unsuitable fortransmission of (real-time) continuous media like audio and video, and alter-native protocols such as RTP, ‘the Real-Time Protocol’, have been proposedfor these media types.

� User interface design: HTML is not a user interface design toolkit, andalthough mark-up tags are provided for simple form-filling widgets like inputfields these do not support features now common in desktop user interfacessuch as drag and drop, multiple selection and semantic feedback. Althoughsome browser vendors have introduced new tags to provide features like mul-tiple, independent screen areas (Netscape Frames) they do little to broaden thepossibilities for user interface design (and are not supported by all browsers). Afundamental problem here is the lack of server-client notification (see above);it is easy for the interface to become inconsistent with the information on thecentral server and is only updated when the user reloads the entire page.

Some of these limitations are not so much problems with Web components likeHTTP and HTML but more with the current implementations of browsers andservers. For example there is no reason why a server could not act as a clientand vice versa to allow a form of update propagation and notification. (In factsome 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, restrictthe kinds of CSCW systems which can be developed as extensions of the Webusing the CGI, and suggest that the Web in its current form is largely unsuitable fordeveloping systems which require highly-interactive user interfaces, rapid feedbackand ‘feedthrough’ (user interface updates in response to others’ interactions) or ahigh degree of synchronous notification.

Of course, extending a Web server through the CGI programming interface isnot the only method of deploying a CSCW system on the Web, and more radicalapproaches can remove some of the constraints of the basic architecture. Based onthe extent to which a developer must modify the basic Web components, we canidentify the following approaches:

1. Extending through CGI: As described above, where no modifications arerequired to protocols, browsers or servers. Any additional client function-ality is provided through ‘helper’ applications. The BSCW system describedin the next section is an example of such a system.

2. Customising/building a server: Building a special-purpose Web server maybe necessary to achieve adequate performance or security, or to introduce

[9]


new functionality such as server-initiated notification. This approach requiresdeployment of the server software and any other application code, but is some-times a better method of enabling access to existing applications from the Webin a more flexible and secure manner than CGI. The BASIS WEBserver, whichenables Web access to the BASISplus document management system,? is agood example of this. (See Trevor et al., 1996 for a more detailed considerationof CGI versus specialised server approaches to deploying applications on theWeb.)

3. Customising/building a client: Building a special-purpose client allows appli-cations other than Web browsers to communicate with Web servers usingHTTP, such as the ‘coordinator’ clients developed for the WebFlow distrib-uted workflow system (Grasso et al., 1997). Customising a client may alsobe necessary to interpret non-standard HTML tags such as those proposedby Vitali and Durand (1995) for version control to support collaborative edit-ing of HTML documents. Custom clients can be used in conjunction withcustom servers to provide additional services; as part of their Virtual Placessystem,z the Ubique client can interact with the Virtual Places server to providesynchronous 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 deploymenton the Web. These applications use other means of providing the user interface,managing data and event distribution and so on, and only limited interactionis possible using a Web browser and HTTP.

Using this classification the flexibility for the developer increases from 1 to 4, andmany of the problems identified above can be solved by specialising or replacingcomponents such as clients and servers to provide richer mechanisms for the userinterface, update propagation and so on. Of course, this level of flexibility is boughtat the price of the innovation required from developers to build or integrate thesecomponents, and it should be obvious that very soon we may find ourselves backto square one; with a system which cannot be deployed outside the laboratory dueto particular hardware and software requirements and a lack of integration withexisting user environments. In this case, if our goal is eventual deployment andevaluation in real work domains, there seems little point in using the Web as aplatform 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 ismore suited to asynchronous, centralised applications with no strong requirementsfor synchronous notification, disconnected working and rich user interfaces. Theadvantages, however – an accepted technology, integrated with existing user envi-ronments and extensible through the server API without requiring additional clientsoftware on users’ machines – indicate that here we have a method of deploying

? http://www.idi.oclc.org/z http://www.vplaces.com/

[10]


and evaluating basic mechanisms to support collaboration in real work domains.Further, the rapid pace of development in Web technologies suggests that manyproprietary and experimental features which address some of the current limitationscould become standards in the future. Of course much depends on the willingnessof the main browser vendors (currently Netscape and Microsoft) to agree on andimplement these features, but this does not seem to have been a problem to date. AsWeb technology matures some of the current problems with CSCW developmenton the Web should be solved.

To illustrate the potential of the Web for enabling development and deploymentof CSCW systems we now describe our work with the ‘BSCW shared workspacesystem’. Our intention here is to show the possibilities for developing CSCWsystems without modifying Web components and thus reducing the utility of theWeb as a platform for system deployment. In the final section of the paper weshow how recent developments have the potential to broaden the range of CSCWsystems 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 concernedwith the integration of collaboration services with existing environments, sup-porting widely-dispersed working groups with different computing, network andsoftware infrastructures. The BSCW shared workspace system is the basis forthese services, which include features for uploading documents, version manage-ment, group administration and more, all accessible from different platforms usingunmodified Web browsers. The system is an extension of a standard Web serverusing the CGI programming interface. The intention is to extend the basic Webarchitecture with mechanisms to support cooperation and information sharing andprovide a stable platform on which more powerful tools can be implemented,deployed and evaluated. We give a brief overview of the system functionality (fora more comprehensive description see Bentley et al., 1997), the system’s imple-mentation as a CGI extension of a Web server, and some initial results from systemdeployment.?

4.1. SHARING INFORMATION WITH THE BSCW SYSTEM

The BSCW system is based on the notion of a ‘shared workspace’ which themembers of a group establish for organising and coordinating their work. A sharedworkspace as realised by BSCW is a repository for shared information, accessibleto group members using a simple user name and password scheme. Each ‘BSCWserver’ (a Web server extended with the BSCW system through the CGI) managesa number of such workspaces for different groups and users may be members of

? All BSCW software described in this paper is freely available for downloading; to obtain thesoftware, use our public server, or for more information on the BSCW project see http://bscw.gmd.de/

[11]


Figure 2. HTML user interface for the BSCW shared workspace system.

several workspaces (e.g., one workspace corresponding to each project a user isinvolved with).

A shared workspace can contain information such as documents, images, linksto other Web pages or FTP sites, threaded discussions, member contact informa-tion and more. The contents of a workspace are represented as information objectsarranged in a folder hierarchy (Figure 2). Members can transfer (upload) infor-mation from their machines to a workspace and set access rights to control thevisibility of this information and the operations which can be performed by oth-ers. In addition, members can download, modify and request more details on theinformation objects by clicking on HTML links to request workspace operations

[12]


from the BSCW server. After each operation the server returns a new HTML pageshowing the new state of the workspace.

Figure 2 shows a sample workspace view. The workspace contains a numberof different kinds of documents, a URL link to another Web page (‘BSCW projectpage’), an ‘article’ object representing an item for discussion (‘Features of 2.0’), asub folder containing further workspace information and a document under versioncontrol (‘Publications’). The last ‘significant’ operation performed on each objectis described, and a list of clickable ‘event icons’ give information on other recentchanges. The operations which can be performed are given below each object anda 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 pageas well as the HTML links below each object. The former operate on the currentfolder being shown (so that ‘add URL’ would return a HTML form to specifythe name and URL of a URL link object to add to the current folder) while thelatter 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 withthe buttons above or below the list of objects allow operations on multiple objectselections.

Clicking on an object name will perform different operations depending on thetype of the object; clicking on a document will download it, possibly for displayby the browser, display by an external ‘helper’ application (as with a MicrosoftWord document) or saving to disk, while clicking on a folder ‘opens’ the folder andreplaces the current view with a display of the folder contents. This last methodof navigating ‘down’ through a folder hierarchy is supplemented by a navigationbar at the top of the page presenting the current location and path; clicking on thefirst element of the path (‘:bentley’ in Figure 2) returns to the current user’s ‘homefolder’, which lists all the workspaces of which the user is a member, and thereforehas access to.

4.1.1. Storing documents in a shared workspace

The HTTP protocol and basic Web components provide no standardised supportfor sending documents to a Web server for remote publishing. Currently onlythe more recent versions of the Netscape browser support any form of documentuploading, and this requires extension of a Web server to receive and store uploadeddocuments. The BSCW system includes this extension allowing Netscape users toupload documents to a BSCW server to store in a workspace folder by specifyingthe 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, ver-sions of which exist for PC, Macintosh and Unix platforms, provide a richer func-tionality than the Netscape built-in method including multiple document upload

[13]


Figure 3. Uploading the documents with the helper application.

and progress reporting (Figure 3), but use the same protocol for formatting andtransmitting documents to the BSCW server. Netscape users can indicate whetherto use the built-in or helper upload methods by setting a flag in their personalpreferences, and clicking on the ‘add doc’ button (Figure 2) returns a HTML formor launches the helper application as appropriate.

4.1.2. The event service

The event service provided by the BSCW system provides users with informationon the activities of others with respect to objects in a workspace. Events aretriggered when a user performs an action such as uploading a document, renaminga document and so on. The system presents the recent events to each user as eventicons in the workspace listing (Figure 2). ‘Recent’ in this context means eventswhich have occurred for an object since the user last ‘caught up’; an operation bywhich users can indicate they are aware of events that have occurred so far and nolonger wish to see them in the workspace (like catching up articles in an Internetnewsgroup). Events can be caught up at different levels, from individual objects tocomplete workspace folder hierarchies.

The system distinguishes several types of events in the workspace listing suchas ‘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 occurredsince the last catch-up. This service therefore provides a very simple form of event

[14]


information regarding changes within the workspace; we are currently extendingthis 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 validlogin consisting of a registered user name and password. Using the standard accesscontrol mechanisms supported by Web servers, the server can be configured torequest user ‘authentication’ information and validate the user name and passwordbefore handling a request. The BSCW system uses this method of ‘basic authenti-cation’ to provide a degree of security and to establish user identity for recordingevent information and access control.

New members can be added to a workspace through an ‘invitation’ from anexisting member. Invited users must register with the server and specify a username and password if they do not already hold a valid login, which is possible ifthe invited user is already a member of a different workspace on the server. It isalso possible to configure the system to allow self-registration, whereby users canspecify a user name and password to create a registration without first being invitedby an existing member.

4.1.4. Additional services

The system provides standard features for simple document management such ascreating folders, renaming, moving and so on. To date much of our attention hasfocused on these simple features with the goal of providing a more comfortableenvironment for cross-platform document sharing for groups than is possible withemail or FTP. An important role for the BSCW system, however, is to provide a sta-ble 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. TheBSCW system includes an experimental version management feature to preservea document version history. This service uses a form of ‘soft-lock’ (Backer andBusbach, 1996) to provide awareness of the current status of a document, suchas who is editing it, without enforcing a stricter model of locking. Based on ourexperience we feel this model may be more appropriate in many situations forcollaborative 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 imple-mentation of a more flexible access control model than found in most multi-usersystems. Developing a general model for access control for collaborative systemsis 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 ofthe resulting model. Our goal here is to inform the development of a usable model

[15]


Figure 4. Architecture of the BSCW system.

for access control in CSCW systems through experience with implementations inthe BSCW system.

We are also looking to extend the range of tools provided by BSCW beyondshared document management. In Figure 2 for example, the object ‘Features ofBSCW2.0’ is an ‘Article’ object providing features for conducting threaded dis-cussions as found in text-based conferencing systems like Internet newsgroups. Inthis vein we are also experimenting with interfaces to tools providing support forother forms of collaboration such as synchronous application sharing, audio andvideo 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 proto-cols. The core is a standard Web server extended with the BSCW software throughthe CGI. The system is written entirely in the interpreted programming languagePython, and the only additional software required to use the system besides a Webserver is the public domain Python interpreter.?

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 theWeb server which hosts the BSCW system. Request details such as the operationto perform (‘add doc’, ‘rename’, etc.), the objects on which to perform it and otherparameters are encoded in the URL sent to the server as part of the request, andthese are then passed to the BSCW system through the server’s CGI programminginterface as described in Section 3.1.3.

At the highest level of abstraction the BSCW system itself can be decomposedinto three layers which deal with request handling, operation handling and per-sistent object storage (Figure 4). In the request handling layer the details of the

? http://www.python.org/

[16]


request are formatted as an internal representation called a request object, whichis an abstraction over the method and protocol used to transmit the request. Thus,although the system currently supports only Web access, this approach allowsconsideration of other forms of access to the BSCW system such as via email.

The request object is dispatched to the operation handler which implementsthe requested BSCW functionality, such as listing the contents of a workspace,adding a new member and so on (Figure 4). Operation handlers interact with thepersistent object store to process the request, creating, deleting and modifyingobjects 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 aconcrete format suitable for the access method employed, currently a HTML pagewhich can be displayed by a standard Web browser. The request handling layergenerates and returns to the Web server a HTTP response header identifying thetype of the response data (HTML) followed by the HTML body, which is returnedto the user’s Web browser and displayed.

This layered architecture therefore allows extension of the system in a numberof 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 persistentstore to store new kinds of objects without modifying the storage routines them-selves. This extensibility allows new services to be integrated with BSCW in astraightforward manner, and reflects a role of the system as a platform on whichadditional tools can be implemented and deployed.

4.3. DEPLOYING THE BSCW SYSTEM

The system described above is the second iteration of the BSCW shared workspacesystem. Its design is based largely on feedback following release of an earlierversion to the public domain. Version 1 (Bentley et al., 1995) was intended asan exploratory prototype to investigate possibilities for extending the Web withricher support for CSCW. We made the server and helper application source codeavailable in October 1995 and installed a public BSCW server at GMD where userscould 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 usersto June 1996), we are aware of a number of commercial companies, governmentorganisations and academic institutions who have installed their own server, thelatter 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 receivereports from interested users via email. In some cases these came from researchgroups who actually were evaluating groupware tools, and these provided valuableinformation on the strengths and weaknesses of the system. Combined with thesewere more mundane (but no less revealing) reports of installation difficulties,confusing or missing functionality, bugs (or assumed bugs) in the software and so

[17]


on. It should be stressed that the majority of the feedback we received originatedfrom groups who were using (or analysing) the system in supporting collaborativetasks in real work domains.

Our experiences have revealed the importance of developing CSCW systemswhich can be deployed beyond the research laboratory. Without the feedback fromusers who employed the system to support real tasks we would not have discoveredmany of the problems with our initial design, nor revealed activities for which thesystem might be useful which we had not considered. One example of this (forothers see Bentley and Appelt, 1997) was the use of the system for collaborativemanagement of Web sites.

It is now clear that in many organisations maintenance of a Web site is agroup rather than an individual responsibility. The support provided by BSCW fordocument management combined with the simple event service led several BSCWuser groups to attempt to use the system for Web site management, storing theWeb pages in a shared workspace. However, the need to specify a user name andpassword to access information meant that HTML documents could not be storedin a workspace and open for ‘anonymous’ access simultaneously. In at least onecase this led a group to develop programs to copy files from a workspace to adirectory which was open for anonymous access via the Web server.

We anticipate that as the richness of Web pages and the complexity of Websites grows, integrated tools to assist with collaborative Web site management willbecome increasingly necessary. For version 2 of the BSCW system, describedabove, we have therefore provided better support for this application of the system.The access control mechanism allows objects to be declared ‘public’, so thatusers can request these without a registration on the server. In addition we havesimplified the process of creating and editing Web pages by providing support fordirect uploading from a number of WYSIWYG HTML editors, including NetscapeNavigator Gold.

We have recently begun to repeat the process of system deployment with ver-sion 2 of the BSCW system. In conjunction with our user groups in the ‘Coop-WWW’ project a more rigorous evaluation of the system is being performed toinform the next stage of development, including integration of more sophisticatedfeatures for access control, version management and more.

5. Experiences and perspectives of the Web as enabling technology forCSCW

The above description of our work with the BSCW shared workspace systemis intended to illustrate some possibilities for developing and deploying CSCWapplications on the Web. In this paper we are concerned primarily with the Webas a potential enabling technology for CSCW systems, rather than possibilities forenhancing the Web itself with mechanisms to make it more ‘collaborative’. Wetherefore focus our discussion on the role of the Web as a vehicle for developing

[18]


and deploying CSCW systems, instead of a target of CSCW research in its ownright, and thus orient more to the utility of current and future Web standards forCSCW systems rather than possible modifications to these standards as informedby CSCW research. This last, however, is clearly an area where CSCW and theWeb have much to say to each other; for example, the phenomenon that the Web iscurrently a ‘lonely place’ is an argument put forward by Lea et al. (1997) for theirwork on Virtual Societies, and the goal of adding group ‘awareness’ mechanismsto 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 aresearch 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 technologyis twofold, easing problems of both development and deployment of CSCW sys-tems in real-world domains, and that deployment is best achieved when systemsintegrate smoothly with existing Web technologies. We now discuss the possibil-ities and problems of developing CSCW systems on the Web, before reviewingrecent developments which might address these problems and broaden the rangeof 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 theemphasis to date on the Web as a tool for information browsing. This allows infor-mation providers to design and retain control of the form and content of theirinformation and ‘publish’ it via a Web server. Consumers can then access the infor-mation by sending requests via their Web browsers. The CGI server programminginterface 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 pagesstored in files on the server file system.

Our experiences with the BSCW system suggest that, as a tool for applicationdevelopment, it is straightforward to extend the Web with application functionalityor interface to an existing application. The method of passing request details throughthe CGI programming interface is simple and allows developers to write extensionprograms in most programming languages, with no need to link extension codewith the server. Extension programs must generate and return HTML which againis straightforward. In combination with a high-level, interpreted programminglanguage such as Python, this arrangement allows extremely rapid prototyping andtesting 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 theround-trip to the server to service every user interaction. When requesting docu-ments or even HTML pages this delay may be acceptable, but for simple requests,

[19]


especially those which change only the state of the interface, this delay is a prob-lem. For example, with the BSCW system it is possible for users to fold in/out theobject 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 folderlisting. Using these features requires a request to the server to generate a modifiedHTML page, and when interacting via the Internet (as do most of the users ofour public server) network delays represent a much larger component of the totaltime to service the request than processing time. In designing a user interface for aWeb-based application, developers must take care to reduce the number of requiredtrips 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 detailsof the request may allow rapid development, but gives the developer no chance tomodify server behaviour or request information which is not passed explicitlythrough the CGI. Where the default behaviour is adequate, as is the case for theuser authentication features used directly by BSCW for example, there are noproblems. Where features are inadequate for an application’s needs the developercannot modify these but must either re-implement them using the CGI or build acustom HTTP server (Trevor et al., 1996).

The Web is best suited as a development platform for applications whichdo not need to step outside the information provider-consumer model, current-ly enshrined in existing standards and browser and server implementations. Whenthis is required, it is often necessary to provide additional components at the serveror client (in the form of helper applications). The latter removes one of the mainadvantages of the Web, which is the ability to deploy systems without requiringdevelopment of client programs that run across platforms or installation of addi-tional software by users. For BSCW, the need to upload documents to the serverhas required considerable effort to produce versions of the (very simple) helperwhich operate on PC, Macintosh and Unix machines. For this and other aspectssuch as synchronous notification, information replication and so on the basic Webstandards and components offer no support and developers must provide their ownsolutions.

Much of the work in the Web standards community is focusing on refinement ofprotocols, client and server architectures to improve the speed and reliability withwhich requests can be handled, and not on providing more flexible and powerfulcomponents for application development. This emphasis is not surprising; thegrowth of the Web has been so rapid that aspects of the HTTP protocol in particularmust urgently be re-designed to ensure the Web architecture can continue to scaleto millions of users world-wide. However, this growth has also led to demand fromusers and third-party vendors for extensions to Web components to allow richersupport for different media types, user interfaces and so on. To meet this demand,

[20]


server and browser vendors have proposed a number of mechanisms and builtsupport for these in their products.

There is some evidence that this practice is key in the continuing developmentof the Web. An example of this is the support for HTML page editing and remotepublishing, identified as an area requiring support by a number of vendors includingNetscape (with the Navigator Gold browser), Microsoft (with FrontPage) andGNN’s GNNPress. Although the solutions offered are currently incompatible, allhave a need for uploading documents to a Web server and this has promptedefforts to agree a standard method for doing this.? Similarly, the need for richerWeb pages has led to tools like Java and JavaScript being supported by the majorbrowser vendors and becoming de-facto standards. Where relevant, these de-factostandards have also filtered into the documented standards process, as is the casewith some of the proprietary extensions to HTML now part of the latest proposedstandard, HTML 3.2.

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 innovationwill increase. The growth of the corporate intranet, for example, raises require-ments of information replication, workflow services and the like, while commerceapplications require much higher levels of security and privacy than are currentlysupported. Although many vendors will seek to provide proprietary solutions tothese requirements, and thus lock corporate customers into particular technologicalsolutions, it is also clear that technologies are emerging which have the potentialto broaden the possibilities for third-parties to customise Web components anddevelop new extensions in a more generic fashion.

The problems of the CGI approach to extending an existing Web server are wellknown, and vendors of Web server technology are seeking to provide more flexiblesolutions for developers. For example, in designing the API for the Apache server(currently the most well-deployed Web server on the Internet), the developerssought to allow “third-party developers to easily change aspects of the serverfunctionality which you can’t easily access from CGI” (Thau, 1996, p. 1113).Similar developments in browser programming interfaces such as Netscape’s ‘Plug-in’ development kit and Microsoft’s ‘ActiveX’ environment are intended to extendthe 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 developmentof much richer CSCW systems, better integrated with desktop environments than ispossible with basic Web components. In the main, however, these developments are

? The World Wide Web Consortium (W3C) has recently established a working group on “Distrib-uted Authoring and Versioning on the World Wide Web” to examine requirements and work towardsspecifications to support this activity. See http://www.ics.uci.edu/˜ ejw/authoring/

[21]


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-platformdeployment of CSCW systems. Although some vendors have announced supportfor others’ programming interfaces, it remains to be seen how this will work inpractice as they (particularly browser vendors) seek to differentiate their productson the basis of the richness of features supported.

An approach which is independent of particular client and server programminginterfaces seems to offer more potential in this regard. One area receiving muchattention is that of ‘mobile code’ where, in addition to data in HTML or otherformats, a browser might download small application programs or ‘applets’ whichare executed on the local machine, taking input and displaying output via the Webbrowser. This should remove many of the constraints on the application developer:applets can be designed which provide much richer user interfaces than are possiblewith HTML; computation can be moved to the client, for example to check forvalid input data and thus reduce network traffic, server loading and feedback lags;applets supporting special protocols can be developed which handle different mediatypes and so on.

Although there are many problems to be overcome, most notably security con-cerns 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’sJava programming language is now provided by the latest Web browsers fromNetscape, Microsoft and IBM. For tasks requiring less power than a full program-ming language, scripting tools like Netscape’s JavaScript follow similar principlesbut are less ambitious, allowing HTML pages to be extended with code fragmentsto pass responsibility for simple computations from the server to the client.

We see these developments as broadening the role of the Web as an enablingtechnology for CSCW, increasing the range of CSCW systems which can be devel-oped while not compromising the benefits of cross-platform system deployment.In the BSCW project we are making use of both Java and JavaScript to overcomeproblems with the basic Web components and provide richer collaboration servicesto users of the BSCW system. With JavaScript we have augmented the HTML userinterface of the BSCW system to remove the need to send requests to the serverfor changes in user interface state, including the folding of actions and descriptionsand the select all/none behaviour discussed above. With Java we are being moreambitious, designing applets which provide synchronous collaboration servicessuch as event notification, presence awareness, simple text chat and more, whichcan be presented in standard Web browsers alongside the existing BSCW HTMLuser 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 ‘enablingtechnology’ for CSCW, arguing that such a technology should assist with both the

[22]


development and deployment of CSCW systems beyond the laboratory. Despite thecurrent limitations of the Web as a platform for development, the advantages of anaccepted technology integrated with different hardware and software environmentssuggests that the Web is worthy of attention from the CSCW community. Usingexamples from our own work with the BSCW shared workspace system, we havetried to illustrate the kinds of systems which can be implemented and directlydeployed on the basic Web architecture, and some of the benefits when this approachis followed.

In general, we see the continuing development of Web technologies, and in par-ticular those which provide greater flexibility to system developers while supportingopen standards and cross-platform, client and server implementation, as transform-ing the Web from a platform for information browsing to a more sophisticatedenvironment for system development and deployment. We believe it is importantthat the CSCW community takes the opportunities offered by the Web, and indoing so helps transform the Web from a largely passive information repository toan active tool for cooperation.

Acknowledgments

We wish to thank our colleagues in the BSCW project whose work is reported in thispaper: Wolfgang Appelt, Uwe Busbach, Elke Hinrichs, David Kerr, Klaas Sikkeland Gerd Woetzel. Parts of this work were funded by the Telematics ApplicationsProgramme of the European Union under contract TE 2003 (CoopWWW).

References

Backer, A. and U. Busbach (1996): DocMan: A Document Management System for CooperationSupport. In Proceedings of 29th Hawaii International Conference on System Sciences, volume III,Maui, Hawaii, 3–6 January 1996. Los Alanitos, CA: IEEE Computer Society Press, pp. 82–91.

Bannon, L. (1996): Use, Design and Evaluation: Steps towards an Integration. In D. Shapiro, M.Tauber, and R. Traunmuller (eds.): The Design of Computer Supported Cooperative Work andGroupware Systems, Amsterdam: North-Holland, pp. 423–444.

Bentley, R., T. Horstmann, K. Sikkel, and J. Trevor (1995): Supporting Collaborative InformationSharing with the World Wide Web: The BSCW Shared Workspace System. In The World WideWeb Journal: Proceedings of the 4th International World Wide Web Conference, Boston, MA,12–14 December 1995. Sebastopol, CA: O’Reilley & Associates, pp. 63–74.

Bentley, R. and W. Appelt (1997): Designing a System for Cooperative Work on the World WideWeb: Experiences with the BSCW System. In Joy F. Nunaroker and Ralph H. Sprague (eds.):Proceedings of 30th Hawaii International Conference on System Sciences, Maui, Hawaii, 7–10January 1997, Washington: IEEE Computer Society Press, Volume IV, pp. 297–306.

Bentley, R., W. Appelt, U. Busbach, E. Hinrichs, D. Kerr, K. Sikkel, J. Trevor, and G. Woetzel(1997): Basic Support for Cooperative Work on the World Wide Web. International Journal ofHuman-Computer Studies, special issue on ‘Innovative Applications of the World Wide Web’ (inpress).

Berners-Lee, T., R. Cailliau, A. Luotonen, H. Frystyck Nielsen, and A. Secret (1994): The WorldWide Web. Communications of the ACM, vol. 37, no. 8, pp. 76–82.

Dewan, P. and R. Choudhary (1992): A High-Level and Flexible Framework for ImplementingMulti-User User Interfaces. ACM TOIS, vol. 10, no. 4, pp. 345–380.

[23]


Fitzpatrick, G., W. Tolone, and S. Kaplan (1995): Work, Locales and Distributed Social Worlds. InProceedings of ECSCW’95, Stockholm, 10–14 September 1995. Dordrecht: Kluwer, pp. 1–16.

Dix, A. (1997): Challenges for Cooperative Work on the Web: An Analytical Approach. ComputerSupported Cooperative Work: The Journal of Collaborative Computing (this issue).

Gorton, I., I. Hawryszkiewycz, and L. Fung (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. Los Alanitos, CA: IEEE Computer Society Press,pp. 72–81.

Grasso, A., J. Meunier, D. Pagani, and R. Pareschi (1997): Distributed Coordination and Workflowon the World Wide Web. Computer Supported Cooperative Work: The Journal of CollaborativeComputing (this issue).

Greenberg, S. and M. Roseman (1996): GroupWeb: A WWW Browser as Real Time Groupware. InCompanion Proceedings of CHI’96. New York: ACM Press, pp. 271–272.

Lea, R., Y. Honda, and K. Matsuda (1997): Virtual Society: Collaboration in 3D Spaces on theInternet. Computer Supported Cooperative Work: The Journal of Collaborative Computing (thisissue).

Palfreyman, K. and T. Rodden (1996): A Protocol for User Awareness on the World Wide Web. InProceedings of CSCW’96, Boston, MA, 16–20 November 1996. New York: ACM Press, pp. 130–139.

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. New York: ACM Press,pp. 87–95.

Rao, V. (1995): The Implementation of Satellite Offices: Initial Recommendations Based on Observa-tions from One Site. In Proceedings of 28th Hawaii International Conference on System Sciences,Volume IV, Maui, Hawaii, 3–6 January 1995. Los Akinitos, CA: IEEE Computer Society Press,pp. 426–436.

Rodden, T., G. Blair, and J. Mariani (1992): Supporting Cooperative Applications. Computer Sup-ported Cooperative Work: The Journal of Collaborative Computing, vol. 1, no. 1, pp. 41–67.

Roseman, M. and S. Greenberg (1995): Building Real-Time Groupware with GroupKit, a GroupwareToolkit. ACM Transactions on CHI, vol. 3, no. 1, pp. 66–106.

Shen, H. and P. Dewan (1992): Access Control for Collaborative Environments, in Proceedings ofCSCW’92, Toronto, 31 October–4 November 1992. New York: ACM Press, pp. 51–58.

Thau, R. (1996): Design Considerations for the Apache Server API. In Computer Networks andISDN Systems 28: Proceedings of 5th International World Wide Web Conference, Paris, 6–11May 1996, pp. 1113–1122.

Trevor, J., R. Bentley, and G. Wildgruber (1996): Exorcising Daemons: A Modular and LightweightApproach 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., D. Randall, and R. Bentley (1994): Situated Evaluation for Cooperative Systems.In Proceedings of CSCW’94, Chapel Hill, NC, 22–26 October 1994. New York: ACM Press,pp. 441–452.

Vitali, F. and D. Durand (1995): Using Versioning to Provide Collaboration on the WWW. In TheWorld Wide Web Journal: Proceedings of the 4th International World Wide Web Conference,Boston, MA, 12–14 December 1995. Sepastapol, CA: O’Reilley & Associates, pp. 63–74.

[24]

The World Wide Web as Enabling Technology for CSCW: The Case of BSCW

Documents

Transcript of The World Wide Web as Enabling Technology for CSCW: The Case of BSCW