In the construction of traditional systems it is very common to perform a task analysis prior to design. As Weigand [1994] makes clear, this is different in the case of computer supported cooperative work (CSCW) applications. With regard to collaborative writing and human-computer interfaces, the literature often does not cover more than so called shared display editors and What You See Is What I See (WYSIWIS) in synchronous, co-located environments (e.g., Ellis et. al. [1991]). In general, asynchronous and distributed co-authoring environments receive little attention. Perhaps these are thought to resemble interfaces of stand-alone single-user applications. However, I do not share this point of view.
According to Ellis et. al., the basic problem in CSCW applications is how to manage complexity: multiple users simply produce a higher level of activity as well as a greater degree of concurrency (i.e., in the same time changes take place in different parts of the group document) than single users. The interface should support this complex behaviour. Hellman [1992] has some interesting ideas to handle this complexity.
In the remainder of this subsection I will first pay attention to the interface with regard to the group task, then to the use of the interface in the communication process, and finally to means of support for the social experience of working in groups.
In my definition of a human-computer interface, I state that it must provide a shared context for action. The interface must at all time reflect the progress that is made in accomplishing a certain task. Therefore, it is essential that the common ground between human and application interface, the shared information, remains up to date. Accumulation of the common ground, called grounding by Clark and Brennan [1990], should be a highly interactive process between human and interface.
In my opinion, computer-mediated cooperative work merely requires an extension of the common ground from an individual and the system he uses, toward all members of the group, mediated through their respective computer systems. Thus, a shared context for action is created.
Computer systems should not be perceived as a tool but as a medium which is able to represent a number of tools. Using a computer to support human-human communication within a workgroup, requires the system to represent a new kind of tools (i.e., new design metaphors) Sørgaard [1988]. In case of The COOPerator, the directed connected graph depicts the group's common ground. Through COOPerator's human-computer interface, the group members alter the graph or the contents of certain nodes. Thus, the interface component of the hypertext system that forms the basis for The COOPerator is particularly important.
Communication is probably the most important factor in teamwork. Failures in communicating are liable to cause conflicts between members of the group or hamper the decision-making process. Therefore a very important job, as well as a tremendous challenge for the interface designer, is to mould the right means of communication given todays technical standards and constraints regarding multi media data types (i.e., the envisioned minimal configuration) and telecommunication capabilities.
The COOPerator is a co-authoring tool which supports remote, asynchronous (non real-time) interaction between the different members of a group.
Kraut et. al. [1992] discovered that when groups can choose the modality they use to communicate about a co-writing project, they are likely to choose a rich medium when they are planning and revising; they avoid face-to-face communication when they are drafting the manuscript. Thus, the human-computer interface designer must be concerned with both modeling the exchange of rich information as well as providing leaner channels for interaction. Exchanging rich information assumes forms of high touch communication (e.g., telephone and face-to-face conversations). However, it may be impossible to achieve information richness in communication in an environment that is characterised by non-real-time interaction which effectively hinders high touch conversation.
In the following paragraph, some ideas are presented that were useful for modeling communication in The COOPerator.
In my model of collaborative writing I mention support for annotations as one of the primary means of communication and coordination between group members. Preferably, this mechanism should be guided by context-sensitivity. For example, consider the difference between an author annotation and a private annotation. The former is sent as a mail message to the author of the document part it is linked to whereas the latter can only be read by its creator. It should be prevented for the author of a document part to create an author annotation since this would mean sending mail to himself. From within the context, it should be clear to him that this is not the right action to undertake. In practice, this option could be greyed out (i.e., appear faded).
Another important coordination and communication mechanism is support for roles. Within The COOPerator, three different roles are distinguished: an editor, authors, and others. Hellman gives some interesting possibilities to support tasks. In my opinion, these may be translated to roles. For instance, role descriptions may be presented in the form of a verbal legend which incorporates links to various objects mentioned in the legend. These legends may be used in order to answer the co-writers question: 'what are my privileges or rights regarding this document part'. Moreover, these privileges may be depicted as visual indicators (e.g., icons) that present this information in a form that requires less screen space, as is done in COOPerator's document facility. To handle the complexity in a cooperative working environment, Hellman suggests a map construct or index to orientate the user in the space of different descriptions. This kind of instrument presents information about the cooperative relations and the creation and use of document parts.
In our opinion, true co-writing is a social experience; the peer collaborators should have equal control over the document and within the interaction.
In a distributed task environment it is not unlikely for a group member to actually 'forget' that he is a member of a group. Weigand warns for the lack of involvement and solidarity in virtual groups. As a consequence, the system's interface has to make clear that anything a member does eventually influences the work of others. In effect, it is the task of the interface to represent or resemble the other team members through the medium computer. You might think of the human-computer interface as a counter-balance for thoughtless actions from individual group members. The interface offsets the user's actions against the interests of the entire group.
The role mechanism which was described in the previous paragraph may help to provide such a sense of group context. It can make clear to humans that they belong to a group, that they are not alone!
On the other hand, it might be necessary to stimulate individual group members when they do not contribute as much as the others. For example, an individual may have problems regarding the contributions of the others: do they take on their fair share? When this is not guaranteed, he may decide not to participate any further. Particularly in large groups, group process losses, like the just mentioned assurance problem, may occur yet remain unnoticed for a long time. Perhaps the human-computer interface should be constructed to avoid these situations.
Besides guarding the interests of the entire group, the interface in a cooperative work environment should protect the individual's work. Some sort of locking mechanism (e.g., as suggested by Miles et. al. [1993]) may prevent others from (partly) destroying the results of ones exertion, whether this is done intentionally or not.
In another section, on the human-computer interface of COOPerator's client application, these ideas will be put into practice.
Sjoerd Michels, Tilburg, The Netherlands.