A new architecture for a collaborative authoring system

Computer Supported Cooperative Work (CSCW) 2: 159-174, 1994. .~ 1994 Kluwer Academic Publishers. Printed in the Netherlands. 1 5 9

A New Architecture for a Collaborative Authoring System Collaborwriter

K E I T H M c A L P I N E 1 & P A U L G O L D E R 2 Aston University, Birmingham, UK; Email- ][email protected]; [email protected]

,(Received 9 March 1993; in final form 25 October 1993)

Abstract. Much research has occurred in recent years detailing computer systems which support collaborative writing. In this paper we describe a collaborative authoring system capable of handling both synchronous and asynchronous communication between authors, based upon a writing model of coordination, writing, annotation, consolidation and negotiation. This assumes that the negotiation aspects play a major role in the collabora- !rive process. A model linking the logical structure of documents and author roles is also established, based on ~he Standard Generalized Markup Language.

Keywords. Collaboration, Negotiation, Authoring, SGML, CSCW

1. Introduction

Most computer-supported writing systems are based around the single user. For 'projects requiring multiple authors, this normally means the coordination of the document is done manually amongst the authors. While this may work when ~the authors are working closely together on a project, it can cause major prob- items when the people are dispersed and working at varying times. As group ..sizes increase, thus the coordination and management problems of these groups !increase.

A number of collaborative writing systems have been developed over the last ten years to help address some of these problems, which are inherent in group ]processes in general, and collaborative authoring in particular. Some of these '.systems are built around specific models of collaboration, some have grown out of other groupware systems, while some are general tools used for the easy creation of blocks of text among shared users.

There are many different types of authoring scenario, ranging from taking notes in group meetings, changing code in a multi-user programming environment, and the actual creation of large and complex reports and documents by multiple authors. As well as different scenarios, different types of authoring can ~:ake place. Authors may choose to work closely together on a work, or quite sep- arate - only merging their works at specific points in the project. For example, authors writing different sections of a composite publication, usually under one

160 KEITH McALPINE & PAUL GOLDER

editor, is common in magazines, newspapers and edited academic books. In general the individual authors take complete responsibility for their own work and have negligible input to the work of others, whilst the editor is responsible for maintaining a common style, controlling the volume of contributions, and having final control over the content and acceptability of a section to the overall document. Alternatively, authors may work closely on a text and jointly accept the final document. Again, individmd authors may write specific sections of the final document, which must be reviewed and accepted by all other authors involved, such as in the preparation of a contract or treaty. Finally, authors may work closely together on a task, often in close proximity, jointly writing and changing each others' text, such as in a brainstorming activity or a design meeting.

Current systems normally address specific scenarios and tasks. Systems designed for small groups don' t scale-up well to large organisation use, while systems designed for one task don't convert well to being used for another task.

Our design considerations for CollaborWriter primarily concern its use in large organisations, mainly by professional writers who would be using it for a large percentage of the time. The design is thus guided towards facilitating these authors with features known to be of use to professional writers cognitively, yet helping manage the complex group processes which occur inside a group. We also acknowledge that all types of cooperation is based on negotiation of one type or another (Vfimos 1991) and thus support negotiation amongst authors through tools similar to those used between managers and decision-makers in Negotiation Support Systems. Finally, as the Standard Generalized Markup Language (SGML) becomes more widely used in large organisations, we note how it can be exploited to provide varying views of a document. SGML also provides the facilities for ensuring that any required fields in documents are filled in (eg. the 'Memo From:' field in a memo), yet still provides, if required, great flexibility in the creation of these structures by a user.

2. Some current collaborative authoring systems

To combat the problems outlined above, a number of collaborative authoring systems have been developed to support groups working together in the joint production of documents. Some of these systems are built around a hypertext model, such as NoteCards (Trigg et al. 1986, Halasz 1988), Quilt (Fish et al. 1988, Leland et al. 1988), and SEPIA (Haake and Wilson 1992), whilst others are designed around a free-flowing document layout model, such as ShrEdit (Olson and Olson 1991) and GroupWriter (Malcolm and Gaines 1991), where the docu- merit is regarded as one large contiguous block of text, similar to most single- user wordprocessors of today.

NoteCards is a hypertext system for manipulating ideas that has been used for some collaborative authoring. It is based on the 3 X 5 paper notecard, and pro-

A NEW ARCHITECTURE FOR A COLLABORATIVE AUTHORING SYSTEM 161

vides links and browser facilities between the cards. It was designed for use by individuals and small workgroups, and as such offers only limited facilities for true collaborative writing.

Quilt is a hybrid of a multi-user hypermedia, computer-conferencing and mul- timedia electronic mail system. It assumes that people have different roles in the production of a document and assigns different privileges to these roles. It was developed on a centralised database system, and does not allow synchronous changes to a document. The document structure consists of a basic tree, consisting of a base document with n annotations, which contain further annotations, and so on. The comments can be either text or voice, and consist of private comments, public comments and directed messages. The system maintains a system and user log, where a user can say what they have been doing, or intends to do, while the system consists of messages like:

'Edited section 2.2 for 2 hours; 15 to 45 paragraphs changed'.

SEPIA is a hypertext authoring system consisting of various activity spaces used for structuring, planning, arguing and writing documents under a rhetorical perspective. It also models itself on three modes of collaboration: individual work, loosely coupled mode and tightly coupled mode. The system supports a smooth transition between these modes of collaboration, with automatic node locking and 'author awareness' when somebody is in the same node for loosely coupled work, through to shared views, telepointing, and an audio-visual connection for tightly coupled , work.

ShrEdit is a synchronous group writing system which allows for the fine- grained editing of text. It provides no prescribed structure for collaborative work, relying on the authors to form some method of working together. The system also provides both shared (public) and private views, and allows one author to 'track' another author's actions.

GroupWriter is based around the notion that the tool used for writing should contain all the features of existing commercial wordprocessing systems. It has full versioning facilities, being able to maintain multiple versions, reproduce older versions, and compare different versions. The user interface also 'hides' the com- plexities of versions for those who wish to use the system as a simple wordprocessor, yet makes the facilities readily available to those who know how to use the full power of the system.

3. Issues for collaborative writing support

From examining the above, and other, systems, a number of issues can be highlighted as requirements in a comprehensive co-authoring tool. Research on the writing process itself and managerial decision-making and conflict negotiations


have also led us to consider some other issues. We intend to address both these sets of issues with CollaborWriter, some of which are:

3.1. TEXT PROCESSING CONTROLS

Most of the current systems generally have poor typographic, formatting and document processing controls available for the author to use - features which authors now expect from their traditional wordprocessors. This is partially due to the fact that the systems are often research prototypes where specific qualities of the collaborative process are being examined, and are not designed to be fully- functional commercial applications. The GroupWriter system overcomes this problem, using a commercial wordprocessing engine as its core element. Those systems based on hypertext structures generally have limited formatting facilities, with only simple text entry into a node.

3.2. FREE-FLOWING TEXT

Due to the link-node structure inherent in hypertext system design, the reading of a document can be very disjoint as various links are traversed to find the body of the text. The systems are also normally tailored to support either browsing or authoring, not both (Halasz 1988). Graphs can also become large and unwieldy for the display of large documents, although graph layout programs using graph trees, indentation, or nested set notation, along with the suppression of subtree details, can help (Feiner 1988).

3.3. STANDARDISED DOCUMENT FILE PROTOCOLS

A problem with wordprocessors in general, and not just with collaborative authoring tools, is that each system uses its own format for storing the document text on disk. This document file structure normally does not map onto the actual document structure, nor is it compatible with other wordprocessing systems. Some common formats have been introduced, such as RTF (Rich Text Format), to ease this problem. These languages, however, are so simplistic that they do not contain any information about the styles and structure used in a document, only being concerned that the document looks the same between one computer system and another.

A document structure language, such as SGML, assumes the opposite role. It is primarily concerned with the structuring rather than the formatting of documents. This allows each author to keep their own specific formatting view of a document, with the underlying document structure remaining consistent between all authors.


3.4. RESOLVING CONFLICTS AND GROUP AWARENESS

The joint authoring systems currently available seem to take a generally vague view regarding conflicts which arise in the production of a document. Most systems either disallow one author to change an area being worked on by another, displaying an appropriate message, or create a new document version whenever a conflict arises. These systems do not seem to help rebind these versions together, mostly leaving the human authors to decide which versions of the document should be kept. This approach assumes that the co-authors are all working together harmoniously on the project, an assumption we believe cannot be supported for many creative collaborations. We regard the conflicts which occur to be a major part of any collaborative effort, and that some computer-assisted negotiation element is central to the co-authoring tool.

Much of the conflict which may arise is, however, often due to a lack of awareness amongst the group members. Ideally each member should be able to consider the content and character of individual contributions with respect to the whole group and its goals, through either explicitly generated or passively col- lected mechanisms (Dourish and BeUotti 1992).

3.5. COGNITIVE MODELS OF WRITING

Few of the systems take account of the cognitive aspects of writing (Sharpies and Pemberton 1988, 1990). Writing itself is a very ill-defined and under-constrained activity, with writers needing as much help as they can get. The writing process also takes on various forms at different stages. At one point a brainstorming session may occur, while at the next a review or layout decision is being made. A collaborative system must be able to harmoniously switch into these different modes without extra effort on the part of each author.

3.6. EASE OF USE AND TAILORABILITY

Systems should be easy to use, being presented in the format most pleasing to each individual author. Authors should not need to worry about specific typeset- ting or typographic conventions (e.g. 1" margins, headings in 14pt Bold Times Roman), these decisions being made by the group as a whole, or the publisher, in the document binding and distribution stage. Each author should simply be concerned with the overall structure of the document, namely the chapter, section, and sub-section format of the work. The system should also have all of the writing aids available as in a traditional wordprocessor, such as spelling checkers, the- saurus, and grammatical checkers. In all, the system should be no harder to use than its single-user counterpart, otherwise the system is likely to fail (Grudin 1991).


3.7. REUSABILITY

Parts of the document should be able to be reused. The same body of material could be used as part of a textbook, a scientific paper, a memo, or other format, with no changes to the body actually needing to be made by the authors. Auto- matic document binding (the layout of page numbers, titles, footnotes, contents pages etc.) should also occur depending on the type of format chosen. This helps avoid unnecessary repetition of work by the author.

3.8. DOCUMENT VERSIONS

No part of the document should be deleted. If there are multiple versions of a document, all these versions should be kept so that it can then be 'rolled back' if required at a later date. An author, unless given specific privileges to do so, should not be able to change another's work directly - if a change is made by another, a new version should be created. Small changes, such as a word or sen- tence, may be able to be merged without a new version being created. If this is the case, however, the most important aspect is making sure that all of the authors are viewing the most up-to-date version of a document.

3.9. INTELLIGENT AGENTS

Intelligent autonomous agents should form part of any collaborative system, primarily being used to deflect from any extra workload a user may have had to face in using the system. These agents could each have different responsibilities in the system. One agent could be responsible for checking the spelling of words, while another agent informed users whenever possible conflicts were about to arise. Other agents could tell an author to stop using the machine for a while and to exercise his/her wrists and hands, or act as a neutral party in any computer- assisted meetings. Further roles for intelligent agents are discussed below.

4. Document structures

Since 1986 many papers have shown how documents should be defined and mod- elled as logical hierarchial structures (Coombs et al. 1987). Figure 1 below shows a simplified logical structure for a book, with a series of more detailed structures given in Bryan (1988). This structure depicts a document of consisting of some front matter (title page, contents page, etc.), a main body, and some back matter (index, references, etc.). The main body is divided into a number of chapters, sections and subsections.


Different parts of this structure can then be assigned to various authors as part of the coordination stage of the writing process. Any possible conflicts between authors can thus be identified immediately. For example, a conflict could arise between author A and author B, as both have the ability to change section 1.2. The project leader could also be in conflict with any, or all, of the authors. Each author could also have different access rights to other par ts of the document. Author A can read or comment on any part of the document while author B is only allowed to read any of chapter 1 and author C cannot look at any part of the document apart from that which was allocated to him.

We are using the models embodied in SGML, the Standard Generalized Markup Language (Goldfarb 1981, Coombs 1987, Bryan 1988), for defining how a document should be structured. SGML is a descriptive markup language, describing not how something should look on paper, but what it is meant to rep- resent. Quoted speech, for example, may be written as:

. .. and he exclaimed <q>Wait! I hear something! </q> before. . .

By using this descriptive form of markup, the quotation tags may be replaced by ,either single, double or inverted quotation marks at the formatting stage of the document. Another advantage is that the text and structure of the document can be transferred together in a single text file. SGML is also a widely recognised

~ r

" ~ Chapter 1 ~ ,~ Chapter 2 Chapter n

. . . . \~. I I

Section 1.1 Section 1.2 Section l.m ~, .~

I \ i

I r- : Subsection 1.2.1 Subsection 12.t

Op#onal structured/oyers I Heagilngs

I Partgrt~hs of text

I

I I Highlighted i~ra~e* Items in lisu

I lti#fli#ted #'ntses

4 - - - - - read

read & comment

read, write & comment

Fig. 1. A simplified document structure.


international standard (ISO 8879) and has AAP (Association of American Publishers) backing. As a result, the language is becoming used by an increasing number of professional authors.

Other advantages in using SGML are that the standard is truly international, it can map onto other languages, allows sub-documents to be created as part of one overall document, and supports the creation and existence of different forms of the same document. Thus the same block of text could be extracted to be used in either a text book or a journal article. The standard also includes various encryp- tion techniques ensuring that any text transmitted is secure.

In order to implement CollaborWriter we have found that a logical document structure, as given above, is essential to the coordination of the collaborative process. Parallels can also be made with the development of large software projects, which contain very similar problems to those in co-authoring, where different pro- grammers are given different procedures or modules to work on and not simply the whole program code.

5. CollaborWriter

CollaborWriter is being developed in order to address the issues outlined above. It is based around a model of collaborative writing put forward by Sharples and Pemberton. This model suggests that the joint writing process between authors consists of various stages when the authors work closely together, along with stages when the authors work very much apart. This process occurs whether the authors are collaborating closely in time and space, or asynchronously at a distance.

In close collaboration the authors will use many channels to support the coordination, communications, and negotiation phases, being rarely dependent on the computer-supported interface to facilitate these activities. These channels include not only verbal channels (direct speech and audio links) to convey specific content, emphasis and emotion but also visual channels (direct observation and video links) to carry more subtle messages, through body language for example, or give direct indications, such as pointing to an area of the document. Much research has already been carried out in this area, mainly in the GDSS (Group Decision Support System) environment, a detailed review of which is given in Kraemer and King (1988). Where the collaboration is differentiated in space and time specific pro- vision must be made where possible to provide these alternative channels of communication.

CollaborWriter also builds on several established technologies. The management of multiple document versions draws on distributed database theories, while the manipulation of logical text structures is built around object-oriented and text processing technologies. Database theory is also used for backup, recovery and concurrency in a document. Transactions may take place over a long time, with


the database integrity being maintained whenever a document has been consolidated amongst the authors.

'3.1. COLLABORWRITER AND THE WRITING PROCESS

As mentioned above, CollaborWriter is built around a writing model presented by Sharples and Pemberton. They state that any writing software must support the writer's normal working practices, and must provide the writer with support of externalizing cognition - allowing writers to set down intermediate states of the writing task (notes, outlines, rough drafts etc.) They also point out that writers l:ake different approaches and strategies, and use different techniques for writing. A group writing tool should allow each individual author to plan and write their ]part of the work in whatever style and format they feel most suited to. Flower and Hayes (1981) studied writing as a problem-solving process and developed a cognitive model of the processes involved in a writing task, consisting of planning, l:ranslation and reviewing. We have extended this model to identify a number of stages in the writing process for multiple authors. These stages are coordination, 'writing and annotation, consolidation and negotiation. Figure 2 below shows the general writing process with these stages.

This is an iterative model which continues until the authors have all agreed on a final version of their work.

Writing and ~ ~

. . . . . . . . . ~ ~ ~ . ~ is i o i n e d r e s o l v e d a n d

�9 - ~ " ~ t o g e ~ e r a n d ~ e w o r k L#I_, Lg,,,C \ \ o ~ , , , . Q u o . , ~ I I . . . . i . . . . i . . . . . i ~ : , ~ ' i ; /

Fig. 2. The writing process between two authors.

5.1.1. Coordination

At the start of the writing process the authors meet to set out what the goals of the project are to be, how the work should be split up amongst each other, and actually delegate some work to be done by each of the authors.


5.1.2. Writing

The authors disperse and start work on their own topic areas. During this inde- pendent writing stage each author follows their own normal practices of varying between linear activities (the writing itself), creative activities (brainstorming) and editing activities. In a single author system these activities are usually covered with classic word processing functions supported by outlining and some form of notepad facility. At this stage the author may have no need to share or make public any local editing, corrections, outlines or ideas maps. In a collaborative environment, however, it may be preferable to support these activities at a group level.

5.1.3. Annotation

The public sharing of comments is normally handled in a distributed collaborative venture by annotation. Co-authors write comments on the shared document in order to draw the attention of the editor or the section's primary author to errors or suggested improvements (proof reading is a special case of this activity). These comments are typically added in a distinctive way, and are different in kind to direct corrections to the text. Some word processing systems have imple- mented this through red-lining, by attaching an electronic 'Post-It' note to the text (e.g. NoteCards), or through embedding spoken commands.

Reserved comments are comments which raise issues the annotator has the right to approve, or negotiate any change before withdrawing the objection. A reserved comment canbe completely withdrawn (deleted by its owner), transferred to the section owner it is addressed to, or demoted to a more specific section of the document. A non-reserved comment can be deleted by the section owner it was addressed to, or left as an aide memoire to be deleted during the next editing phase.

The use of annotation in the co-authoring process is important for supporting three different activities: �9 Notifying changes to the work of the same author which has already been con-

solidated into the current version and cannot thus be arbitrarily changed, even by the original author.

�9 Adding non-reserved comments to another author's text for making suggestions or pointing out errors. In general the annotator is happy to leave the author to decide if and how he/she takes note of the comments.

�9 Notifying other authors of a possible objection or conflict to part of a text through reserved comments. This raises issues linked with the negotiation stage, such as the annotator having the right to approve or negotiate any change before withdrawing the objection.

Directed Messages, as used in Quilt, can also be used for sending private messages or notes between two authors. Broadcast messages may also be appropriate for sending general messages to a group or all of the authors. These could be


used for stating an author's intentions (such as "I 'm working on section 2 about l~he state of the nation") to help add to group awareness or as a means of using the system as a simplified teleconferencing facility.

Whereas, in an ideal situation, all authors have the fight to read any part of a document under preparation, in some applications it may be necessary to restrict access. These restrictions may be for security reasons or for performance reasons (helping reduce communications traffic or reducing the number of replicated copies of a document). The main types of access we have identified are: no access, read access, read and comment access, and full access (read, write and comment). These access rights can be either positive or negative (Shen and Dewan 1992), such as giving a group read ;access to all of a document section, or restricting a specific author from access to ,certain parts of the document. If authors can see what each colleague is doing, how- ,ever, there is a reduced problem of writing cross-over conflicts. Authors can also give suggestions to others, and use their colleagues' work for stimulating their own ideas.

.5.1.4. Consolidation

If the work allocated during the coordination stage is simply defined then there can be no structural conflict arising at the consolidation stage. Structural conflicts occur whenever authors are permitted overlapping access rights to various sections of the ,document. Figure 1 above showed an example of this, where authors A and B could both come into conflict over the writing of section 1.2. The situation where both authors write the same section should be reduced, with CollaborWriter automatically informing both authors of a possible conflict once any changes have been made to the section in question, using either directed messages, facsimile, or some other :method to inform the appropriate authors. If two versions of the same section are present, however, the system will regard author B's text as the main version as B is the prime author of the section. All of author A's text for that section is made into an annotation and attached to B's section, the conflict being then carried forward to the negotiation stage.

Other conflicts which can arise relate to annotations being made to an author's piece by a colleague who believes that author's piece to be incorrect in some way, or who suggests some alternative to the piece. These conflicts are not as involved as the structural conflict mentioned above, and are often solved by directed messages between the two authors before the consolidation stage is reached. If there is a conflict, ihowever, the annotation is kept and also carried forward to the negotiation stage.

.5.1.5. Negotiation

The negotiation stage aims to defuse any reserved comments or conflicts which ihave been identified and carried forward from the consolidation stage. In general,


once detected any conflict should be resolved before a new working version of the document can be endorsed. This implies some form of negotiation activity must be supported by any collaborative writing environment.

The negotiation process in a face-to-face system involves the ability to make comments or suggest changes, to argue those changes, and if appropriate to vote on those changes. These activities must also be supported by the collaborative writing environment. Much of the negotiation process can be supported in the annotation and consolidation stages already discussed, with only specific conflicts passed to the negotiation stage.

In managing the negotiation process CollaborWriter uses various computer- assisted negotiation techniques, such as those found in the design of Negotiation Support Systems (Holsapple et al. 1990). The techniques used can relate to author seniority, a neutral arbitrator, section or project leader, or an editorial board (for voting). CollaborWriter then logs the negotiated settlement and updates the document so that any discrepancies are removed, such as annotated changes which are now discarded.

CollaborWriter uses various collaborative aids, forming a negotiation window (see Levels of Communication below), in the negotiation process. These tools include a text editor to allow authors to work and comment synchronously on the same parts of text, an electronic chalkboard for general notes and outlines, and directed and broadcast messages for creating a basic teleconferencing facility.

5.1.6. Coordination

After any conflicts have been resolved a new version of the working document is agreed. In some cases it may be agreed, in order to progress the work, that a particular conflict be 'put on ice' and resolved later. Such a reserved position may have a consequence for later work, and proxies may have to be created so that subsequent work may be able to reference the result of a negotiation, with such references being resolved when the negotiations are concluded. The next allocation of work, which may include authors taking into account comments of colleagues and revising existing work, is then made. The authors then revert to writing and annotating the new version of the document. The process repeats until the authors are sufficiently satisfied with their work for it to be submitted for publishing.

5.2. LEVELS OF COMMUNICATION

To manage the different modes of communication mentioned above (direct messages, annotation/commenting, writing/authoring and negotiation) CollaborWriter requires four main output windows. These windows consist of the document window, which can be edited directly by the permitted author, a transparent anno-


tation window on which comments can be posted by other authors, a communication window for direct correspondence between the authors, and a negotiation chalkboard window on which arguments can be made and agreements negotiated. Figure 3 below shows how these windows interact with each other and between two authors.

A set of author roles have to be defined in order to support the concepts of a structured logical document and the different modes of communication in the writing process. An author can take on one or more of these roles. For any logical unit in a document, there is: �9 One Owner. When authorship is an issue, the Owner has executive editorial

power over the contents of a section. �9 One or more sub-authors, who are entitled to edit the section. �9 One or more annotators, who are entitled to make comments on the section. �9 One or more mediators, who are entitled to participate in the negotiations con-

cerning the section. The system knows for each node what each author can perform there, and automatically switches to that mode when the author enters it. Specialised rights for a role can, however, be negotiated with the rest of the group if an annotator, say, prefers to write over a block of text rather than simply comment on it. As author roles are often fluid, one author can pass specific privileges to another, similar to a ticket (Turoff 1991).

During the different writing stages there will be different levels of access to each of the windows. In the coordination phase access rights can be manipulated, with the negotiation window being used to record allocations and agreements about the partitioning of the work. During the writing and annotation phase, both the document and annotation windows can be written to, the negotiation window being frozen as a record of the previous round of negotiations - a new instance of the window can, however, be created for use as a scratchpad for each individual author. At the consolidation phase only the automatic consolidation of unambigu- ous parts of the document takes place.

Commenting

Authoring Authoring + +

Communication Window

Negotiation Window

Annotation Window

Document Window

Fig. 3. The main communication windows in CollaborWriter.


Finally, during the negotiation phase a new negotiation window is created for the collaborative use of each of the authors. The communication window is always available as a form of electronic mail between any of the authors. The most involved of the windows is the negotiation window. This window displays comments, arguments and positions for those people involved in the negotiation. The negotiation window actually refers to a hierarchy of windows, ranging from general to specific conflicts, spanning the whole document. CollaborWriter deals with the most general comments first and, as these are resolved, then encourages the reso- lution of lower level comments. This top-down approach to negotiation is used because general comments are most likely to affect the whole document, possibly causing specific comments to be nullified. For example, if a general comment saying that section 3 should be removed is agreed on then any specific comments relating to the text of section 3 become irrelevant. In the consolidation stage, however, a bottom-up approach is adopted so that as much as possible of the document can be joined together into a consolidated version.

Intelligent agents communicate via direct messages and annotation in the communications and annotation windows. The Consolidator is one such agent which is invoked at a particular stage or at an agreed time when consolidation conflicts arise, communicating with the parties concerned through directed messages. Other agents may have daemon functions for continuously scanning text for particular aspects, leaving behind annotations where appropriate.

6. Current and Future Work

Our development work to this stage has been primarily concerned with the textual structuring of documents (McAlpine 1991). We are now starting to develop a prototype authoring tool to encompass the structural text elements linked with the collaborative process. Once this has been developed we can see how our theories on negotiation and consolidation relate, along with assessing the utility of the system. Work, however, needs to be done on the user-interface of the system, and how the various author windows interact with each individual author and with the group as a whole. Work especially on the user-interface for large numbers of par- ticipants working synchronously needs to be done, to help avoid screen-clutter and information overload amongst users.

The system is based around an object-oriented database engine, with object types defined for both the various text elements (chapter, list, figure, paragraph etc.) and the collaborators involved in the writing process (project leader, author, reviewer etc.). It is still in the early design stage, where we are looking at how best to link together the synchronous and asynchronous activities of the authors involved in a project, and the interface required to provide a seamless link to multiple versions of a document.


Other peripheral programs have also to be developed, namely the chalkboard system for brainstorming activities and a text editor which can support synchronous changes, which should evolve from the chalkboard system.

In designing CollaborWriter we have identified the distinct functionality required by a tool to support collaborative but dispersed authoring. We have attempted to meet these requirements by drawing on research in the areas of cooperative working, negotiation support, cognitive science, distributed databases, and human- computer interface design.

Acknowledgements

We thank the referees of this paper for making many useful comments to help improve its content and quality. Thanks also go to the members of the Information Systems Research Group at Aston for many informative and enlight- ening discussions on the subject. Keith McAlpine's work is sponsored by a research grant from the Department of Education for Northern Ireland.

References

Bryan, M. (1988): SGML: An Author's Guide to the Standard Generalized Markup Language. Addison-Wesley Publishing.

Coombs, J. H., Renear, A. H. and DeRose, S. J. (1987): Markup systems and the future of scholarly text processing. Communications of the ACM, vol. 30, no. 11, pp. 933-947.

Dourish, P. and Bellotti, V. (1992): Awareness and Coordination in Shared Workspaces. In Proceedings of the Fourth Conference on Computer-Supported Cooperative Work. Toronto, Canada, pp. 107-114.

Feiner, S. (1988): Seeing the Forest for the Trees: Hierarchical Display of Hypertext Structure. In Proceedings of the Conference on Office Information Systems. Palo Alto, California, pp. 205-212.

Fish, R. S., Kraut, R. E. and Leland, M. D. P. (1988): Quilt: A collaborative tool for cooperative writing. In Proceedings of the Conference on Office Information Systems. Palo Alto, California, pp. 30-37.

Flower, L. S. and Hayes, J. R. (1981): A cognitive theory process of writing. College Composition and Communication, vol. 34, no. 4, pp. 365-387.

Goldfarb, C. F. (1981): A generalized approach to document markup. In Proceedings of the ACM SIGPLAN- SIGOA Symposium on Text Manipulation. Portland, Oregon, pp. 68-73.

Haake, J. M. and Wilson, B. (1992): Supporting Collaborative Writing of Hyperdocuments in SEPIA. In Proceed- ings of the Fourth Conference on Computer-Supported Cooperative Work. Toronto, Canada, pp. 138 -146.

Halasz, F. (1988): Reflections on NoteCards: Seven issues for the next generation of hypermedia systems. Communications oftheACM, vol. 31, no.7, pp. 836-852.

Holsapple, C. W., Lai, H. and Whinston, A. B. (1990): A Formal Basis for Negotiation Support System Research. Kentucky Initiative for Knowledge Management Paper 25. University of Kentucky.

Kraemer, K. L. and King, J. L. (1988): Computer-Based Systems for Cooperative Work and Group Decision Making. ACM Computing Surveys, vol. 20, no. 2, pp. 146.

Leland, M. D. P., Fish, R. S. and Kraut, R. E. (1988): Collaborative document preparation using Quilt. In Proceed- ings of the Second Conference on Computer-Supported Cooperative Work. Portland, Oregon, pp. 206-215.

McAIpine, K. (1991) FineForm: A document structuring tool. Final Year Project Report, Department of Computer Science and Applied Mathematics, The University of Aston.

Malcolm, N. and Gaines, B. R. (199t): A minimalist approach to the development of a word processor supporting group writing activities. In Proceedings of the Conference on Organizational Computing Systems. Atlanta, Georgia, pp. 147-152.

174 KE|TH McALPINE & PAUL GOLDER

Neuwirth, C. M., Kaufer, D. S., Chandhok, R. ~ind Morris, J. J. (1990): Issues in the design of computer support for co-authoring and commenting. In Proceedings of the Third Conference on Computer-Supported Coo- perative Work. Los Angeles, California, pp. 183-195.

Olson, G. M. and Olson, J. S. (1991 ): User-Centered Design of Collaboration Technology. Journal of Organi- zational Computing, vol. 1, no. 1, pp. 61-83.

Sharpies, M. and Pemberton, L. (1988): Representing writing: An account of the writing process with regard to the writer's external representations. Cognitive Science Research Paper CSRP 119, School of Cognitive Sciences, The University of Sussex.

Sharpies, M. and Pemberton, L. (1990): Starting from the writer guidelines for the design of user-centred document processors. Cognitive Science Research Paper CSRP 154, School of Cognitive Sciences, The University of Sussex.

Shen, H. and Dewan, P. (1992): Access Control for Collaborative Environments. In Proceedings of the Fourth Conference on Computer-Supported Cooperative Work. Toronto, Canada, pp. 51-58.

Trigg, R., Suchman, L. and Halasz, F. (1986): Supporting collaboration in NoteCards. In Proceedings of the Conference on Computer-Supported Cooperative Work. Austin, Texas, pp. 147-153.

Turoff, M. (1991 ): Computer-Mediated Communication Requirements for Group Support. Journal of Organi- zational Computing, vol. 1, no. 1, pp. 85-113.

V~imos, T. (1991): Cooperative Communication: Computerware and Humanware. Journal of Organizational Computing, vol. 1, no. I, pp. 115-123.

Documents

A new architecture for a collaborative authoring system