Supporting information evolution on the WWW

World Wide Web 1 (1998) 45–54 45

Supporting information evolution on the WWW

I. Sommerville a, T. Rodden a, P. Rayson a, A. Kirby a and A. Dix b

a Computing Department, Lancaster University, Lancaster LA1 4YR, UKE-mail: {is,tom,paul,ak}@comp.lancs.ac.uk

b School of Computing, Staffordshire University, Stafford, ST18 0DG, UKE-mail: [email protected]

This paper describes a simple versioning system which we have developed to support collaborative authoring on the WWW. Thesystem provides facilities for versioning pages and allowing readers access to different versions of web pages. We discuss why such asystem is needed and present the versioning model which we have developed. This model allows existing web pages to be converted toversioned entities without affecting links to these pages. Central to the model, is a set of access control facilities which allows authorsto provide co-authors with access to versions of pages under development. We describe the instantiation of this model and assess ourwork against the requirements identified in the first part of the paper.

1. Introduction

The World Wide Web has, in a remarkably short time,become a major publishing medium for a large number ofauthors. It is now the norm to see traditional publicity andpublication media supplemented by world wide web activi-ties. The explosive growth of the web has meant that manyorganisations have been pressurised into creating web-basedinformation systems quickly. They have not had time toconsider longer-term issues of information evolution, man-agement and maintenance. However, these problems ofinformation evolution are now manifesting themselves tousers of the web in a number of ways:

• Information on web pages changes arbitrarily. On revis-iting a page, readers may be surprised that previouslyavailable information is no longer accessible. Evenwhen users register interest with particular pages andare e-mailed with information about page updates, littleor no access is provided to the previous page.

• Little or no management information is provided. Pagesare often marked as ‘Under construction’ with no infor-mation about when the construction started or when itis likely to be finished. Often readers have to revisit thepages regularly to see if a completed page is available.

• When a page is being revised, web page creators oftenhave to create copies and maintain them in a separatefile store until the revisions are complete. This causesproblems when pages have many links which must alsobe copied and their URL’s modified. While, of course,in-situ revision is possible, changes are permanent. Ifmistakes are made, it may be difficult or impossible torecover from them.

In addition to these problems, developers of web pagesface additional difficulties when several people are involvedin developing a page or set of pages. They must work inde-pendently on their own copies of the pages then (somehow)

integrate these independent efforts to create the final pages.There is no easy way to review and check alternative pagedesign proposals or for one developer to link into a subsetof the pages being developed elsewhere.

This paper seeks to address the issues of managementby developing a set of management facilities to support thepublication of information on the world wide web. It isimportant that these facilities are developed in line with thesimple and low cost philosophy central to the world wideweb. Any developed management facility for the worldwide web needs to exist within the current working prac-tices of the world wide web or else it runs the risk of failingto be used.

The work described in this paper addresses some of theproblems of WWW information evolution. We have devel-oped a simple WWW page versioning system which allowsfor the maintenance of multiple versions of web pages andprovides an access control mechanism to these pages. It istherefore particularly useful in the following situations:

1. Where information naturally evolves through a series ofversions and where there is a need to have access to pre-vious versions as well as the current version. An exam-ple of this might be the specifications of some productwhich change over time but where it is clearly desir-able to maintain the specifications of all versions of theproduct which have been offered for sale.

2. Where information is produced as a collaborative effortwith teams of people responsible for the information cre-ation. Here, we have rapid evolution where individualsmay propose changes which have to be agreed by allteam members. If changes are not accepted, there mustbe a reversion to the previously agreed version.

Our work has been designed so that it can be introducedseamlessly into a WWW information system without mak-ing any changes to the organisation or the content of thatsystem and without requiring the use of plug-ins or helper

Baltzer Science Publishers BV

46 I. Sommerville et al. / Supporting information evolution on the WWW

applications in WWW browsers. In the remainder of thispaper, we present a number of scenarios where versioningcan support users and creators of WWW pages, describeour objectives for the versioning systems, discuss the ver-sioning model which we have developed and its implemen-tation and, finally, assess how well we have achieved theseobjectives.

2. Version support requirements of WWW users

In this section, we discuss some general requirementsfor WWW page versioning. To put these requirements intocontext, we first present two usage scenarios for the WWW.The first of these scenarios is concerned with the problemsof cooperative page construction; the second with the prob-lems of managing archival information as WWW pages.

Scenario 1 – Cooperative page creation

A group of people are working together to produce aset of web pages to publicise a conference. This group in-cludes the conference manager who provides some informa-tion and comments on the proposed pages, the conferencesecretary who provides information about the conferencesessions, a web page designer who is concerned with thelayout and organisation of pages and a travel organiser whoprovides information about hotels and links to travel infor-mation. The information about the conference evolves overtime from a preliminary announcement to the publicationof the full conference programme.

Versioning facilities might be used by this group in anumber of ways:

1. After the creation of an initial conference page, each in-dividual uses this as a master copy for their own versionwhich they can then work on independently to includethe information relevant to their work. However, theywant to be able to access other people’s versions to seewhat they are doing and, if appropriate, to comment onthis work.

2. Periodically, a new ‘public’ version of the conferenceweb pages must be produced by integrating informationfrom a number of different versions. In the case ofmore formal procedural information this often requiresthe agreement of a conference committee.

Scenario 2 – Management of archival information

Many publishers of technical journals have now imple-mented or are considering on-line publication. There aremany advantages in this approach such as reduced costs,faster publication and wider dissemination. Currently, thesepublications replicate paper-based publication but, in thelonger term, it is likely that we will see publishers takingadvantage of the dynamic nature of electronic media. Itwill be possible to link technical papers with letters com-menting on these papers, details of corrections and withlater results of the work.

However, there is a conflict here with the need forarchival publication. Some technical journals, such as theACM Transactions, are archival publications in that pub-lished information may be used many years after originalpublication. If such archival information is referenced byanother author, users who trace the reference at some latertime should be guaranteed access to the original publishedinformation which was referenced. There is therefore aconflict which is inherent to electronic publication. On theone hand it must be possible to reference a particular ver-sion of a document and be sure that subsequent readerswill be able to trace the same text that you have read. Onthe other hand it is useful to allow authors or even read-ers to correct and update material thus allowing a dynamicevolving literature.

Versioning facilities can resolve this dilemma. An ini-tial version of a paper may be published and, as new in-formation becomes available, new versions can be created.Therefore, if an algorithm in a paper contains an obscurebug which is only revealed several years later, a new ‘cur-rent’ version of the paper can be created by the authorwhich corrects the problem. Access to the previous ver-sion will still be possible so archival publication is stillguaranteed.

Figure 1 shows some of the versioning requirementswhich may be derived from each of these scenarios.

As well as the requirements for specific support facil-ities, we felt that it was very important that a versioningsystem should fit in with the general mode of WWW usageand should not force new ways of working on either webpage creators or users of versioned web pages. The follow-ing requirements were therefore a very significant influenceon the design of our system:

Cooperative web page creation Management of archival informationRequirements Independent development of private versions of the web

pageStraightforward conversion of unversioned to versioned webpages

Awareness of the actions of other version developers Several co-existing ‘public’ versions of a WWW page

Facilities allowing developers to comment on other user’swork

Display of ‘most recent’ version and navigation to earlierversions

Integration of different versions to form an agreed ‘publicversion’

Facilities to add comments and further information to thepublished information

Figure 1. Versioned web page requirements.

I. Sommerville et al. / Supporting information evolution on the WWW 47

1. Each web page can have an unknown number of links– it must be possible to convert a web page instance toa versioned page in such a way that future accesses tothe original URL continue to work.

2. There must be some mechanism to inform users thatthey are dealing with a versioned entity and it must beeasy for them to access different versions of the currentpage.

3. Each version of a page should indicate visually, if pos-sible, its unique characteristics so that readers can un-derstand the difference between versions. This is a par-ticular problem where the differences between pages arenot in the page content but in the items embedded in thepage (e.g., Java applets).

4. The easy-to-use interaction metaphor of web browsersmust be maintained. As far as possible, users shouldnot have to register as readers of pages nor should theyhave to go through some login sequence before access-ing information.

We believe that these usability requirements are at leastas critical for the success of any WWW versioning sys-tem as the specific functionality which is provided. Webusers expect simple ‘point and click’ interfaces and systemswhich are complex are unlikely to be used.

3. Related work

The need to provide some version support for teamsworking on the collaborative development of computer-based information has been recognised for many years. Theearliest form of this support was in version managementsystems such as SCCS [Rochkind 1975] for software de-velopment. The objectives of these early systems were tocontrol cooperative working so that users working simul-taneously on the same software could not over-write eachother’s work and to reduce the storage requirements formultiple software versions. These configuration manage-ment systems have evolved into very sophisticated systemssuch as ClearCASE [Leblang 1994] and Adele [Estublier1985] which provide active process support as well as con-trol. However, many software developers do not need suchsophisticated version management facilities and simple ver-sion management systems such as SCCS and RCS [Tichy1985] are still widely used.

Reuter et al. [1996] have demonstrated that WWWbrowsers may be used as a front-end to a revision con-trol system. They provide distributed revision control forsoftware developers through a client-server system wherethe server is a revision control engine and the client is aweb browser. They are concerned with providing accessto versioned files (source code say) rather than web pages.The web browser is used to provide distributed access anda graphical interface to the underlying revision control sys-tem.

Douglis and Ball [1996] describe a system (AIDE) whichthey have implemented which provides some version sup-port using the RCS system. Their main objective is toallow users to see the differences between WWW pageswhen pages are updated. They allow users to store pagesin an RCS system and provide a facility to display the dif-ferences between the stored and the current versions of apage. Users explicitly request the system to display differ-ences between the current page and a page version storedaccording to date. The system also provides an automaticfacility to detect when pages of interest have been updatedand can retrieve the most recent versions of these pages.New versions of web browsers, such as Netscape, are alsoincreasingly incorporating this facility.

The AIDE system is not a generalised versioning sys-tem as versioning is the explicit responsibility of the WWWclient rather than the server. It relies on end-users remem-bering to store versions and it is difficult for users to knowif they have maintained all versions of a page. The versionsare stored at a local site and explicit actions are necessaryto allow distributed groups to access the version set.

Existing configuration management systems rely on theirown data management system. If these were used forserver-side version management of WWW pages, thiswould have to be integrated with existing http protocols.While this is probably possible, it would be slow andclumsy. Furthermore, configuration management systemsare notoriously difficult to use and the more advanced sys-tems impose a specific process model which is normallyorganisation-specific. Not only is it completely unrealisticto expect web page creators to be able to use the sophisti-cated facilities of these systems, the open nature of the webprecludes the use of a predefined process model.

General-purpose hypertext systems have mostly skirtedaround versioning issues. Cybulski and Reed [1992] identi-fied the need for configuration management where hypertextsystems were used for software process support. However,their paper provides little information about the version-ing approach which was actually used. Garg and Scacchi[1990] also used a hypertext system for software documentmanagement but again do not discuss the version modelwhich was used.

Those hypertext systems, such as NEPTUNE [Delisleand Schwartz 1986], which have addressed this issue ver-sion everything within an internal storage management sys-tem. It is not clear whether or not this is a manageablesolution to the problem. The best documented approach tohypertext versioning that we are aware of is in the COVERsystem [Haake and Haake 1993]. COVER is a hyper-media version server which essentially provides facilitiesto manage version sets and version identification throughattributes. COVER is part of a hypermedia environmentcalled SEPIA and a closed version representation is used.References to entities are indirect and may be translatedautomatically to version set references. However, the factthat WWW pages can include direct links as URLs meansthat this approach is not translatable to a web-based system.


Figure 2. Replacement of existing web page with V-Web page.

Issues of versioning have been largely ignored by theWWW community until recently. Vitali and Durand [1995]proposed VTML, a mark-up language for storing documentversion information, but this requires a parser to sit be-tween the web server and the document store to processall documents on the fly. Work in progress at GMD on theCoopWWW project [Appelt 1996] builds on previous workon the BSCW system [Bentley et al. 1997]. BSCW pro-vides basic support for version management within a linearversion history so that users can be aware of the existenceof earlier versions and can read these versions. However,it does not allow editing of previous versions. MacArthuret al. [1997] published a list of requirements for a changemanagement system for the WWW (PowWow) and appearsto have implemented some of these requirements. Theyrecognise the need for managing versions of pages but itis not clear whether or not they have actually implementedsuch a facility.

The Working Group on Distributed Authoring and Ver-sioning on the World Wide Web (WebDAV) was set upin May 1996 to address problems created by the additionof write capability to HTTP. Internet standards in this areamay eventually emerge, but it is not clear if they will coverthe versioning issues that we are addressing here. CurrentWebDAV work in progress is to specify a set of require-ments for the versioning model. This allows for branchingand merging in the ‘version graph’, and requires that linksto specific versions should be available. We assume thatthis will be achieved by the server maintaining state in-formation and by extensions to the HTTP protocol. Thismeans that the impact of the work will be long-term as itwill require a new generation of web browsers to supportthese changes.

4. The V-Web model

The versioning system which we have designed (V-Web)is based on a simple model of page versions. The principaldesign constraint on this model, was the need to maintainpage access through the original URL of the unversionedpage and the flexible simplicity associated with the worldwide web. Users of the Web are rightly irritated whenthey re-access a page and find that it no longer exists inthat location. Any WWW versioning model which requiresURL changes is unlikely to be acceptable to WWW users.

In our version model, an original unversioned page isreplaced by V-Web frame page. This contains the originalpage contents and a reference to a list of versions of thepage which is maintained in a separate directory along withinformation about each version instance. So long as thelink or replacement page conforms to the HTML standardthen the HTTP server will present the new page in thesame manner as the old page. We ensure that accessing thelink to the version set automatically results in the displayof page contents; we do not just present a version list asmost readers do not care about versions. They do not wantto be surprised when an unversioned page is replaced bya V-Web page. Our model allows for branching of theversion history and parallel editing is permitted. However,negotiation between users is necessary to resolve conflictingversions.

Figure 2 shows how the addition of a versioned webpage fits in with existing storage of web pages. In this dia-gram, there are four web pages files namely first.htmlto fourth.html. First.html to third.html aresimple html files. However, fourth.html has been replacedby a V-Web page which references 2 versions of the orig-inal page. When a V-Web page is created, a sub-directoryis created and the original unversioned page is moved tothat sub-directory. All subsequent versions are created inthe sub-directory so that the V-Web page includes, essen-tially, a list of version links. We make this usable by addingfunctionality through a set of CGI scripts which ensure thatthe user is not simply presented with a version list but cansimultaneously view any of the versions of that page whichhave been created.

A V-Web page is made up of three frames as shown infigure 3.

Figure 3. Presentation of the V-Web page within frames.


The three frames on a V-Web page are:

1. A display frame where the contents of the ‘current’version are displayed. The frame acts like any otherbrowser window, allowing links within the web page tobe traversed with new pages being displayed within theframe.

2. A version information frame which provides informationabout each known version instance. Users may selectany version from this list for display in the display frame.This version information is stored in a descriptor file foreach V-Web page. This descriptor is read by a CGI scriptwhich produces the version instance data frame of the V-Web page, or by a Java applet which provides a scrolledlist view of the information. The format of the descriptoris extensible so that other information such as date andtime of last view or instance comments may be addedas the requirements for the versioning system evolve.

3. A toolbar frame which provides access to the functional-ity of the versioning system. Toolbar icons are linked toCGI or Java scripts which provide the system function-ality. Again, this display is optional so is not normallydisplayed to users who are not interested in the differentpage versions.

4.1. Access control

As well as providing support for public versions ofpages, V-Web is also designed to support versions whichare private to an individual or a group. Accordingly, wehave implemented some access control facilities in the sys-tem where the designers of a version may limit access, ifthey choose to do so, to members of a preregistered group.This access model supplements the existing authorisationfacilities in server software by providing a more generalmodel which is more directly accessible to users of theworld wide web.

V-Web pages have an associated access attribute whichmay either be set to PUBLIC which means that the pagemay be accessed and viewed by anyone or PRIVATE whichmeans that access is restricted to a predefined group. Ac-cess is at the version level so PUBLIC and PRIVATE ver-

OWNER OPEN RESTRICTED CLOSEDAlter page access attribute

√

Alter access permissions√

Overwrite version√

Create new version√ √

Read version√ √ √

Version awareness√ √ √ √

Figure 4. V-Web page access permissions.

sions of a page may coexist in the same version set. Each‘private’ page has an associated access control file whichholds the list of registered users for that page along withtheir access permissions. Potentially, this could lead to anexplosion of information if there were thousands of regis-tered users associated with a page. However, as the accesscontrol is primarily intended for group authoring, we do notanticipate that registered groups will be large so managingthe access control information is unlikely to be a problem.

The current permissions which are supported are OWN-ER, OPEN, RESTRICTED, CLOSED. Figure 4 shows thefacilities available to users in each of these classes.

Page readers need not identify themselves to the systembut members of a group who wish to collaborate on pagedevelopment must do so. Access control to ‘private’ pagestherefore requires that page developers log-in to the V-Websystem. This is discussed in later sections of the paper.Pages may be ‘owned’ by more than one member of agroup so several individuals may be able to control accessto the page. We assume that some informal negotiation willgo on amongst the group to ensure that this will not causeproblems. In figure 4, ‘version awareness’ means that usersare made aware that a new version is under developmentbut do not have access to the contents of the pages. Thisis discussed later in the paper.

4.2. Model limitations

The model we have developed is necessarily very sim-ple. The distributed hypertext model which underlies theWorld Wide Web imposes fundamental limitations on theversioning support which can be provided. Ideally, wewould like to support both of the scenarios illustrated infigure 5. These are:

Figure 5. Generalised versioning.


A. A link from one unversioned page to another is con-verted into a link to a page version set. This is currentlysupported and is most appropriate where versions areupdated over a period of time. Linked pages should beable to access the most recent and all other versions.

B. A link from one unversioned page to another is con-verted into a link to a specific page version within apage version set. Links are therefore absolute. Thistype of link is useful where there is a need to ensurethat links always refer to exactly the same information.Of course, in existing systems this cannot be guaranteedas the page which is referenced may change.

The situation illustrated above in scenario B is, of course,a general problem faced by version management systems.However, where versions are managed in a centralised data-base, the problem is lessened by ensuring that all links aretwo-way links. All references to a version may be discov-ered and some semi-automated process used to establish theright type of link. The problem that we face is that whenthe owner of page P2 wishes to convert P2 into a versionedentity, it is not possible to find all of the links to P2 norto deduce whether these should be links to the versionedentity or to the original page.

This problem has been tackled in more general hypertextsystems [Hann et al. 1992] such as Intermedia where alink server is used to manage the links between hypertextentities. This requires a separate database of links to bemaintained. As the WWW relies on links embedded in thesource rather than maintained as a separate list, it is notpossible to use this solution to the problem of versionedlinks.

The V-Web system, therefore, does not currently sup-port general users who require a link to a specific version.For ‘private’ pages, registered page users can indicate apreferred version which should be their default display ver-sion when they access a V-Web page. Furthermore, theuser may also request that the system should remember thelast version accessed by that user and that this should bethe default display version, even if later page versions arecreated. We can thus provide some approximation to therequirements outlines in scenario B with direct links be-tween specific pages. In implementing these features, werely on the server to remember state information.

Storing preferences locally on the client is possible usingJavascript cookies. However, we cannot assume all userswill have sufficiently advanced browsers and local securitymay not allow the creation of cookies. We therefore de-cided that server-side maintenance of this information wasmore appropriate.

5. V-Web system facilities

The facilities in the V-Web system implement the re-quirements which we identified in section 2. All function-ality is provided through CGI scripts associated with the

V-Web page. We do not make any assumptions about theconfigurations of V-Web clients to allow the developed sys-tem to be as open as possible. No helper applications orplug-ins are required.

The basic facilities of the system include:

• Facilities to present versioned web pages as a collectionof pages and to access any of the pages in the versionset. Filtering and sorting facilities for the versions inthe version set.

• Facilities to convert pages to V-Web pages and add ver-sions to the V-Web version set.

• Facilities to add version instance information (owner,creation date, etc.) to a specific version of a web page.

• Support for group authoring of V-Web pages.

These are described in more detail in the following sec-tions.

5.1. V-Web page presentation

V-Web pages are accessed in exactly the same way asany other web pages by specifying their URL. When aV-Web page is accessed, the reader is presented with adisplay as shown in figure 6. Within the web browser, thetoolbar is displayed on the left edge, the list of versions inthe top window with the largest window reserved for pagedisplay.

Alternative pages for display are selected by clicking onthe appropriate version in the ‘version instances’ window.This causes the currently displayed page to be replacedwith the specified version. If the displayed page containsa link to another V-Web page, we replace all of the framesin the display with the frames of the referenced page, i.e.,we do not attempt to have versions within versions. Webelieve that it would be confusing to users and would leadto display windows which were too small to be of practicaluse.

The toolbar icons activate the following functions:

• Instances – provides access to filtering facilities to selectthe versions in the instance list and to sort the versionlist (e.g., by name). The list of displayed versions willonly include those versions which are accessible by thecurrent viewer of the page.

• Full Page – replaces the current display by a full pageversion of the page in the display window. By default,pages which are converted to V-Web pages are displayedin Full Page format for new readers.

• Manager – used to login to the V-Web system and togain access to the V-Web access control and awarenessfacilities described in section 4.1.

• Create – creates a V-Web page from an unversionedpage.

• Upload – adds a new version of a page to the pageversion set.

• Delete – deletes a version of a page.


Figure 6. A V-Web page display.

• Comment – allows a reader to add a comment to a ver-sion. Comments are like Post-it notes which can be readby all readers who have access to the version. They ap-pear in the instance list frame.

• Info on/Info off – switches the display of the version listpane on and off.

• E-notify – allows a reader to indicate that they wish tobe notified by e-mail when a new version of the pagebecomes available.

The default page version which is displayed to mostreaders is the latest version of the page. However, readersmay choose to register with the system and log-in whenaccessing a set of V-Web pages. This allows them to settheir own default display version. It also allows users ac-cess to the awareness facilities of the system, discussed insection 5.2.

Unversioned pages can be converted to versioned pageswithout affecting links so the system may be used to pro-vide a publishing environment where versioned and unver-sioned web pages exist side-by-side. Initially, informationis published as normal web pages which are created us-ing some HTML editing system. Versions are only cre-

ated when they are required so that no additional over-head is incurred when there is only a single version of apage.

5.2. Group authoring support

One of the principal aims of the developed facilities is asense of symmetry where information users and providersare given similar easy to use facilities. In particular, au-thors have the same rights as readers to easy-to-use facili-ties which do not involve a high learning overhead. If thecreation and management of versioned web pages is signifi-cantly more difficult than normal web page creation, authorswill not use the system. It is important that we do not re-duce the ease of information provision which underpinnedthe growth of the world wide web. We provide supportfor collaborative authoring and maintenance of web pagesthrough the access control facilities which we described insection 4.1.

In order to gain access to authoring support facilities,users must log on to the system by clicking on the ‘Man-ager’ button discussed in the previous section. Once users


Figure 7. Supporting multiple authors.

have been identified, they then have access to their ownprivate set of page versions.

Figure 7 illustrates the situation where there are severalusers with different version sets. Steve is unregistered andsees the public version set with page1.html as the default;Paul has registered and has set his default to page2.html;Andy has a number of private versions with his default setto newpage4.html.

If a user logs in as a member of a group they can seepages produced by other members of the group as wellas their own pages. They can be made aware of othergroup member’s activities and can coordinate their workwith them. We can therefore support the collaborative pagedevelopment scenario discussed in section 2.

Cooperative work relies on individuals working in ateam to have some awareness of what other team membersare doing. There has been some discussion of awarenessfacilities in the CSCW literature [Palfreyman and Rodden1996; Patterson et al. 1996] but there is currently no con-sensus on a general awareness model. Existing work hastended to focus on the development of simple real-timeawareness protocols that supplement the existing HTTPprotocol. Our aim is to provide an open means of showingusers access to different information and propagating theactions across a community of users as they occur. Ac-cordingly, we have provided relatively simple awarenessfacilities in the V-Web system:

1. Event awareness. Any user can ‘register’ with a pageand request e-mail notification when a new version ofthat page becomes available. This is supported for bothPUBLIC and PRIVATE pages. However the e-mail fa-cility only tells people when a new version has beenpublished. We also support awareness of work-in-progress by allowing version developers to set the ac-cess of their current pages to CLOSED. This will re-veal to other group members that they are working on anew version without exposing the contents of that ver-sion.

2. Content awareness. Members of a group can selec-tively expose the content of their work for commentby other group members. By setting the access to aversion to RESTRICTED, other group members cansee and comment on the work but cannot change itdirectly. If particular group members are trusted tomake changes, they can be given ‘OPEN’ access tothe page which means that they can copy and maketheir own changes to versions which are under develop-ment.We recognise that there would be some value in extend-ing access control to comments so that ‘confidential’comments could be supported. However, we are un-convinced that the benefits of this feature outweigh theadditional complexity involved and are of general utilitygiven the close integration of electronic message facili-ties.

Once group members have developed their individualversions, these must be merged into a single version forpublications. This involves a negotiation phase where theorganisation and content of the version are agreed and anediting phase to create the public version. Again, the ac-cess control facilities of the system allow for the creationof restricted experimental versions which can be discussedand amended by group members. Individual negotiationsare possible using standard ‘chat’ and electronic mail fa-cilities. We are considering the possibility of producingversion ‘thumbnails’ so that several pages can be displayedsimultaneously with some drag and drop capability for pagerearrangement. However, we suspect that such facilitieswill be provided in future web page editors so we havedelayed their implementation for the moment.

6. Conclusions

It is clear that the rapid growth in the volume of infor-mation available through the world wide web is becomingincreasingly problematic. One of the reasons for this is


Identified problem V-WEB solutionConverting single pages to versioned entities Accomplished using a simple mechanism which converts the existing page to a frame

set which includes a reference to a version directory.

Preserve the original URL of pages The frame set which replaces the original page has the same URL-access causes thedefault version to be displayed.

Inform users of page changes and provide access to newversions

When a reader revisits a page which has been converted to a versioned page, a versionlist is presented. Clicking on this list causes that version to be displayed in a frame.Users can register as being ‘interested’ in a page and are automatically e-mailed whena new version becomes available.

Visually indicate differences between versions We have not yet addressed this problem. Identifying differences between HTML pagespecifications is a nontrivial problem. Some work on this has been reported [Pino1996] and we hope to reuse this in future versions of the V-Web system. For example,a new version of a text item can be highlighted and linked to other versions of it.

Maintain easy-to-use philosophy of the Web This has been achieved – all operations are ‘point and click’ and web browserfunctionality is maintained.

Provide support for collaborative page authoring andmaintenance

A simple set of access control facilities combined with user registration allows forsurprisingly complete group authoring support.

Figure 8. V-Web achievements.

the increased demand placed on the information structuresand the need for better communication facilities. How-ever, it is also clear that the issues of complexity involvedare such that some form of management is needed to con-trol the vast volume of information now provided electron-ically.

A key issue in the provision of these management facil-ities is the manner in which it is provided. The technologyinvolved in the world wide web was not revolutionary in na-ture yet its growth and development has altered the way inwhich we consider on-line information. The decentralised,simple and low cost approach to information provision wasone of the principle reasons that the rapid growth of theworld wide web took place when others such as X.500 hadpreviously failed. It is vital that future management fea-tures recognise and fit within this ethos of the world wideweb.

Figure 8 summarises the progress we have made in thedevelopment of the V-Web system.

There is a fundamental conflict between the inherent dis-cipline of configuration management and the ad-hoc order-ing of the World Wide Web which must be resolved. Thework described here is a small step towards such a resolu-tion where we have provided simple facilities for web pageversion management which do not force versions on usersand which allow versioned and unversioned pages to bemixed. Software configuration management systems pro-vide much more powerful solutions but these are so com-plex that they are likely to be unacceptable to WWW usersand authors who have become used to an informal style ofworking.

Acknowledgements

The work described in this paper was supported by theUK’s Engineering and Physical Science Research Councilunder grant GR/J08560.

References

Appelt, W. (1996), “CoopWWW – Interoperable Tools for CooperationSupport Using the World-Wide-Web,” In Proceedings of ERCIMWorkshop “CSCW and the Web,” GMD, St. Augustin, Germany,pp. 91–94.http://orgwis.gmd.de/projects/W4G/proceedings/coopwww.html

Bentley, R., W. Appelt, U. Busbach, E. Hinrichs, D. Kerr, K. Sikkel, J.Trevor, and G. Woetzel (1997), “Basic Support for Cooperative Workon the World Wide Web,” International Journal of Human–ComputerStudies: Special Issue on Innovative Applications of the World WideWeb 46, 6, 827–846.

Cybulski, J.L. and K. Reed (1992), “A Hypertext-Based Software Engi-neering Environment,” IEEE Software 9, 2, 62–68.

Delisle, N. and M. Schwartz (1986), “Neptune: A Hypertext System forCAD Applications,” In Proceedings of the ACM SIGMOD Conferenceon the Management of Data, ACM Press, New York, NY, pp. 132–143.

Douglis, F. and T. Ball (1996), “Tracking and Viewing Changes on theWeb,” In Proceedings of the 1996 USENIX Technical Conference,USENIX, Berkeley, CA, pp. 165–176.

Estublier, J. (1985), “A Configuration Manager: the Adele Data Base ofPrograms,” In Workshop on Software Engineering Environments forProgramming-in-the-Large, ACM Press, New York, NY, pp. 140–147.

Garg, P.K. and W. Scacchi (1990), “A Hypertext System to MaintainSoftware Life-cycle Documents,” IEEE Software 7, 3, 90–98.

Haake, A. and J.M. Haake (1993), “Take CoVer: Exploiting Version Sup-port in Cooperative Systems,” In Proceedings of InterCHI’93, ACMPress, New York, NY, pp. 406–413.

Hann, B., P. Kahn, V.A. Riley, J.H. Coombs, and N.K. Meyrowitz (1992),“IRIS Hypermedia Services,” Communications of the ACM 35, 1, 36–51.

Leblang, D. (1994), “The CM Challenge: Configuration Management thatWorks,” In Configuration Management, W. Tichy, Ed., John Wiley,Chichester, UK, pp. 1–37.

MacArthur, K., S. Virdhagriswaran, G. Dakin, and M. Webb (1997), Pow-Pow – A World Wide Change Management System, Crystaliz, Inc.,Concord, MA.http://www.crystaliz.com/PowWow/PowWow.html

Palfreyman, K. and T. Rodden (1996), “A Protocol for User Awarenesson the World Wide Web,” In Proceedings of CSCW’96, ACM Press,New York, NY, pp. 130–139.

Patterson, J.F., M. Day, and J. Kucan (1996), “Notification Servers forSynchronous Groupware,” In Proceedings of CSCW’96, ACM Press,New York, NY, pp. 122–129.


Pino, J. (1996), “A Visual Approach to Versioning for Text Co-authoring,”Interacting with Computers 8, 4, 299–310.

Reuter, J., S.U. Hanßgen, J.J. Hunt, and W.F. Tichy (1996), “DistributedRevision Control via the World Wide Web,” In 6th International Work-shop on Software Configuration Management, Springer, Heidelberg,Germany, pp. 166–174.

Rochkind, M.J. (1975), “The Source Code Control System,” IEEE Trans-actions on Software Engineering 1, 4, 255–265.

Tichy, W. (1985), “RCS – A System for Version Control,” Software Prac-tice and Experience 15, 7, 637–654.

Vitali, F. and D.G. Durand (1995), “Using Versioning to SupportCollaboration on the WWW,” In World Wide Web Journal (FourthWWW Conference) 1, 1.http://cs-pub.bu.edu/students/grads/dgd/version.html