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