GSS Collaboration in Document Development: Using ... - CiteSeerX

Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999

GSS Collaboration in Document Development: Using GroupWriter to Improve the Process Mark Adkins, Jeannette Q. Reinig, and John Kruse Center for the Management of Information University of Arizona Tucson AZ, 85721

Daniel Mittleman School of Computer Science Telecommunications & Information Systems DePaul University Chicago, IL,

Abstract Research was conducted on the application of GroupWriter, to support the development, editing, sharing, and modification of government documents. One of the major advantages of using GroupWriter is the support of collaborative writing and the manipulation of documents in a manner unconstrained by time and place. At this time various groups from government agencies and the University of Arizona’s Center for the Management of Information (CMI) are involved in GroupWriter sessions. Development of the tool has revealed the need for preset protocols, which explain the requirements, definitions, and uses pertaining to the system and software. Achievements were made in tailoring the technologies to fit the needs of specific groups. This paper will focus on the development of both facilitation processes and GroupWriter as a collaborative writing tool. Lessons learned in this area call for the reduction of system and process ambiguity to support both synchronous and asynchronous distributed users.

Introduction Collaboration has been defined as a process that requires support for more than the exchange and maintenance of information [5]. In order for collaboration to succeed, group members must establish a common perspective or context, maintain both formal and informal communication channels, and evolve rules for structured interaction while executing their task to completion. Collaborative writing research has been designed to advance our understanding of the evolution and development of how individuals learn to write together [12]. Collaborative writing requires negotiations between

persons in the group as to content and meaning of text [11]. Collaboration affects the allocation and distribution of attention as well as the common ground that is essential for a shared understanding by the group. Social dynamics are altered when using Group Support Systems (GSS) to promote collaborative writing. Studying the use of a collaborative writing tool provides the opportunity to observe the writing process, and reveals much about the special needs of writers. Collaborative writing is an arduous task. The tools used to facilitate such sessions must be simple and concise; there should be minimal complexity in learning to use the tool with no technological distractions. In collaborative writing, issues of group process, communication, and organizational policies are introduced into the mix. There are various strengths and weaknesses in conjunction with using a collaborative writing tool. The research approach focuses on how to collaboratively write; the collection and analysis of requirements for group writing software; review of research and commercial group writing products; design and testing of a Windows GroupWriter tool; and development of facilitation processes for use of the technology to support the group writing system.

Defining Group Support Systems (GSS) A GSS is a collection of different software tools, each of which focuses and structures group thinking, and affects group dynamics in a unique manner [14]. The system is typically based on a network of personal computers, usually one for each participant. A GSS enables a group to communicate simultaneously, anonymously, in parallel and in a structured manner. The contributions made by each

0-7695-0001-3/99 $10.00 (c) 1999 IEEE

1


participant are immediately available to the rest of the group. GroupSystems software is a component of GSS used with all GroupWriter sessions. At this time the installation of GroupSystems is required to gain access to the GroupWriter tool. Windows GroupWriter has been coded in Delphi on top of the GroupSystems for Windows GroupOutliner platform.

Strategies for Collaborative Writing Thompson (1967) described three types of teamwork strategies: pooled, sequential, and reciprocal. Sharples et al. [17] has built upon these three teamwork strategies to describe three strategies for collaborative writing: Generally, collaborative writing procedures will fall into one of the three categories.

Sequential writing Sequential group writing involves the collaborators dividing up the task so that the output of one stage is passed to the next writer for individual work. Because sequential writing is an asynchronous process, work already done acts as a constraint on future work. Each writer is guided by what has been done before. But the document does not explain why a writer has written certain text. The Sequential strategy is slow since each writer must wait for his/her turn for a chance to work on the document [8]. Additionally, the product is sensitive to poor performance by any one-writer [4].

Parallel writing Parallel group writing is where the collaborators divide up the task so that each writer is working on a different part of the document and

then the document is reassembled in an integration stage. Parallel work is divided into sub-tasks either by content (parts of the document) or process (editing, spell checking, formatting) that can be accomplished in parallel. This method is efficient, however, there is a need for the reconciliation of different versions. Writers must coordinate efforts and time schedules. The Parallel strategy is particularly appropriate for loosely coupled writing tasks requiring minimal interaction [17].

Reciprocal writing Reciprocal writing is where the collaborators work together to create a common document, mutually adjusting their activities in real time to take into account each other’s edits. Reciprocal strategy requires writers to work around a single document instance that is mutually available to all of them. Writers may check out copies of sections, make changes and then update the document. However, only one live document exists at any time. Writers may impose turn-taking (making it similar to sequential), or divide the task into content sections (making it similar to parallel) in order to provide structure to this strategy [17].

Strategy comparison The three strategies can be evaluated along four dimensions (Table 1). Scheduling is the assignment of tasks and deadlines, and the setting of process constraints. Coordination is required to deal with changes in the document. As one writer adjusts, other writers must be informed and adjust appropriately. The need for coordination is central to the process of co-writing documents [8]. Constraints are content, style, domain and process bounds by which all of the co-writers must adhere. Intentions are the basis or reasoning of each writer for the prose he/she has written.

Table 1. Characteristics of Strategies for Collaborative Writing Scheduling Parallel partitioning

Coordination Low

Constraints Plans, instructions

Sequential working

Sequential partitioning

Medium

Reciprocal working

Self-scheduling

High

Plans, instructions, draft text in document sequence Plans, instructions, draft text

Parallel working

0-7695-0001-3/99 $10.00 (c) 1999 IEEE

Intentions Communication between partners Communication between partners, annotations of text Communication, annotations of text

2


In parallel writing, scheduling is a matter of allocating tasks, setting completion time and merging the results. Each partner requires a welldefined subtask. The key stage of this strategy is in integrating the sections into a coherent whole. This melding stage requires facilitative guidance. Sharples [18] describes the role as “host”; Diaper [3] as “co-ordinator”. There is a low level of coordination requirements in parallel work as the strategy assigns out authority to the writers. In parallel, co-writers accept front-end constraints and then write within the bounds of those constraints. Intentions must be communicated among co-writers using a medium independent of the document to ensure timely communication. In sequential writing, there is no need for scheduling as each writer works until done. It might be necessary to determine sequence of writers and time limits, but there are no problems with synchronization. There is a moderate level of coordination required for sequential as when the current writer adjusts to externalities, his/her decision creates constraints for all subsequent writers [10]. Unless authority is delegated along with lease of the document, negotiation and resolution of new externalities must be coordinated. In sequential, writers are bound by both initially agreed to constraints plus previously written text. Intentions may be conveyed outside of the document or within the document through a metamessaging system. In reciprocal writing writers may attempt to edit the same piece of text simultaneously. The group process or software must govern this contention. Locking mechanisms can be used to manage this contention. As writers can edit any portion of the text, version control to monitor changes becomes an important component. Ellis [7] found that the ability to open up the document to any section was useful, but the group needed to generate a protocol to manage this strategy. A high degree of coordination is required as the influence of externalities on one co-writer can have immediate impact on the work of all other co-writers. As with parallel, intentions may be conveyed outside of the document or within the document through a metamessaging system.

synthesized process for conducting collaborative writing sessions emerged from experiences developing documents, manuals, pamphlets and regulations. As facilitators involved in collaborative writing sessions we have been able to identify the specific roles taken on by individual writers in collaborative writing sessions and develop a process which capitalizes on the benefits of using a GSS to support collaborative writing. At times, a single individual can undertake several roles in the collaborative writing process. The observed roles in our sessions follow: • Writer-person who drafts new material in a given section of the document. • Editor-person who can make changes to a given section. • Reviewer/Interpreter-person who read drafts and suggests improvements or amendments to a given document. • Leader/Facilitator-person who sets structures and pace for the documentation project. • Copy Editor/Typographer-person who takes group’s final draft and polishes it for publication. The roles group members undertook in the collaborative writing process were useful to provide structure, and yet they also added confusion to the process. Post-session interviews indicated that miscommunication between the facilitator and the group participants often led to a lack of understanding a particular role a writer had undertaken at a given time. For example, the behavior of the editor on a particular section may have been closer to the behavior of a writer. Thus, comments like “you didn’t edit my section, you rewrote it!” were often heard. The lesson from this experience was to build a role identification process into the meeting pre-plan. This way participant roles were clearer and mutually understood.

Requirements for Collaborative Writing

As the prototyping project began, several avenues of development and implementation were explored. In the end, a Delphi development environment was selected due to the availability of commercial off the shelf

CMI has worked on a number of collaborative writing projects with a variety of organizations. A

Development of a Windows GroupWriter

0-7695-0001-3/99 $10.00 (c) 1999 IEEE

3


[COTS] word processing components. These features provided for both basic word processing and a fully customizable and extensible environment. Windows GroupWriter Requirements From various organizational requirements previously compiled, and from CMI facilitation experience using collaborative writing tools such as DOS GroupWriter, a list of software design requirements was established. This list consisted of: • Editing Editing tasks will be undertaken at different levels. In a typical scenario, a sub-team will take the input from group outliner and do extensive editing and reorganization of the data that was imported. In the on-line feedback and discussion phase, there will be extensive editing suggestions provided through annotation and revision processes. These contributions will then have to be accepted, rejected or merged with the document text. During and after the verbal walk-through, final editing will be done to produce a finished document the group agrees on. If a participant is editing a section, others will not be able to edit it simultaneously. • Buttons The buttons available on the GroupWriter toolbar will be appropriate to the task at hand. In some phases, it will be important to minimize the functions available to participants in order to reduce complexity and keep the process focused. There will be buttons for creating new sections, merging sections and saving sections. Other features will be available from pull-down menu items. • Revisions Changes will be made in the document and will be marked explicitly as revisions. They can be accepted, rejected or merged later. • Annotations Annotations will be created using the annotation mechanism but an annotation button will be provided for participants. There will be buttons available for creating and viewing annotations. It will pop up a custom read-only window showing the document text with annotation markers and the annotations appearing as indented text after each paragraph. GroupWriter will have a button to put an annotation marker in the spot where the cursor is located. Whenever you are entering an annotation, you will be able to see the other nearest annotations. • Team Leader Controls There will be a team leader version of the document that is based upon a team leader template, which provides controls to configure the participant version of GroupWriter in use at a given time. This

will enable the team leader to focus the efforts of the participants throughout the process. The team leader will be able to control the set of buttons and menu items that are available to participants at a given time so that the process can remain focused on the current stage of document development. Some of the leader controls will be accessible using toolbar buttons and others will be accessible from pull-down menus. The leader will have control to open, save and delete a master document and sub documents. GroupWriter will have the ability to import from and export to GroupSystems and any Word Processing tool. The list presented above were initial requirements for the Windows GroupWriter prototype software, the final prototype produced contained a slightly modified feature set. Modifications occurred as a natural part of the prototyping process. As feature combinations were tried, some features were found to be unwarranted or counter productive. In addition, other necessary features were found to be under-specified. The final version of Windows GroupWriter contains a rich feature set. This list below specifies them and compares them to the DOS GroupWriter feature set. Documents may be divided into sections on a tree structure. This is a stepwise improvement over the DOS GroupWriter, which was limited to a linear list structure. The Table of contents window allows for easy navigation through the document. It also depicts the current holder of a section, and the time of the last edit to that section. The DOS software did not. The latter information remains available in the Windows software by consulting the version history. Writers can check out a section to write but can always read. This structure is identical to the DOS software. Sections can be updated on a time poll set as quickly as one second, or can be checked out and not updated until checked in (this is switchable at the writer’s discretion). This feature allows for two modes of use. If the section writer wishes to have others in the group follow his/her edits in real-time so that they can offer verbal feedback, the polling scheme can be set to automatically provide those updates. If, however, the section writer would like to carefully compose their prose before sharing them with the full group, the polling scheme can be disconnected and

0-7695-0001-3/99 $10.00 (c) 1999 IEEE

4


updates are only reported when the section writer saves his/her work. The latter scheme is the only option in the DOS GroupWriter. Read and write updates are on separate poll schemes. Separate update rules can be used for each. The two schemes are manual in the DOS version so there is no comparable feature. Windows GroupWriter contains an outline building facility to support the generation of the table of contents. Group members during the writing process can manipulate the table of contents. This is the same as in DOS however the user interface is significantly improved for Windows. Discussion of document content is handled through GroupSystems discussion tools. Output from those discussions can be imported into GroupWriter. The DOS tool did not have an effective discussion component. In DOS discussion either occurred by using annotations or discussion comments appearing directly in the document text. The latter solution was more common. There is a messaging system embedded in Windows GroupWriter to provide for facilitator communication - even in a distributed setting. There is no corresponding feature in the DOS GroupWriter. Consequently the Windows GroupWriter is better equipped for distributed work. Basic word processing features are available using a standard word processing interface. Keystroke shortcuts can be set to map to Word, WordPro, and/or WordPerfect to make the environment better map to systems familiar to the user. The Windows GroupWriter supports font manipulations, justifications, and paragraph formatting. There are no word processing formatting features available in the DOS GroupWriter; it is wholly an editing tool. There is an information bar at the bottom of the screen, which provides status of document information. There is no corresponding feature in the DOS GroupWriter. Documents may be saved using .RTF format as well as .TXT ASCII format supporting far more flexible formatting options. The DOS GroupWriter only handled ASCII text. Multi-media objects may be attached to the document. There is no comparable feature in the DOS GroupWriter. A spell checker is available. DOS GroupWriter has no comparable feature. There is a full document view feature. In DOS, the full document view was the default view. The editor follows standard Microsoft Windows GUI standards and therefore is easy to use for anyone familiar with Windows. The DOS GroupWriter used the GroupSystems standards,

which were not widely known. There is an undo feature in the Windows GroupWriter. In DOS, one could only undo through the version history. If a text had not been saved into history, it was not recoverable. It is now possible to print directly from Windows GroupWriter. There is a print preview feature to support this feature. In DOS the document was exported before it could be printed. There was no print preview feature. Windows GroupWriter Feature Set The GroupWriter application constantly evolves as research conducted with the tool reveals electronic collaboration breakthroughs. The past year found GroupWriter evolving to take better advantage of the common Windows interface. Upgrading from the DOS environment involved a shift, and GroupWriter is undergoing a transformation to extend Windows’ growing familiarity to the collaboration features. To this end, GroupWriter has evolved in the interface, features, and coding areas. • Interface As more and more groups have worked with GroupSystems and GroupWriter, the interface has changed to provide the design people are looking for. Existing features have been modified to make the interface overall more intuitive and easy to use. Identified annotations: Name and time appear together with the annotations; all of the identification properties of annotations which people look for are present in the text box along with the annotation:

The identification feature of the annotation can be toggled on and off, and a button has been included to easily copy the body text of annotation to the clipboard. Reverse version history: The Version History feature has been modified to provide

0-7695-0001-3/99 $10.00 (c) 1999 IEEE

5


the information in the reverse order to identify the most recent version(s) easily:

The Version History window provides the number, date and time of modification, and size of each version.

Facilitation Methods to Support Collaborative Writing GroupWriter and the platform software, GroupSystems support many collaborative writing processes. Listed below are six stages in which we use both software's. These technologies have been used applying synchronous and asynchronous methodologies. The distributed process will be discussed at the end of the synchronous process and we will point out what changes, if any were made. GroupSystems tools such as Categorizer and GroupOutliner will support the first three stages. GroupWriter will support the second three stages. The individual sections (sub documents) of the document will be developed by sub-teams or individuals using GroupWriter. On-line feedback and discussion of the details of the document will be handled using the annotation and revision features of GroupWriter. Once this evaluation and modification process is completed, there will be a verbal walk through by the entire group or by the document owners to produce a finished and publishable version of the document, manual, or pamphlet.

3. Discussion of content within outline interactive generation and discussion of document content in each section. This will make use of Group Outliner. 4. Composing by sub-teams - these sub-teams may consist of a few people or in some cases may be only one person. The task is to take the content entries from a section and organize, edit and complete the section as a first draft version. The work will be done in the GroupWriter tool with the data from stage 3. having been imported from GroupOutliner. 5. On-line feedback and discussion - using the GroupWriter tool, the document team will review each section and make suggestions in the form of annotations and revisions. The document, or section, owners will accept, reject or merge the suggestions. 6. Verbal walkthrough - using the GroupWriter tool, the project team will do a verbal walkthrough and the document owner will make any revisions needed to finish the document.

Open Discussion

Outline Document

Discuss Content Sub-team Composition Verbal Walkthru

On-line Feedback

Figure 1. Model of Facilitation Stages

GroupWriter Processes This process evolved into a rich set of rules and procedures.

Stages of Document Development 1. Open discussion - develop the objectives and general scope of the document. May use Electronic Brainstorming or Categorizer to support this process. 2. Generation of document outline - develop main sections and subsections that will provide the structure for the document. Will use Categorizer, Voting, and GroupOutliner.

1. Divergent discussion of issues which must be addressed by the document and

2. Organization of those issues into an outline form The first stage of the documentation process depended upon the degree of preparatory work that had been done prior to

0-7695-0001-3/99 $10.00 (c) 1999 IEEE

6


the group meeting. In the case where the group was meeting for the first time and was just beginning to devise the contents for the document, an Electronic Brainstorming session to surface ideas for document contents. The EBS session was followed by a Categorizer session where topics were proposed and relevant brainstorming comments were organized into buckets (categories). Additional structured discussion followed where participants suggested key information to be included in each section of the document. Participants were encouraged to cut relevant prose from existing external documents and paste into the discussion windows to seed the text for each section. These two stages required most of the first day of the meeting. The facilitators chose not to rush the group through this process as they wished to bring conflicts to the table and resolve them prior to drafting the document. By alternating between an interactive facilitation style for the initial brainstorming, a chauffeured facilitation style for the section generation and ordering, and then an interactive facilitation style again for gathering section information facilitators were able to break up any monotony of a repetitive process. In the case of the document where an entire draft had previously been written we immediately began with a GroupWriter session. Facilitators imported the previous document into GroupWriter and began reviewing the previous table of contents in the GroupOutliner format, which is the platform tool for GroupWriter. Using a chauffeured discussion the group modified the table of contents to reflect current thought about optimal document structure. Facilitators then opened the GroupWriter section in read-only mode for comments using annotations, for each section of the document. These two stages required three to five hours of group time. The time required was less for creating a new document simply because significant organizational work had previously been done which facilitators built upon. For the distributed process we required the participants to come together for steps 1 and 2 to increase the level of commitment and buy-in to the collaborative writing process. In the case where particular participants could not come together with the group, they were brought in via conference calls with their connections to GroupWriter and the document off the web. Using a CITRIX server to dial up to the DENIX (the Department of Defense’s Environmental Information Management System) website GroupWriter and GroupSystems are made available to various government agencies. Issues arose as to preset protocols. There were questions

as to section controls. How were the individual writers assigned to a particular section sure that another writer would not edit their work? Issues of trust and accountability were also prominent. 3. Drafting of text for each portion of the

outline Once the full group contributed thoughts, ideas and information by section in the parallel discussion session, we divided the full group up into working teams of two or three people each. In our first project facilitators began with teams of three, but they quickly found teams of two were better use of individual’s time. In the case of the new document, teams were to make use of existing documentation as well as the annotations made during the previous phase to sculpt an initial draft of the section. The output from the Categorizer discussion was imported into sections of a GroupWriter document. Each team was charged with turning the discussion text of their assigned section into a first draft of a coherent document. In the case of the previously existing document, the existing document was imported into GroupWriter in front of one team member and the GroupOutliner discussion remained on the screen in front of the other team member. Each team was charged with addressing the annotations made in the previous discussion by making changes in the existing document. Each team was assigned specific sections of the document (sub-chapters) to work on in GroupWriter. Assignments were made verbally and voluntarily with the facilitator acting as chauffeur at a whiteboard. However, when issue oriented conflicts between two participants were known a priori, the facilitator encouraged the two participants in conflict to address the document section in question as a team. This method was chosen to focus the conflict without distracting the rest of the group, and to allow the individual in conflict to negotiate out a solution without having to back off of a stated position in front of the entire group. Invariably, when the combatants returned to the full group in Stage 4 with a compromise solution, the rest of the group quickly accepted it. It was hypothesized that requiring participants to work in teams would prevent lone wolves from straying too far from the pack

0-7695-0001-3/99 $10.00 (c) 1999 IEEE

7


and including individual agendas in this draft of the document. The experience was that this strategy worked fairly well. The only failures in this regard were in teams where one individual had a much stronger personality than the teammate. However, the full group readily addressed those few situations in Stage 4. During the process of small teamwork the full group would occasionally verbally address issues brought to it by individual teams. Dyads and triads formed ad hoc to address questions which crossed borders among two or more teams or two or more areas of personal expertise. The process of creating initial drafts took about a full day of work for the new document and about a half day of work for the existing document. For the distributed participants, they were notified via email to the location of the document on the DENIX CITRIX Server website. The team leader invited the group into the GroupWriter session and gave them read-only access to the document. Participants were told which section/s to review and make annotations regarding revisions or comments. Team related issues were avoided and participants could access GroupWriter at their own convenience within a given time period. Time constraints consisted of a few days to a 24-hour period in which to access GroupWriter and make annotations. The issues arising with this method were the lack of control by the leader to provide help or direction for the participants. Some had questions about text or the software. These participants had to make phone calls or email the team leader (document owner) to ask questions and acquire assistance on software issues. This slowed the process.

4. Review and evaluation of the drafts Once a draft was complete, the full group reassembled to walk through the draft. The facilitator led the group through this process with the document appearing in front of each participant on their own screen in GroupWriter. The facilitator called upon the writers of each section to verbally present key issues from their work to the full group. The group addressed those issues verbally with one member of the presenting teams acting as a scribe in GroupWriter to either take notes or implement suggested changes to the document on the fly. The facilitator acted to keep the discussion focused and on topic. On the occasions where an impasse was reached regarding a specific issue, the facilitator guided the group to select an ad hoc team to address the issue subsequent to the draft walkthrough and report back at the next iteration. With these

guidelines decisions were usually made by consensus; only on the rare occasion was a vote taken. Commonly, once an issue was framed in precise terms in the document draft, individual participants with specific content expertise for that issue were able to explain to the full group the constraints regarding the issue in question. The walkthrough took the group about a halfday to complete for one of the documents, and about three-quarters of a day to complete for another document. Distributed participants were once again notified of the due dates for first drafts. Conference calls brought together group members with the facilitator. GroupWriter on the DENIX Website was utilized. As a group, they went through the document and pointed out key issues. A consensus on the first draft of the document was reached.

5. Refinement of the drafts After the initial walkthrough the teams were once again charged with addressing issues raised and further developing prose. At this point facilitators began to stress continuity in style for the full document. Teams revisited their work and cleaned up their initial prose. When appropriate, sections were merged or split (it was much more common to find several sections merged than a single section split.) On occasion ad hoc teams formed crossing the boundaries of the initial teams to pull together sections. In this stage most writing was done individually with teammates checking and editing each other’s work before reporting it back to the full group. This editing stage required less time than the initial editing stage. It ran from two to six hours across our projects. For stage 5 writers were asked to stress continuity on the entire document. The first draft was done in stage 4 and they were to follow and make annotations for any editing they felt necessary to other sections. Each writer was responsible for his/her section so that it would flow with the entire document.

6.

Additional review and evaluation with consensus emerging

Following the refinement of the drafts, the full group again assembled to step through changes and revisions only. By this point in the meeting there was strong rapport among the

0-7695-0001-3/99 $10.00 (c) 1999 IEEE

8


participants with a high level of trust and a meeting culture established. This walkthrough was each time accompanied by humor and expedition. The walkthrough took less than an hour to complete, but boundaries blurred as dyads would often break off to do individual editing during this process. It is important to emphasize the difference in tone between the initial verbal discussions the first day of the session and the walkthrough at the end of the session. The vary process of document creation seemed to serve as a team building exercise bringing the group together, evolving a culture and language, and developing a sense of shared ownership for the document produced. On several occasions the group expressed strong possessiveness towards the document and argued to maintain control of it as the document passed through subsequent stages of approval at the sponsoring organization headquarters. This level of commitment and document ownership was in sharp contrast to the initial document drafts prepared via traditional documentation means prior to the initiation of these GSS sessions. Stage 6 distributed, the verbal walkthru, was also a section were we required those who could to come together in a synchronous session. Those who could not make the meeting were once again connected to the rest of the group via conference call. The group came together on the final document. Buy-in and group rapport was not as strong as that of the synchronous session. Issues of control over the document led the group to bicker over who had contributed the most. There were issues on protocols and who now had control of the finished document.

Conclusions Through the research in the application of GroupWriter to synchronous and asynchronous group sessions, we have internalized the need for facilitation and the importance of structured processes to support groups. For GroupWriter sessions with both the government and experimental, student groups, a readiness assessment for establishing the ability to create a documents must be conducted. With, several groups, it was found that they were not ready to write and were not sufficiently knowledgeable in the document's goal or content. These groups would have been better served through focusing their efforts in a traditional GroupSystems session and then invoking a GroupWriter session. The GroupSystems session would work to establish a

shared sense of purpose and would define the document's structure and overall content. Distributed sessions were successful in allowing the groups to work on a shared document and finish the job. Work must be done on developing a good set of preset protocols and developing a method to bring groups together in the process even though they may never meet face-to-face. Buy-in and implementation are important factors with using the tool. We must also provide detailed instructions and on-line help for the tool. This would allow participants to focus on the process and not the technology.

Collaboration Tools GroupWriter is unique among collaborative writing tools in the granularity of locking and the support for simultaneous writing. While most tools control update anomalies through the use of document locking, GroupWriter locks at the section level of the document. The most common applications for collaborating with a document are through the traditional document management system (DMS). Generally, these allow users to check out a document for editing. The collaborator can then make changes and return the document. One such DMS is Xerox’s DocuShare. It affords users the opportunity to sequentially collaborate on documents while using a web browser enhanced with proprietary plug-ins. Such tools are valuable, but don’t really facilitate simultaneous collaboration or the required processes. The incorporation of collaborative tools into Microsoft Word is a sure sign that the need for group editing support has reached critical mass. Word 98 supports the tracking of versions, changes and the merging of documents. Additionally, it allows for meta messaging within the document. All of these enhancements make for improvements in collaborative writing. They do not, however, lend the same level of real-time simultaneous support of the GroupWriter tool.

Future Research CMI has many experiences supporting synchronous and asynchronous distributed collaborative writing sessions. At this time, work is being done on defining preset protocols

0-7695-0001-3/99 $10.00 (c) 1999 IEEE

9


to assist with the use of the tool. On-line tutorials are now available on the web. The development of a JAVA GroupWriter prototype is in the process, which does not require GroupSystems as a platform, therefore decreasing the learning curve by allowing users to concentrate efforts on GroupWriter alone. Our focus has become on implementation and increasing usage of the tool.

Diffusion Efforts The Construction Engineering Research Laboratory (CERL) will be the center of supporting roll out to a larger user population. CERL supports DENIX, the Department of Defense’s Environmental Information Management System. GroupWriter has become resident on a DENIX CITRIX server and will become available to 14,000. Research will focus on providing CERL with specialized training in the use of GroupWriter, supporting the development of workspaces to support specific DENIX user communities, and providing ongoing support over a limited test period. Some training will need to be conducted on site at CERL and support efforts will continue from CMI. GroupWriter will also be integrated in the DENIX tool-set. DENIX users will be able to access the GroupWriter server via the Citrix hardware and software solution for distributed access. Availability to such a large user population will increase the potential number of user groups and allow investigation of different process structures and readiness measures with a wider number of participants.

Java Version GroupWriter The JAVA programming language invaded the arena of computation in 1995. It emerged with the abilities to enable information retrieval from Internet Web servers, databases, or any other conceivable source, with the influence of a generic structure popularly called “cross platform” development environment. It is a practical and powerful solution for today's networked programming environment. JAVA is simple, concise, clean, and well defined. It implements security features reassuring to both developers and end users. The implementation of GroupWriter in JAVA dramatically changes the functionality and convenience of the tool. The most important factor is the ease of using the tool in distributed sessions. JAVA GroupWriter allows its users to directly log-

on to a particular session without the need of a server or GroupSystems; access is acquired through a web browser. There are no limitations set by servers or the constraints of GroupSystems. Set-up for JAVA is very simple. There is no need to acquire server licenses and maintenance is minimal. The use of the CITRIX server on DENIX to access Windows GroupWriter was problematic. The configuration of the server had to be modified. Connectivity to a particular session required access to the CITRIX server, GroupSystems, and then GroupWriter. Users had to know and understand how to use these before logging on to learn how to use GroupWriter making implementation and consistency in use difficult. JAVA eliminates these issues and will allow users to concentrate on the GroupWriter session at hand. Currently, an experimental prototype of JAVA GroupWriter is being tested. This prototype is a stand-alone version. At this time it has the same functions and features as Windows GroupWriter. Some added features that will be incorporated are different kinds of communication capabilities, for example a chat window. This will allow users taking part in the distributed session to have simultaneous access to the document and also comment with one another instantly. The JAVA version GroupWriter will also have a more simplistic interface than that of the Windows version GroupWriter.

References [1] Alavi, M. (1994). Computer-mediated collaborative learning: An empirical evaluation. MIS Quarterly, 18 (2), 159-174. [2] Briggs, R.O., Ramesh, V., Romano, N.C. & Latimer, J. (1994-95). The Exemplar Project: Using Group Support Systems to Improve the Learning Environment. Journal of Educational Technology Systems, 23 (3), 227-291. [3] Diaper, D. (1993) “Small-scale collaborative writing suing electronic mail,” in Diaper, D.& Sanger, C. (eds.) CSCW in Practice: an Introduction and Case Studies, Springer-Verlag: London [4] Duin, A. (1991) “ Computer-supported collaborative writing: The workplace and the writing classroom,” Journal of Business and Technical Communication, 5(2) pp. 123-150.

0-7695-0001-3/99 $10.00 (c) 1999 IEEE

10


[5] Duin, A. (1990) “Terms and tools: A theory and research-based approach to collaborative writing,” The Bulletin of the Association for Business Computing, 53(2), pp.45-50 [6] Dubrovsky, V.J., Kiesler, S. & Sethna, B.N. (1991). The Equalization Phenomenon: Status Effects in Computer-Mediated and Face-to-Face Decision-Making Groups. Human-Computer Interaction, 6, 119-146. [7] Ellis, C. A., Gibbs, S. J. & Rein, G. L. (1991) Groupware: some issues and experiences, Communications of the ACM 34(1):39-58. [8] Kirby, A. & Rodden, T. (1995) “Contact: Support for Distributed Cooperative Writing,” In Marmolin, H., Sundblad, Y. & Schmidt, K. (eds.) Proceedings of the Fourth European Conference on Computer-Supported Cooperative Work, Kluwer: Dordrecht, The Netherlands. [9] Kirkpatrick, D. (1992, March 23). Here comes the payoff from PCs. Fortune, pp.93102.Nunamaker, Jr. & Ralph H. Sprague, Jr. (eds.), Proceedings of the Twenty-Ninth Annual Hawaii International Conference on System Sciences, 313-322. Los Alamitos, CA: IEEE Computer Society Press. [10]Kraut, R., Galegher, J., Fish, R. & Chalfonte, B. (1992) “Task requirements and media choice in collaborative writing,” Human-Computer Interaction, 7 pp. 375-407. [11]Mitchell, A. &Baecker, R. (1996). Communication and Control in a Shared Text Workspace. [12]Mitchell, A., Posner, I. &Baecker, R. (1995). Learning to Write Together Using Groupware. Proceedings of CHI [13]McComb, M. (1993). Augmenting a Group Discussion Course with Computer-Mediated Communication in a Small College Setting. [14]Nunamaker, J.F., Briggs, R. & Mittleman, D. (1995). Electronic Meeting Systems: Ten Years of Lessons Learned. Groupware: Technology and Applications. [15]Nunamaker, J.F., Dennis, A.R., Valacich, J.S., Vogel, D.R., and George, J.F. (1991). Electronic meeting systems to support group work. Communications of the ACM, 35 (7), 4061. [16]Salomon, Gavriel. (1989). When teams do not function the way they ought to. International Journal of Education Research, 13(1), 89-99. [17]Sharples, M. (1993) “Adding a little structure to collaborative writing” in Diaper, D.& Sanger, C. (eds.) CSCW in Practice: an Introduction and Case Studies, Springer-Verlag: London

[18]Sharples, M., Goodlet, J., Beck, E., Wood, C., Easterbrook, S., & Plowman L. (1993) “Research issues in the study of computer support collaborative writing,” in Sharples, M. (ed.) Computer Supported Collaborative Writing, Springer-Verlag: London. [19]Slavin, R.E. (1991). Cooperative Learning. Review of Educational Research, 50(2), 315-342. [20]Walsh, K.R, Briggs, R.O, Ayoub, J, Vanderboom, C., & Glynn, M.S. (1996). Learning with GSS: A case study. Proceedings of the 29th Annual Hawaii International Conference on Systems Sciences, 3, 283-292. Los Alamitos, CA: IEEE Computer Society Press.

0-7695-0001-3/99 $10.00 (c) 1999 IEEE

11