|
V.C. Miles, J.C. McCarthy, A.J. Dix, M.D. Harrison, A.F. Monk
Abstract: This paper marks the first steps in the design of a group editing environment for synchronous and asynchronous collaborative document development. A model of cooperative work is presented and applied to the task of collaborative writing. This analysis assists in a review of literature on computer mediated communication and shared editor design, and in the formulation of design ideas for a group editing environment. The designs suggested can be seen as providing users with a range communication 'channels'.
Keywords: Cooperative work, collaborative writing, computer mediated communication, shared editors, communication channels, interface design.
The roots of computer supported cooperative work (CSCW) are in the observation a great deal of our daily activity involves some form of collaboration [Olson 1989]. Much of the early research in CSCW considered ways of supporting a general concept, that of cooperative work. More recently CSCW research has begun to focus on specific applications. Computer support for collaborative writing, particularly in the form of a shared editing environment, emphasizes a more task focussed approach to CSCW applications.
Collaborative writing involves two or more people working together to produce a document. It involves phases of writing and phases of communicating [Newman 1992,Beck 1993]. It also involves periods of synchronous activity, where the group works together at the same time, and periods of asynchronous activity, where group members work at different times. The diverse range of activities involved and the different modes of interaction (synchronous and asynchronous) make collaborative writing a particularly interesting domain for CSCW support. The CSCW literature discusses a number of shared editor applications which aim to support collaborative writing. It is interesting to note that many of these systems will support either synchronous or asynchronous interaction, but not both.
Work at York on CSCW has echoed the general pattern of CSCW research mentioned earlier. We began by looking at computer mediated communication, building the Conferencer as a 'generic' conferencing environment [McCarthy 1990,McCarthy 1991]. This work was valuable in clarifying our thoughts on CSCW. A natural progression, we felt, would be to attempt to support a more focussed task than conferencing. We chose to examine collaborative writing within the shared editor application domain. By focusing on shared editing, we are taking a narrow definition of collaborative writing. We concentrate on that part of the collaborative writing process which is concerned with the actual creation of text: 'putting pen to paper'. Our proposed shared editing environment does not aim to provide specific support for activities such as brainstorming, ideas organising and decision making, although these are important parts of the overall writing process. However, as this paper will show we did not deem it sufficient to design a shared text editor alone, but also considered the design of accompanying conversation spaces.
This paper then, marks the first steps in the design of our shared editor environment. We consider literature on collaborative writing, computer mediated communication and group editor applications to come up with some design ideas for our shared editor environment.
We start, in the next section, by touching on some of the issues surrounding collaborative writing, this is done with reference to a conceptual model of cooperative work. This section sets up the broad requirements for our shared editor environment. Sections 3 and 4, deconstruct the model into its component parts. These sections include discussion of designs for supporting computer mediated communication and group editing. Sections 3 and 4 see a move from the conceptual model to ideas for design. Section 5 attempts to reconstruct the model in the light of these design ideas. The paper concludes with a discussion section.
Figure 1. Conceptual Model of Cooperative Work.
Arrow (a) in the model of cooperative work refers to direct communication between participants. Direct communication implies that participants are aware of each other, and will address messages to their co-participant(s). Direct communication takes place in face-to-face interaction, for example, in informal conversation, formal meetings and so on. It can also be mediated, for example by telephone, or electronic messaging. Computer support for direct communication is often referred to as computer mediated communication (CMC). If we take the example of a group of people writing a document together, direct communication may include the communication of ideas about what to include in the document, how to go about the task, relevant expertise, comment and so on.
Successful direct communication implies the achievement of a common understanding between participants. This can be difficult, particularly when group members have a diversity of backgrounds. Different perspectives and different areas of expertise often mean different languages for addressing a problem [McCarthy 1991a]. Olson refers to this as a coordination cost [Olson 1989]. The complexity of the coordination problem is elucidated by Begeman, Cook, Ellis, Graf, Rein, Smith [1986]. in their analysis of meetings. This analysis itemises the variety of activities, information items, contexts, and goals which constitute a meeting. Only a subset of these items will be considered by each participant in a meeting. Clearly the nature of this subset will depend on the participant's background, and disparate backgrounds might be expected to result in ineffective meetings, as there may only be a small degree of overlap between subsets. Thus we see the importance of successful direct communication. If each participant can successfully communicate their perspective, a common understanding can be achieved, with each participant having some knowledge of how other's perspectives differ from their own.
Clark and Brennan [1991] maintain that it will be easier to reach a common understanding in face-to-face interaction, where a high degree of contextual information is available to participants. They maintain that in direct, face-to-face communication context is shared through: copresence; visibililty; audibility; cotemporality (where one person receives an utterance at roughly the same time as another produces it); simultaneity (where people can send and receive simultaneously) and sequentiality.
In the model of cooperative work, line (e) represents common understanding. Understanding need not only be an emergent property of direct communication, it may also be come from interaction through shared artifacts, discussed in the next section.
The model of cooperative work, in figure 1, includes a physical artifact. The (b) arrows represent each participant's interaction with the artifact. Interaction with a common artifact can take place synchronously, where participants work concurrently, or asynchronously, where participants work at different times. One shared artifact central to collaborative writing is the shared document. Posner et al.'s [1991] research into the group writing process, has suggested that participant's interaction with a document artifact will be characterised by periods of synchronous and asynchronous activity. They comment on the need groups have to change writing strategies at any time during a collaborative authoring project. Writing strategies identified include: a single person writing the document based on discussion with the group; a scribe in a group meeting; a division of labour, with different members of a group authoring different sections; and a group writing together. The division of labour strategy proved the most widely used.
In addition to each participant's interaction with the artifact, communication can take place through the artifact. One can think of this as indirect communication. In figure 1 indirect communication, through the artifact, is shown by the curved arrow, (c), which links participants and artifact. Imagine two authors sharing paper and pens to write a document. The text of the document, and annotations to it, acts as a means of communication, helping to establish the task in which they are engaged, and perhaps indicating to each participant the expertise, perspective, and/or role of the other. The style in which the text is writing is informative; as is the type of paper and pen. Cheap paper, and sketchy notes written in pencil indicate to participants an informal interaction. A carefully penned letter suggests something more polished. The orientation of the writing material between authors, is another form of communication. When one participant pushes the paper across the desk to his partner, the implicit message is, "it's your turn now". Pettersson [1989] has examined the communicative power of the shared artifact in her analysis of document reading within two intensive care units. She analysed the type, use and recognition of documents in the wards. She found that information can be transmitted through: the location of a document; its spatial layout; the appearance of a field, filled or unfilled; and the nature of the handwriting and the pen used to produce it.
In addition to interacting with and though the artifact, participants will use various means to refer to particular artifacts. This is illustrated by arrow (d) in figure 1. Clark and Brennan talk about the importance of mutually establishing references to artifacts [Clark 1991]. They maintain that many conversations focus on objects and their identities, and discuss several common techniques for establishing 'referential identity', that is, the mutual belief that addressees have correctly identified a referent. In fact-to-face conversation one such technique is 'indicative gesture', which highlights the importance of pointing, looking and touching as a means of grounding references.
Support for artifact sharing is another target for computerisation. Group editing applications, shared calendars and shared drawing tools all provide computer support for artifact sharing. Such applications will embody the characteristics of arrows b and c in figure 1. Participants will interact with the shared artifact, shown by arrows (b), and will communication indirectly through the shared artifact, shown by arrow (c).
Many of the shared editor applications implemented to date will support either synchronous or asynchronous interaction, but not both. Yet, Posner et al.'s analysis of the writing process suggests that a joint writing effort can last from several days to several years and groups are likely to adopt both synchronous or asynchronous modes at some time during a project. Our choice, then, is to design an editing environment that is capable of supporting synchronous and asynchronous group interaction. In so doing, the aim is to support different modes of writing. For example, support for synchronous interaction would allow group members to write together, at the same time: one of the writing strategies identified by Posner et al. Supporting asynchronous interaction will allow group members to follow the widely used division of labour strategy: each individual writer will be able to produce their part of the text, in their own time, using a single environment. Provision of support both both synchronous and asynchronous interaction is favoured by Posner and her colleagues. She writes,
"Technology needs to be flexible and permissive, allowing groups to change strategies... Smooth transitions should be supported between ... synchronous and asynchronous work by group members."For a more detailed look at synchronous and asynchronous collaborative writing see Baydere et al. in this volume.
When a shared editor is to support synchronous interaction only, then a designer can reply on face-to-face interaction, video and/or audio for direct communication between participants, arrow (b) in figure 1. When asynchronous interaction is also to be supported, then designers must consider other means of facilitating the group's direct communication. One (inexpensive) option is to use textual communication, that is, textual messages displayed at the workstation interface. Direct communication, therefore, is mediated by means of computer support for textual messaging. Other means of mediating asynchronous communication include asynchronous voice. Unfortunately we do not have the facilities to support this at York, so for practical reasons the choice is for textual messaging.
In terms of the conceptual model, we are suggesting that our group editing environment should provide support for both direct communication and work artifact interaction. We require text-based conversation space for direct communication, and shared editing facilities for interaction with and through the document artifact.
CSCW systems vary in approaches they take to structuring direct communication. There are two broadly differing approaches. On the one hand there are systems which enforce a dialogue structure, on the other hand there are systems which encourage users to structure their own conversation. Gibbs [1989] describes these approaches in terms of a "social versus software protocol". Miles, Johnson and McCarthy [1991] talk of 'local' and 'global' structuring. Local structuring is an emergent property of a particular interaction: global structuring is embedded at design time, and is enforced in the same way for every interaction.
Coordinator, an application designed to make clear the commitments of communicating partners, provides an example of a system which enforces a dialogue between its users. A central feature of Coordinator is its use of conversational templates, which are based on speech act theory. These templates define a rigid dialogue structure, which the system enforces. Thus, when a user opens a 'conversation for action' with another user, he is able to predict a closure of some kind, because this is defined within the template. User testing revealed a negative reaction towards Coordinator []. Carasik and Grantham blame this in part on the rigidity of the conversational structure. For example, they argue that it may be the norm within a task-oriented group that only certain statements need a response, yet Coordinator required an explicit response, violating interaction norms. This suggests a lack of context sensitivity. Given a certain relationship between participants there may be no need for the intermediate steps in a 'conversation for action', one utterance might be sufficient to make a number of speech acts. Coordinator's enforced structure limits participants' potential for novel intervention. To that extent, it is an unnecessary constraint on the group process, since it limits the options available for solving the problem under consideration. Carasik and Grantham's evaluation is that,
"The conversational templates appeared to be more a straight-jacket than a communications medium." [Carasik 1988]).
Work on the Amsterdam Conversation Environment (ACE) contrasts greatly with the approach taken with Coordinator. Designers of the ACE system [Dykstra 1991] adhere to the principle that users rather than the system should structure communication. ACE is designed for synchronous use only, and aims to support conversation and stimulate interaction among group members. The support that is available is for the expression and preservation of people's views, rather than enforcement of a dialogue structure. Hypertext, provides the means by which exchanges can be recorded. Designers of ACE are scornful of systems that "institutionalise a conversation space". They maintain that system enforcement of formalised methods of conversation leads to bureaucracy, and rules that stop conversation.
In terms of a conversation space for our proposed group editing environment, allowing user structuring and hypertext support for conversation may present problems for asynchronous users. The non-linearity inherent in hypertext may make it difficult for asynchronous users to follow a previous conversation. In other words the relationship between a piece of text and its context may be lost. Our earlier discussion of direct communication indicated that context can play a significant role in situating text. When the context of a text is unclear there is potential for that text to be misunderstood. Indeed, Conklin and Begeman, in their examination of linear versus non-linear text, found that the non-linearity of hypertext meant that users found it difficult to follow the thread of a writer's thoughts as it wound through several nodes. They suggest that,
"...traditional linear text provides a continuous, unwinding thread of context as ideas are proposed and discussed".
Lying somewhere between the rigid dialogue structuring of Coordinator, and the fluidity of conversation permitted by ACE, are systems, such as the Information LENS system [Malone 1987], which support semi-structured messages. LENS presents users with a range of semi-structured message types which they can use for information sharing. The writer is aided in structuring a complete message without any constraint on expressivity, while the reader is provided with a recognisable structure that facilitates efficient search and comprehension. Semi-structured messages can be an effective means of establishing the context of a textual message [McCarthy 1991]. This is an important consideration, since LENS is designed for asynchronous use, where the time lag between messages can lead to the relationship between the text and its context being lost. The message templates in LENS and the message frames used in KMS [Yoder 1989] provide information about the subject matter of the message, the identity of participants in the conversation, and so on. In both cases the template or frame surrounds the text of the message. In effect, the message is embedded within its context border.
Semi-structured messaging systems may not be suitable for synchronous use. Message templates must be explicitly filled before the information is shared. It may take some time to complete a template, slowing the pace of interaction. Designers of some synchronous systems, view the grain of text transmission inherent in semi-structured messages as too coarse for their needs. Fine grain updating may present valuable contextual information to users, allowing them to review the text as it is generated.
The importance of the grain of message sending is highlighted by Tatar et al. [ 1991], in their discussion of the development of Colab's Cognoter tool. Cognoter, a shared whiteboard for idea organisation [Stefik 1987] was initially developed to include private edit windows. Users of the Cognoter whiteboard could create an individual item using these private edit windows. When completed, an icon consisting of the first twenty characters of the item was created and placed in the Cognoter window. Once there, any user could change or add to any item by opening a private edit window on it. The private editing windows had an 'aggregating' [Johnson 1990] function, collecting chunks of text before transmission. Studying users' reactions to Cognoter, Tatar et al. found that groups were frustrated by the lack of transparency afforded by the whiteboard. Colab's What You See Is What I See (WYSIWIS) principle had been relaxed [Stefik 1987] to such a degree that the group process was being hampered. Users wanted a finer grain of message transmission than the private windows would allow. Cognoter was redeveloped as a consequence. The redesign featured a much finer grain transmission achieved by updating every few characters.
This review of CSCW systems which support text-mediated direct communication, highlights some of the issues and trade-offs designers must consider. Should the designer support the enforcement of a dialogue structure, or should users be encouraged to structure their own interaction? The rigid system enforced structure in Coordinator presents users with a ready knowledge of the thread of a conversation, but places unnecessary constraints on expression. Non-linear representation of participant structured conversation may present difficulties for the asynchronous user, who may be unable to reestablish the context of the text. Semi-structured messages provide an alternative, preserving and presenting the text and its context. However, in synchronous interaction, explicit completion of semi-structured messages may slow the pace of the conversation, and remove the important contextual information inherent in being able to see the emergent text.
Figure 2. Some Conversation Space Design Ideas.
Figure 2 illustrates some of the conversation space design ideas put forward in this section. These design ideas can be seen as striking a balance between system enfored structure, and user structuring. A conversation space includes some system enforced structuring, in that a sequential, linear transcript is maintained. However, by giving users a choice of grain-size for message sending we are supporting a degree of flexibility in the interaction.
The earlier review of computer support for direct communication discussed the issue of structure. It was suggested that structure can be system enforced or user defined. A similar dichotomy can be seen from a review of some existing shared editor applications, and the approaches they take to structuring the collaborative authoring task. There are applications which use a model of a document to enforce a structure. Others apply a system enforced structure based on roles within the joint authoring task. Others again impose minimal constraint on users, allowing them to structure their own work.
Lubich and Plattner [1990] describe a system embedded, document model approach to structuring a shared editor. Lubich and Plattner are involved in the multimETH project, working on the design of a multi-media conferencing and collaborative authoring system. The aim is support the collaborative creation, editing and management of multi-media documents. To this end, use of a formal document model has been proposed, which consists of a number of hierarchically related 'structure elements', for example title, headlines, chapters, sections etc. Each of these 'structure elements' has a 'content portion', for example, text, graphics, bitmap, etc. The document itself is represented in a shared work space, the associated document model is shown as a logical tree structure in another window. By clicking on a node in the tree structure and issuing the 'lock' command, the user reserves a complete subtree, or a content portion within that subtree, for exclusive write access.
The approach taken by Beaudouin-Lafon [1990] is similar to that used in multimETH, in that the document is given a certain structure. The emphasis of Beaudouin-Lafon's work is on support for collaborative software development, so the shared document might be a program file. A key issue is version control for collaborative software development. A document is defined as a hierarchy of fragments. Fragmentation is usually performed automatically by the system, following a predefined set of fragmentation rules. Each fragment can have an arbitrary number of versions. These versions are embedded in the document, rather than kept externally. When users open a document they can select a version for display according to the context. For example, users can choose to see the original version of the document, or the version held by a particular user, or their own version. Rule based fragmentation of a document would appear to be particularly well suited to a program file where component procedures are built to follow a regular pattern. Beaudouin-Lafon's work highlights the importance of version control, which, he suggests, is an issue many other shared editing applications ignore.
Having a system enforced document model means that users are presented with a recognisable and consistent structure. Use in MultimETH of a logical document tree provides a concise representation of the document. This could be particularly useful for asynchronous users, who will be able to establish the current state of a document from its graphical representation. A document tree structure also provides participants with a ready means of establishing a referent within a document. Users can point to a node on the tree rather than the document itself. A document model approach to structuring a shared editor can be seen as an object oriented approach. The components of a document model can be viewed as objects, with certain attributes attached to them.
One concern with the document model approach is that rigid system enforcement of a model might hinder the group writing process, particularly the initial stages. Conklin and Begeman [1989] discuss the early stages of the individual's writing process. They maintain that,
"...the early phase of consideration of a writing or design problem is critical and fragile, and must be allowed to proceed in a vague, contradictory, and incomplete form for as long as necessary."Analysis of the writing process by Sharples and Pemberton [1990] maintains that writing is "an open ended design task". They describe a writer as "under-constrained", facing an infinite number of possible texts that could fill his goal, and an infinite number of actions that he can take at any stage. It is not clear that system level enforcement of a highly structured document model would allow sufficient flexibility.
The document model in multimETH makes some use of social roles. When a document is created in the shared workspace the corresponding access rights must be declared by a chairman or the owner of the document. Similarly it is the role of the chairman or document owner to change access rights during a collaboration. Access rights are 'write', 'read' and 'annotate'. The Quilt application for asynchronous collaborative document production also makes use of system enforced social roles [Leland 1988,Fish 1988]. Each user of Quilt is assumed to have a specific role in regard to a particular document, for example, 'co-author', 'commenter', 'editor' and 'reader'. These roles combined with the chosen document style define access privileges to the document. Document styles are assigned to sections of text within the document. Setting the document style to 'exclusive' means only the author of a section can modify it; 'shared' means any co-author can modify any section; 'editor' ensures that only a designated editor can modify any section, and other authors must make submissions to the editor. Roles and style must be specifically defined at the beginning of a collaboration.
Role enforcement can be a useful means of structuring, and organising collaborative writing. The allocation of roles helps insure that activities are neither neglected nor unnecessarily duplicated. Knowledge of the their own and others' roles enables users to predict their responsibilities with the interaction. One contention, however is that role structure may not always be obvious at the beginning of a collaborative endevour. It may be an emergent property of the interaction. Neuwirth et al. [1990] make the point that 'premature' definition of roles can lead to undesirable consequences. They suggest that if, for example, authorship is denied at the outset, then this may reduce the motivation of someone who has been defined as 'non-author', and the person may be disinclined to contribute. Roles formed one element of Posner et al.'s writing process taxonomy. Their findings support the notion that roles change during a protracted interaction. They cite the example of groups whose members all started out with the intention of contributing. Later the group member with the least time to dedicate to the project, fell into a consultant role, and ceased to be an active writer. There may be a conflict between roles and control in a collaborative writing task. Roles in a collaborative writing task may not be accurately reflected when other relationships interfere. A supervisor and their student may both be defined as co-authors, but the relationship between them may make this declared equality hard to sustain.
The applications discussed so far enforce a structure, be it role or document model based, upon users. An alternative is to allow users to structure their own interaction by means of the emergent social protocols. The GROVE group editor [Ellis 1991,Ellis 1989] provides an example of an application which imposes minimal system constraint. The default in GROVE is a mode in which every user can see and edit any part of the shared document, and there is absolutely no locking while editing. Mode changes can be achieved by redefining the 'view' of some portion of the shared environment. A user can move from the default 'public' view to a 'private' view, where items can be accessed by that user only, or to a 'shared' view where items are accessible to an enumerated set of users. Studies of the use of GROVE provide evidence of social protocol mediation. Ellis et al. describe how users organised themselves to work in parallel; how they organised 'partitioned entry' where the group assigns particular members to refine or reorganise particular parts of the text and how the individuals avoided colliding with others working on a particular piece of text at a particular time.
ShrEdit, a shared text editor developed at the University of Michigan [Bellotti 1991], also enforces minimal system constraint. ShrEdit is a synchronous shared editing tool designed for use in face-to-face design meetings. Users can work simultaneously in any part of the document, although insertion points are locked, so that no two insertion points can be co-located. No continuous feedback is given to users to indicate the location of other users' editing activity, however users can elect to 'find' or 'track' other users to gain such information. Bellotti, Dourish and MacLean [1991] report users' reactions to ShrEdit. They gave eight groups of three co-located designers, three different design problems to solve using ShrEdit. Bellotti et al. were struck by the great diversity of ways in which ShrEdit was used. A number of design themes emerged from their analysis, including users' desires to know what people were doing and where. Users described "bumping into each other" because of the lack of user activity information. One group described constructing a tree representation of the texts they had created, permitting "a fairly quick address for where we were talking". In other words they were providing themselves with the means to make 'referential identity' easier.
GROVE and ShrEdit are both designed for synchronous use, they allow parallel editing and are characterised by fine grain (or no) locking, and rapid updating. Frequent updates minimise the divergence between different views on a text [Olson 1990], ensuring the each user sees the most up-to-date version of a shared document. Continuous updating can be thought of as a way of 'communicating through the artifact'. Participants in a synchronous interaction will be able to watch others' text as it is created. Fine grain text transmission mitigates against what Chafe [1986] cites as one of the advantages of written textual communication. Writers, he claims, can revise and polish their thoughts before communicating them; a facility not available to speakers whose second thoughts and revisions are laid bare before their audience. Providing private workspaces [Olson 1990] give users the option to this polishing and revision of their contributions before including them in the shared document. Olson et al. [1990]comment that many group editors provide this for free, in that they are embedded in multi-tasking environments where other windows are available for private work. Adopting this solution, however, would mean that important user activity information would be lost to other participants. Ellis et al. [1991] have considered the issue of private work, and suggest a novel means by which private user activity information can be denoted. They suggest that private user text editing activity can be shown in the form of a 'cloudburst'. Textual modifications are shown immediately to the person who initiates them, but are indicate on other users' screens by the appearance of 'clouds' over the original text. The position and size of a cloud indicates the approximate location and extent of the modification.
GROVE and ShrEdit are designed for synchronous use only. They do not attempt to support asynchronous interaction. In ShrEdit, for example, this means that no provision is made for recording the context of a text, for maintaining versions or for reviewing changes. The LENS and KMS asynchronous messaging system discussed earlier deliberately separate text and context, 'framing' the text within a context border. Users can re-establish the context of a message by referring to its border. We require our proposed group editor to support synchronous and asynchronous interaction. It is important, therefore, to consider firstly, the separation and recording of text and context, and then, the means by which asynchronous users are able to re-establish the context of a text. The document model discussed earlier lends itself well to the separation and reinstatement of text and context. Contextual information can be associated with document model 'objects'. For example, it would be possible to establish who wrote what text object; when it was written, whether it had be changed; by whom and when; whether there were assess privileges associated with it and so on.
This review of shared editing applications has once again shown up the various trade-offs that designers must consider. Rigid enforcement of roles or a document model may be too inflexible to encompass the range of techniques groups employ when writing together. Role enforcement, however, can help ensure that activities are not ignored or duplicated. A document model lends itself well to 'object' status, and is amenable to graphical representation. Single editor, multiple cursor systems with minimal system intervention allow users to structure their own interaction, but do not support asynchronous interaction.
Figure 3. Some Shared Editor Design Ideas.
Figure 3 illustrates some of the design ideas proposed. Once again, these ideas can be seen as combining elements of system enforced structuring and user define structure. We are keen that users structure their own document segmentation in a way that is agreeable to the group. We wish to provide a choice of private or public editing. However, a degree of system enforcement is inherent in the segment locking strategy proposed. Many of our design ideas focus on supporting the presentation of contextual information. An important consideration here, has been to present not only the current interaction state, but also a context history for asynchronous users.
The last two sections deconstructed the model of cooperative work introduced in section 2. First we looked at at computer support for direct communication between participants. This involved consideration of designs for a conversation space. Next we looked at interaction with and through the document artifact. This involved reviewing designs for shared editing.
In order to support asynchronous, as well as synchronous interaction, we need both conversation space and shared editing facilities in our shared editing environment. In this section we consider how to support the connectivity between these two communication spaces. We are broaching the subject of how to design an environment rather than its individual components. The aim is to consider how the system as a whole would function. In effect, what we want to do here, is to reconstruct the model of cooperative work, looking at the integration of conversation spaces and shared editor in a single environment.
Figure 4. Two Alternative Ideas for Establishing Referential Identity.
We began by introducing a model of cooperative work, and applying that model to the task of collaborative writing. Group writing involves direct communication between participants, and interaction with and through the document artifact. Group writing can be a protracted exercise and is amenable to both concurrent and asynchronous work. With these observations in mind, we proceeded by deconstructing the model of cooperative work into its component parts. First we considered direct communication and drew from the literature on computer mediated communication to propose some ideas for conversation space design. Next, we looked at interaction with, and indirect communication through the shared document. This involved a review of some of the literature on shared editing applications, and some ideas for shared editor design. One fundamental design issue, which affects both computer mediated communication systems and shared editing applications, concerns the approach to task structuring. One can identify two broadly differing approaches. Some systems are designed to enforce a particular structure, other encourage users to structure their own interaction.The design ideas that have been put forward for possible inclusion in our group editing environment reflect an attempt to strike a balance between these two approaches. An important design consideration has been the presentation of contextual information. One aim has been to present not only the current interaction state, but also a context history for asynchronous users.
By proposing that our group editing environment will have both conversation spaces and shared editing we are suggesting provision of a range of different 'channels' for different types of communication (for a similar classification see Crowcroft in this volume). For example a document segment will provide a task specific communication channel, while the global conversation space might be used as a channel for general procedural discussion. These 'channels' are not physical, in the sense of the visual, auditory and linguistic channels that are available in face-to-face communication. They can be thought of as 'virtual channels': these describe the communication media that participants perceive [McCarthy 1990]. Participants' perception of a communication channel will be influenced by its appearance, and the way they interact with it. Giving users a range of differently styled channels can increase the effectiveness of their communication. For example, when a channel is perceived as supporting a particular type of communication, then that channel will help to specify the intended meaning of messages received on it. Receiving related information on more than one channel can have a strengthening effect. For instance, seeing an annotation suggesting a change to a segment, and then seeing the change made to the text reinforces the intention. Provision of a range of channels also allows for deictic referencing, so users can refer to "this segment" or "that annotation". Deictic references can increase the efficiency of communication [McCarthy 1991b].
Having separated the model of cooperative work into its component parts, we then considered its reconstruction. The focus was on how to integrate conversation spaces and shared editing into a single environment. In conceptual terms the aim is to provide interrelated and complementary channels: interrelated in the sense that the relationship between the channels is made clear, complementary in the sense that different channels can mutually supply each other's lack. For example, document segments and segment annotations will be closely related, both concerned with a particular piece of text. The communication channels they provide will be complementary, with a document segment providing a channel for indirect communication through the document, and the annotations providing a channel of direct communication about the document. The hope is, that providing a range of complementary and interrelated channels, will help users to achieve the common understanding, ((e) in figure 1), that is central to successful cooperative work.
