Collaborative writing is a task where several people need to plan, write and rewrite a report together. Some tasks of a group of writers require closer collaboration and face-to-face meetings, while during other activities the group members work individually, and the results are later combined. Typical tasks in a meeting where a report is planned include generating and structuring ideas, making decisions about the contents and writing style, and finally, delegating parts of the work.
The first phase of a writing project includes planning, preparing an outline and dividing work. It can be supported by group editors which provide a shared work space to the members of the planning group. We have studied groups of students who plan a report with the help of a group editor, ShrEdit (from the University of Michigan). Contrary to previous studies, the groups had to write the report they planned, and data was collected also after the planning meeting. Preliminary data analysis has indicated some of the difficulties the groups faced in the planning meeting and during writing.
Meeting behavior is analysed based on videotapes and the log that ShrEdit provides. The analysis shows that ShrEdit has an effect on how meetings are run, and groups find different ways of using it. A goal of this analysis is to find the breakdown situations where group members do not know what happened or why the tool did not work the way they had expected.
In the above figure a meeting held by Group 2 is analysed. The group consisted of six male students on three machines, and at the same moment usually only one writer was actively working on the document. Occasionally two or even three students were editing during the same second. As shown in the figure, the group is not critical on what gets accepted into the document: the percentage of written characters grows all the time, and nothing gets deleted. The most interesting part of the analysis is, however, finding the conflicts: a conflict occurs when a member tries to position his cursor into the document in a spot that has already been selected by another participant.
A conflict is always a breakdown in work, and the member has to focus on the tool and the group instead of the writing he was about to do. These conflicts are caused by the ShrEdit editor: it does not show where other writers have their cursors in the shared document. Thus, it does not provide collaborators with the information they would need to have. The number of such conflicts would have been decreased with better interface planning.
Support for group work would be needed throughout the project; for instance, most groups faced problems with incompatible writing tools when they tried to divide the work between group members. Especially difficult has been to transfer graphics from one platform to another.
In addition to the group editor study that is the Ph.Lic. work of Saila Ovaska, some student projects have worked in this area. Some plans were made to build a workflow application for meeting management using Lotus Notes, but the implementation work has not made progress. Of interest would also be to compare workflow products as tools for system developers.